 Einen schönen guten Abend. Ah, wait, ist anybody here who only speaks English? No? Gut, so, dann werde ich es in Deutsch machen. Also, es geht, wie auch angekündigt, so ein bisschen, erst mal allgemein, wie gerade der Stand bei E-Mail-Incription ist. Die verschiedenen Projekte, die da gerade unterwegs sind. Da hat sich einiges getan in den letzten Jahren, noch im letzten Jahr. Und dann geht es ein bisschen auch in so Usability-Demos von Autocrip, was ich da ein bisschen genauer erzählen werde. Das ist das Projekt, in dem ich gerade viel involviert bin. Und zum quasi dritten Teil geht es dann tatsächlich darum, ein bisschen zu gucken, je nachdem, was für ein Mail-Setup ihr habt, ob ihr das schon jetzt für euch zum Laufen bringen könntet. Also, zuerst mal zu der Motivation. Das, ich glaube, ein wesentlicher Punkt, wo die Leute, die jetzt gerade sich damit beschäftigen von verschiedenen Projekten aus, ist, dass das mit dem, das E-Mail irgendwie eine alte Technologie ist und dass es eben schon immer wieder mal totgesagt wurde. Schon vor zehn Jahren gab es die ersten Totsagungen. Aber nach wie vor noch viel benutzt wird. Und auch für Mobiltelefone quasi der Anker ist, an dem das aufgehängt ist. Und auch für viele andere Services. Es gibt ein bisschen Absetzbewegungen, also auch von bekamter vielleicht mit, von Facebook zum Beispiel, dass die jetzt versuchen, ihre Account Recovery zusammen mit GitHub so zu machen, dass man sich, wenn man in GitHub ein neues Passwort braucht, dann einfach nur in Facebook einlockt und das quasi umgeht. Es gibt aber einen guten Grund, warum es Sinn macht, nochmal zu schauen, dass vielleicht E-Mail etwas Erhaltenswertes und auch sehr, dass es Sinn macht, das weiter auszubauen und es doch nochmals verbessern. Und der Hintergrund ist einfach der, dass das E-Mail-System so eine Art von öffentliches Identifikationssystem darstellt, wo ich mir E-Mail-Adressen mehr oder minder selbst machen kann, wenn ich irgendwie genügend Expertise habe, mir ein Mailshaber aufzusetzen. Oder einfach zu jemandem gehen kann, zu irgendeiner Gruppierung, zu einer Firma, zu einem möglichen, wo ich ein E-Mail-Account mir kreieren kann. Das heißt, dass das Deployment, also dass die Art und Weise, wie E-Mail-Messaging funktioniert, basiert auf einer sozialen Föderation. Also sprich, die verschiedenen Server, die gemacht werden, sind jeweils unterschiedliche Gruppen. Und das ist quasi eine soziale Föderation. Es gibt auch eine technische und auch eine technische Dezentralisierung. Also Bitcoin ist ein bekanntes Beispiel, wo also eine Software läuft, die Dezentral läuft, aber sie ist sozial relativ zentralisiert. Es gibt sozusagen eine Quelle, manchmal streiten die sich, aber es gibt sozusagen recht begrenzt, eine Gruppe von Leuten, die die Software produziert und auch, was dann sozusagen das ganze Deployment erzeugt, was dann zwar peer-to-peer ist, aber es ist quasi konzeptionell in gewisser Hinsicht zentralisiert. Und bei E-Mail ist es eben nicht der Fall, was gleichzeitig was Gutes ist, weil es eben nicht in der Kontrolle einer Entität liegt. Und gleichzeitig aber auch eines der Probleme, warum es nicht so einfach ist, neue Sachen zu machen. Weil ich muss relativ viele Player überzeugen, dass sie das wirklich auch deployen. Es gibt auch einige Standards, die eben nicht von allen implementiert werden, gerade bei IMMAP und so den ganzen Protokollen, die sozusagen innerhalb dieses E-Mail-Systems eine Rolle spielen. Und es ist allerdings, wenn man überlegt, dass derzeitige Entwicklung bei Identifikationssystemen geht halt eher zu Mobilfunknummern. Das sozusagen alles am Mobiltelefon aufgehängt ist. Und das ist halt eine Sache, die extrem proprietär und kontrolliert ist. Ich kann nicht einfach mein eigenes Mobilfunk-Dings aufmachen und einfach eine eigene Nummer kreieren oder irgendwas machen. Zusätzlich ist es auch noch mit diversen Gesetzen und auch Technologien unterlegt, die das eben alles tracken, welche Zellen und so weiter und so weiter. Das sind eben alles Sachen, die beim Messaging oder bei der Identifikation, die im E-Mail-System verankert ist, nicht der Fall sind. Das heißt, obwohl Gmail sehr dominant ist, gibt es trotzdem auch noch viele andere. In vielen Ländern, in vielen verschiedenen Gruppierungen, auch Internationale, die ihre eigenen Infrastrukturen betreiben. Vielleicht eine kurze Frage. Wer von euch benutzt eigentlich E-Mail für tatsächlich private Mails? Also nicht Arbeit? Ich habe mal eine 22-Jährige gefragt, die meinte, sie benutzt E-Mail nur für Arbeit und Spam. Was anderes sozusagen, sonst macht sie halt irgendwie WhatsApp oder irgendwas. Aber meine Frage an euch ist jetzt, einfach mal so einen Eindruck zu kriegen, wer von euch benutzt E-Mail tatsächlich um private Briefe zu schräumen? Ja, Vereinsgeschichten ausschließen. Ja, das war interessanterweise beim Internet-Film-Festival, wo wir jetzt im letzten Monat auch eine Session gemacht haben. Es waren so ungefähr 60, 70 Leute da, war das auch der Fall. Das ist wahrscheinlich der Grund, warum ihr hier seid, dass ihr euch überhaupt dafür interessiert. Naja, also aus der Überlegung heraus, mal losgelöst davon, dass es viele Probleme gibt im E-Mail-Ecosystem, ist das halt einfach ein hausragendes Feature, dass man sich seine eigene user-generated ID machen kann und dass nicht von vornherein alles getrackt ist und sowas. Dann ist es so End-to-end Encryption, wie ihr wahrscheinlich wisst, PGP Classic, sage ich mal, ist seit mindestens 15 Jahren, 10, 15 Jahren in der Entwicklung und es gab im letzten Jahr zwei PGP-Konferenzen. Das eine war der PGP Summit, das war so eine halb geschlossene Veranstaltung und das andere war die OpenPGP Conf. Es gab also auch so einen split in der PGP-Community, darüber wie man die Konferenz macht. Also die einen haben gesagt, wir wollen einen Treffen haben, wo auch jemand von Google kommen kann und Gary war auch von Google dann da und der halt irgendwie dann Sachen sagen kann, ohne dass es sofort irgendwie als Nachricht irgendwo gepostet wird oder so. Das nennt sich dann Chatter im House Rules und das war wiederum von einer anderen Fraktion, die halt meinten, wir wollen solche geschlossenen Sachen, wo man nicht offen über Sachen reden kann, weil wir nicht haben. Deswegen gab es so einen Split, aber der ist jetzt auch nicht total krass, aber es gab deswegen diese zwei Treffen und das ist wiederum der Grund, warum sich Leute mehrfach getroffen haben, die einfach bei beiden Treffen waren und im Zuge dessen dann eben an diesem Autocryp-Projekt, wo ich noch ein bisschen was mehr zu erzählen werde. Zusammen kam im Dezember letzten Jahres in Berlin und der Hintergrund, warum die sich getroffen haben, ist, dass wir so eine Art von gemeinsamer Sicht, also diese Leute, die involviert sind, entwickelt haben, dass eines der Probleme bei E-Mail-Ende-Zu-Ende-Verschlüsselung ist, dass es von Anfang an einen sehr starken Fokus auf so genannten aktiven Attacken gab. Das heißt, also aktive und passive Attacken, erst mal so als grobes, als grobe Differenz bedeutet, ein passiver Attacker ist einfach jemand, der nur Daten sammelt und irgendwie alles korreliert aber quasi in seiner eigenen Ecke. Ein aktiver ist jemand, der wirklich Downgrade Attacks macht, der irgendwie versucht, Messages so zu verändern, dass irgendwie keine Encryption stattfindet oder er dann mitlesen kann, indem er irgendwie Keys austauscht. Klassisches Beispiel, man in the middle attack, dass jemand beiden Seiten irgendwas vortäuscht und beide denken jeweils, sie reden mit dem eigentlichen, aber sie reden noch mit einem, der dazwischen ist. Und wenn man versucht, einen Protokoll zu etablieren, was gegen aktive Attacken gesichert ist, wird es wesentlich komplexer einfach. Und daher kommt auch das ganze Web of Trust in PGP, dass man versucht irgendwie Möglichkeiten zu finden, aktive Attacken zu detecten, dass also irgendwo falsche Keys sind und eine Art von Sicherheit zu kriegen über dieses Key, was sich auch als eine Art von Certificate beschreiben lässt. Und das Problem ist, dass dadurch wird es dann so kompliziert oder wurde es zumindest in der Praxis kompliziert, dass wir in einer Situation sind, wo die meiste Mail, die geschickt wird, einfach Clear Text ist. Also sprich es für Leute, die Passivdaten sammeln, die gehen dann einfach zu Gmail oder zu ein paar Providern und holen sich einfach die ganzen Mails und die sind einfach ein Klartext da. Das heißt, das war so eine Sicht, die wir quasi geteilt haben letztes Jahr, dass man quasi aus Angst vor dem Tod irgendwie sich runterstürzt irgendwo. Und wir haben gesagt, wir wollen uns vor allen Dingen auf Massenüberwachung im Sinne von Passiver-Datensammlung konzentrieren. Und wenn man aus der Warte, wenn man das sozusagen akzeptiert, und das ist in der Kryptoszene durchaus schwierig, weil ganz schnell immer über aktive Attacken geredet wird automatisch quasi, da kann ja jemand ja einfach austauschen und so. War das zumindest erst mal eine gewisse Diskussion, die notwendig war, um das überhaupt zu etablieren, dass man so drüber nachdenkt, dass man erst mal nur versucht gegen Passive-Attacken, sich jetzt zu werden. Es gibt einen RFC, das ist nach Snowden verfasst worden. Das heißt, ich glaube, 7, 4, 3, 5 oder so, Opportunistic Security. Und das beschreibt genau diesen Zusammenhang. Wenn ich versuche, immer eine hundertprozentige Sicherheit auch gegen aktive Attacken zu machen, dann wird es halt sehr schwierig. Und man sollte, bevor man einfach Klartext macht, lieber irgendwas Opportunistisches machen. Weil das ist zumindest, wenn nicht jemand massiv am aktive Attacken fährt, hat man da schon ganz gute Karten, dass nicht einfach Daten gesammelt werden können. Also das ist auf jeden Fall eine Geschichte, so ein Differenzmerkmal, wenn man sehr unterschiedlich unterwegs sein kann. Und das ist durchaus ein Gedanke, der eben schon in diesem RFC und auch in anderen Gruppierungen da ist. Und es gibt dann so, was immer Encryption angeht, sage ich mal 3 Ansätze, über die ich jetzt ein bisschen mehr was sagen will. Vielleicht zuerst den von dem NoopyG Team selbst. Das nennt sich Webkey Directory. Das ist relativ einfach. Also es ist so ein relativ einfaches Konzept eigentlich. Wenn ich eine E-Mail-Adresse habe, dann nehme ich mir den Domain-Teil und mache darüber im Prinzip so eine Art Canonical Lookup um zu dem Key zu kommen, der zu der E-Mail-Adresse gehört. Also wenn ich eine Adresse hab, die heißt xatposteo.net, dann gehe ich zu Posteo in einem Well-Know-Namespace über HTTPS und dann quasi eine Indirektion auf ein Service, wo ich dann über die E-Mail-Adresse den Key kriege. Das heißt, ich hab dann sozusagen automatisches Key-Lookup, was beim Provider hängt. Und da die Provider eh schon bei der ganzen Mail-Delivery, da geht die Mail ja letztendlich auch hin, drin hängen, also für Mail-Clients ist es nicht unbedingt normal, HTTPS-Requests irgendwo hinzumachen, um irgendwas rauszufinden. Das ist nicht unbedingt in vielen E-Mail-Clients drin, aber es ist gleichzeitig eine Sache, die auf allen Plattformen verfügbar ist und insofern gemacht werden kann und das Web-Key-Directory braucht natürlich der Schlüsselmuster irgendwie hinkommen. Das heißt, die Mail-Clients, die das supporten, und es ist glaube ich jetzt auch ein Enigmail eingebaut, aber noch nicht released, die müssen halt dieses Registrierungsprotokoll sprechen. Also die müssen quasi, wenn ich ein Mail-Client bin und ich hab für meinen User ein Key generiert, dann muss ich den quasi dem Provider irgendwie geben. Und das läuft über eine Mail-Austausche, also ich schicke quasi eine Mail hin, kriege irgendwie eine Mail zurück und die muss ich irgendwie konfirmen. Das lässt sich im Prinzip komplett automatisieren, ist aber glaube ich derzeit immer noch nur so halbautomatisch. Das mein Provider, meinen Key für andere Leute, die mir mailen wollen, zur Verfügung stellt. Aber das ist sozusagen Underway, das gibt es als IETF-Draft, kommt von Werner Koch und dem Gnopigee-Team und hängt natürlich daran, dass die Provider das unterstützen. Und das wird zumindest bei einigen wie zum Beispiel Google wird es sehr schwierig werden. Google hat nach 2013, also nach dieser Snowden-Geschichte genauso wie andere große Firmen so end-to-end Projekte gestartet. Also Google end-to-end heißt das, beziehungsweise dann später dieses Google end-to-end und dann nochmal einen anderen Namen zuschrindlich gehabt. Mittlerweile haben sie aber, das Ziel war eigentlich, Gmail Ende zu Ende verschlüsselt zu machen und sie haben sich aber dann auf ein Teilproblem konzentriert, was sie als sehr wichtig angesehen haben. Nämlich Key-Transparency und Key-Transparency kommt vielleicht nicht über das Kennen, so Certificate-Transparency geht es im Prinzip darum, dass ich sicher sein kann, dass das was ich kriege und in gewisser Hinsicht ist, so ein Public Key, so ein Encryption Key ist so eine Art Zertifikat dass mir der Provider nicht nur einfach irgendwas gibt. Aber es gibt ein grundsätzliches Problem, wenn ich den Providerfrage, den Zielprovider wo ich Gmail hinschicken will, gibt mir doch mal den Key für den User. Dann ist er natürlich von vornherein in einer absolut perfekten Position um Sachen auszutauschen. Er kriegt ja jede Message. Also der muss nicht noch irgendwie sich in irgendein Kiziskorouter einhecken oder irgendwas, der ist ja schon der Provider, da geht jede Message durch. Dann ist er bei meinem Netzwerk identifiziert oder so, einen bestimmten Key gibt, den er sozusagen nur für mich generiert und ich benutze den und denke, das gehört dem anderen User. Dann kann der den einfach ganz silently austauschen, weil er in dieser perfekten Position ist. Das war einer der Motivationen, glaube ich, bei Google, deswegen sie gesagt haben, wir müssen irgendwie ein System haben, was sicherstellt, dass ein Provider dem wer anfragt. Also sprich, wenn ich meinen eigenen Provider frage, was ist mein Key, dann kriege ich meinen Key, wo weiß halt ich Frage an, also gibt da mir meinen Key, wenn jemand anderes fragt, dann wird halt ein anderer Key geschickt. Wie kann ich das mitkriegen? Dieses Problem nennt sich in der Kryptografie Equivocation, also dass ich sozusagen unterschiedliche Aussagen treffe zu verschiedenen Kommunikationspartnern. Das ist ganz stark konzentriert über zwei Jahre auf dieses Thema, was sie das irgendwie verhindern und haben mit Merkle Trees und einem Konzept, das basiert auf einem Forschungspaper von vor zwei Jahren ungefähr, das heißt Connex, wo es im Prinzip eine Fortschreibung von so einer Certificate Transparency Geschichte ist, haben sich damit ganz stark beschäftigt und haben das jetzt auch released, wird aber nicht in Gmail integriert. Das ist sozusagen nur noch oder ist zumindest nicht mehr der Plan. Jetzt haben sie halt dieses Key Transparency System, was irgendwie auch skalieren soll und was sicherlich an sich auch erstmal eine möglicherweise interessante Geschichte ist, aber diese Key Transparency ist halt bloß ein Problem in der Frage, ein kleines Subproblem in gewisser Hinsicht, in der ganzen Frage wie bringt man Ende zu Ende Encryption überall hin? Weil da kommt halt ganz viel Usability, einen Bezug auf Key Loss, also wenn ich oder Device Loss, wenn ich mein Device verliere oder so was, ganz viele Usability Fragen und die muss ich ja auch alle lösen und dann habe ich auch noch Webmail, was auch nochmal speziell ist, weil da bekomme ich den Code, der auf meinem Rechner läuft von dem Provider. Wo sozusagen, wenn ich dann Ende zu Ende mache und ich bekomme aber den Code eigentlich von dem Provider, kann ich natürlich immer auch modifizierten Code bekommen, wenn es dann mal liegt oder so, also bei Webmail nochmal ein Spezialproblem, was ich jetzt bei Debian zum Beispiel nicht habe, wenn ich in Debian irgendwie mein Mail Client installiere, dann ist der unabhängig vom Provider, da kann der Provider nicht einfach mir irgendwas unterschieben oder so. Also sprich, da gibt es eine ganze Menge Probleme, die man da irgendwie lösen muss und Key Transparency ist eben nur eins und das wird bei Webkey Directory, das ist das System, weil was ich gerade angesprochen habe, was es sozusagen derzeit gibt, was auch schon in GNU PG eingebaut ist, da gibt es dann diesen speziellen Lookup, der gemacht wird und die wollen jetzt halt schauen, dass sie das möglichst viele Provider machen, mal schauen. Provider sind in der Hinsicht relativ konservativ, weil das ist ihre Business-Infrastruktur und die sind da nicht so ganz leicht dabei, da irgendwie Sachen dazu zu machen, vor allen Dingen, dass man das als Certificate Authority übernehmen. Dann ist man so sagen, noch mal ein anderes Target für Hacker und so, da irgendwie reinzukommen und irgendwas zu ändern. Das wird sich also zeigen. Es gibt ein zweites Problem, was unterschiedlich eingeschätzt wird bei dieser Geschichte und das betrifft auch die Key-Server, wie man jetzt, ich weiß nicht, wie ihr eure Keys bekommt, ihr macht ein Lookup-Macht auf dem Key-Server und wenn man ein Lookup-Macht auf dem Key-Server oder das auch macht über Web-Key-Directory, also dass man einfach den Provider-Frag, wo man hinschicken will, hat man das Problem, dass man quasi ein unauthenticated, anonymous Lookup erlaubt. Also sprich, jeder kann das machen. Das ist auch der ganze Sinn der Sache und das, dass das auch Spammer machen können. Also derzeit ist Spam im e-mail-Ikosystem nicht mehr so ein großes Thema, weil es eine Kombination von Content-Filtering und IP-Trust-Geschichten, also das Provider sozusagen Trust-Level-Kriegen, die in Real-Time evaluiert werden und dadurch halt, dass mit dem Spam einigermaßen eingegrenzt wurde, dass tatsächlich relativ viel Ende-zu-Ende-Verschlüsselung stattfindet, dann fällt zumindest ein Teil dieser Anti-Spam-Infrastruktur weg. Und das ist eben natürlich für Spammer dann einfach eine große Datenbank anzulegen mit all den Schlüsseln und einfach Sachen Verschlüssel zu schicken. So, das ist zumindest eine Sache, wie gesagt, gibt es unterschiedliche Ansichten, die sagen, naja, wir gucken dann mal, wenn wir das Problem haben, so nach dem Motto. Und es gibt einen, der bei Google gearbeitet hat, Mike Hearn, der hat auf der Messaging-Manning-Liste, wo allgemein über verschiedene Formen von Messaging und Krypto diskutiert wird, hat ja mal ein recht langes Posting gemacht, wo er das aus seiner Sicht erläutert. Also warum das mit Ende-zu-Ende-Verschlüsselung und Spam und einem offenen System, weil E-Mail ist anders als WhatsApp ein offener System. Sobald ich die Adresse habe, kann ich einfach hinmailen. Während ich sonst bei diversen Messengers erstmal den Kontakt etablieren muss, die Seite muss akzeptieren. Bei Freema zumindest ist es, glaube ich, so und auch bei einigen anderen. Und das ist eben bei E-Mail nicht der Fall. Und wenn man also ein offenes Ende-zu-Ende-Verschlüsseltes Messaging-System hat, dann ist halt die Spam-Frage immer ein Thema. Das wird sich also noch zeigen, wie das dann, wie da die Auswirkungen sind und wie auch die Provider das dann sehen. Also jetzt zum Beispiel für Gmail ist wahrscheinlich nicht so einfach weil die natürlich, wenn sie ein Spam-Problem kriegen, dann halt ein Massives und für sehr viele User. Das heißt, da bin ich mal gespannt sozusagen, wie da die Reaktionen sind. Aber das läuft auf jeden Fall und ich denke mal, dass da auch einiges passieren wird in den nächsten Monaten, was auch veröffentlicht wird. Dann das zweite Projekt, was es schon eine ganze Weile gibt, ich glaube seit 4 Jahren oder so, ist die PEP-Engine. Das ist, ich glaube, Pretty Easy Privacy ist das Ding, wir haben es in der Autocript-Gruppe gesagt, dass darf nirgendswo in unserem Text irgendwas mit Easy auftauchen oder Good oder so, weil das ist sozusagen verbrannt. Aber los, weil man dann sagt, das ist alles ganz easy. Aber losgelöst davon sind die seit einiger Zeit schon dabei. Und da ist der Ansatz, dass sie quasi so eine Art von Open Source Produkt liefern, eine Library und die eingebunden werden soll oder kann in alle möglichen Mail-Clients und diese Library kümmert sich quasi darum, das mit den Schlüsseln klarzukriegen und auch die Encryption zu machen und das dann eben möglichst auf einem Plattform. Natürlich ein ziemlicher Entwicklungsaufwand auf mehreren Plattformen sozusagen das gleichzeitig anzubieten und deswegen haben sie auch sich sehr frühzeitig schon um viele Funding bemüht und haben halt sind dabei, da eben jetzt auch, es gibt schon teilweise Releases in verschiedenen Bereichen, das eben weiter vorzuführen. Das wird auch in Enigmail integriert zum Beispiel. Ich weiß aber nicht genau, wie der Status in den verschiedenen Plattformen und Bereichen ist. Ich glaube, da passiert gerade noch eine ganze Menge. Ist aber eben der Ansatz, was ich quasi einen Code habe, der von allen möglichen Leuten benutzt wird. Und der dritte Ansatz, den ich, der eben Autocrypt heißt, der sich jetzt erst seit ein paar Monaten der dreht sich darum, dass wir sagen, wir wollen gegen passive Attacken, also gegen reines Daten sammeln, wollen wir ein System haben, was funktioniert auch wenn die Provider nicht mitmachen. Also auch wenn Gmail nicht mitmacht. Wir haben sozusagen nicht als Vorbedingung, dass die Provider erstmal irgendwas ändern, damit ich dann im E-Mail-Cline irgendwas machen kann, was sozusagen damit arbeitet. Sondern wir sagen, es ist weniger, wenn wir es schaffen, dass das rein von den End-Devices gemacht werden kann, ohne dass die Provider sich ändern müssen. Das ist zumindest eine große Differenz zu dem Web-Key-Directory-Ansatz von dem GNU-PG-Team. Es ist was Ähnliches, was auch, es ist eine ähnliche Sicht, die auch, denke ich, von den Pep-Leuten geteilt wird. Man sozusagen von den End-Devices aus guckt. Der zweite Punkt, der ein Autocrypt sozusagen, den wir da vor uns gefunden haben, ist, dass wir nicht eine Implementierung überall hinbringen wollen, sondern, dass wir Gespräche und Protokolle spezifizieren. Also wir reden sozusagen miteinander die verschiedenen Implementierer und gucken halt, was ist das Minimale, was wir brauchen, damit wir diese Art von Ende-zu-Ende-Verschlüsselung hinkriegen. Und das Grundkonzept ist, dass man gibt, wenn das die Keys im Band transferiert werden. Das heißt, also innerhalb der Mail-Messages. Wenn ich also eine Mail schicke zu jemandem, dann hängt in einem Header, also eine Sache, die normalerweise für Mail-Kleins nicht angezeigt wird, hängt Informationen über den Key und noch ein bisschen was mehr dran. Und die andere Seite kann dann einfach, wenn diese Mail so ankam, das nehmen und zum Verschlüsseln verwenden. Das heißt, es gibt keinen Key-Server-Lookup oder irgendwas in der Art. Und die Mail kommt in gewisser Hinsicht über so transport-authentifizierte Kanäle. Also ich mache keinen anonymen Lookup, ich muss diesen Key auch nirgendwo veröffentlichen. Einfach die Tatsache, dass ich eine Mail schicke, erlaubt der Gegenseite sozusagen an mich zu verschlüsseln. Das geht an der Stelle auch in Bezug auf das Spam-Problem. Weil diese Keys sind nicht so leicht zu sammeln. Weil die sind nirgendswo in dem Sinne zentral vorhanden, wo man sie abrufen könnte, wie auf einem Key-Server oder wie bei Web-Key-Directory, sondern die befinden sich halt in diesen Messages. Das heißt, die Spammers müssen es irgendwie schaffen, ihre Erzfeinde, weil die Email-Betreiber sind sozusagen, die automatisch diejenigen, die versuchen, gerade nicht es den Spammers zu machen, von denen irgendwie die Keys zu kriegen. Weil die kriegen die Keys natürlich mit. Ich habe eine verschlüsselte, transportverschlüsselte Mail von mir an dem Provider. Der Provider hat den Header, also der kennt den Key auch, der sieht ihn sozusagen, während er durchgeht. Und dann wird die Mail weiter geschickt und heutzutage ist das meiste schon dann auch über Transportverschlüsselung abgesichert. Das heißt, es kriegt erstmal niemand, den ganzen Schlüssel mit. So nicht per se. Außer man hat mal wieder irgendwie TLS kaputt gemacht oder so, dann vielleicht doch. Aber erstmal so grundsätzlich nicht so einfach für Spammers an diese ganzen Keys ranzukommen. Wie relevant das ist, da können wir auch noch darüber reden. Die entscheidende Geschichte denke ich, die dann bei, sag ich mal, in diesen Autocrypt-Diskussionen eine große Rolle spielt, ist, dass wir sehr viel in Bezug auf Usability uns überlegen. Wir wollen ein möglichst minimales System. Wir wollen nicht, dass ein User irgendwas mit Keys entscheiden muss. Kann ich jetzt diesen Key vertrauen oder nicht? Und kann ich ihn importieren oder nicht? Oder will ich meinen Key exportieren? Diese ganzen Fragen sind einfach nicht da irgendwie ein mentales Konzept zu haben, was irgendwie ein Public Key ist oder so. Also es ist einfach schwierig, weil was ist ein öffentlicher Schlüssel? Ich hab hier irgendwie so ein Schlüssel. Was ist jetzt irgendwie ein öffentlicher Schlüssel? Ist es sozusagen, wenn man nicht irgendwie mit der Mathematik irgendwas zu tun hat oder damit irgendwie was anfangen kann, dann ist das schon mal ein Problem, da überhaupt anzufangen, darüber zu reden. Leute gewöhnen sich dann dran, da irgendwie darüber zu reden. Und einige sprechen dann lieber von Encryption Key, also ein Verschlüsselungskey oder manchmal auch eine Verschlüsselungszahl. Was tatsächlich für viele sozusagen ein bisschen einfacher zu verstehen ist. Weil mit Zahlen kann man komische Sachen machen. Es ist halt eine Verschlüsselungszahl, damit kann ich irgendwas machen. Während so was wie ein öffentlicher Schlüssel hat keinerlei Assoziationen, die irgendwie hilfreich ist für einen nicht-mathematischen Background hervorruft. Naja, und die usability, die zentrale, eine der zentralen Geschichten bei usability-Problemen ist unreadable mail. Also sprich, ich bekomme eine Mail, die ich nicht lesen kann. Wer hat, also erstmal, wer macht von euch gerade PGP in irgendeiner Form? Okay, und wer hat im letzten Monat entweder selbst eine unreadable mail gekriegt oder von der Gegenseite gehört, dass sie das nicht lesen kann, irgendwie. Nicht so viele. Es ist auf jeden Fall ein Problem, was sehr viel auftaucht und es gibt, also wir haben auch Kontakt mit verschiedenen Trainern, also in Venezuela und allen möglichen, gerade auf dem IFF, auch viel mit Trainern geredet, die also Leuten PGP beibringen, Aktivisten, allen möglichen Leuten, wo bei denen die Frage dran hängt, ob sie verfolgt werden oder nicht, ob im Staat hinter ihnen her ist und sie für irgendwas dran kriegt oder nicht. Und die sagen halt, dass im Prinzip alle sich einig sind, sie brauchen das irgendwie, es ist irgendwie wichtig, weil sonst ihre staatlichen Provider oder andere einfach alles im Klartext direkt da haben. Aber sind sich alle einig in dem Kurs, der Trainer und die Leute, die das Kurs machen oder so. Und wenn man dann mal nachfragt, nach zwei Wochen, wer von denen macht das wirklich, dann ist es halt in der Regel niemand. Also alle finden es wichtig, aber keiner, sozusagen, kriegt es wirklich in seinen Alltag integriert. Das stimmt natürlich nicht, ja? Wo wird es? Genau. Moment, mir ging es darum, sozusagen diesen Usability Aspekt, dass der sozusagen einfach ein großes Hemmnis ist. Genau, für die Allgemeinheit. Und es gibt dann noch zusätzlich das Problem, das gibt es in einigen Staaten, dass allein die Tatsache, dass man PGP verwendet, schon sozusagen ein Problem ist. Oder die Tatsache, dass man ein Rise Up Account hat oder irgendwas. Dass das schon ausreichend ist, um vor Gericht verwendet zu werden, als ja, ja, der ist wahrscheinlich irgendwie, ist irgendwie mit irgendwelchen Leuten verbunden, die irgendwas terroristisches wollen oder so. Das Problem ist einfach, dass es eigentlich ziemlich viel Bereitschaft gibt von Leuten da sozusagen Sachen auszuprobieren, aber dass sie mit der ganzen Komplexität, die eben mit dieser aktiven Angriffsgeschichte die PGP-Klassek versucht zu lösen, oft überfordert sind. Und dann gibt es noch die Weisloss, Kilos und viele andere Geschichten, die man natürlich benutzt. Und das eine der Geschichten ist bei opportunistischer Verschlüsselung, dass man im Zweifelsfall, bevor die andere Seite Mails kriegt, die sie nicht lesen kann, lieber Klartext checkt. Und das ist sozusagen so ein gewisser Bruch, weil normalerweise ist es so, na ja, wenn ich irgendwie Signal benutze zum Beispiel, dann will ich halt sicher sein, dass die SMS verschlüsselt ist. Soll nicht mal zwischendurch irgendwie nicht verschlüsselt sein. Mal abgesehen davon, dass sie in Signal diese SMS Signal Message Geschichte verwirrt wahnsinnig viele Leute, dass sie nicht so richtig realisieren, dass die SMS, die sie schicken, auch wenn Signal die SMS-Message ist, natürlich nicht verschlüsselt ist. Jetzt haben sie ja irgendwann abgeschafft, vor 2 Jahren oder so, dass die SMS verschlüsselt ist, wenn sie sich eine SMS schickt, weil man gerade Kandidatenverbindungen oder irgendwas hat, muss man sehr genau hingucken, was unten das Symbol sagt. Es ist schon verschiedene Leuten passiert, dass sie dann dachten, das wäre verschlüsselt, war es aber nicht. Also dieser Mix, der wird allgemein als was Negatives empfunden. Bei E-Mail ist es allerdings nicht so unbedingt der Fall, weil bei E-Mail ist es so, dass eh erstmal alle irgendwie von Klartext ausgehen. Und je nachdem, was ich dem User tatsächlich anzeige, ist auch nicht die Erwartung da, dass alles immer komplett verschlüsselt ist. So unsichtbar quasi. Und die wesentliche Geschichte bei dem Verhindern von unleserlicher Mail oder von Mail, die man nicht lesen kann, ist eben das Bedenken von was passiert bei Device oder Kilos und das große Thema E-Mail, Ende zu Ende Verschlüsselung bei der Benutzung von verschiedenen Geräten. Wobei ein Gerät zum Beispiel auch ein Web Browser ist in dem Fall. Einfach Multi Device. So wird das angeführt. Und das ist eben, wenn ich irgendwie einen K9 hab, also der Wincent von K9, der ist zum Beispiel auch bei den Autocrib Geschichten dabei. Der Android App. Wenn ich dort jetzt das mache, was auch immer, das Ganze egal, was, und dann habe ich aber noch mein Webmail Account, über den ich auch noch reingehe, dann kriege ich plötzlich unreadable Mail. Also ich schicke irgendwie was raus, ich habe mein, sei es mein Header oder Pep-Engine, egal, die andere Seite sieht das und will dann verschlüsseln an mich und ich kann das aber dann in meiner Webmail nicht lesen. Und das ist für jemand, der jetzt nicht irgendwie wahnsinnig viel Aufwand reinsteckt, seinen E-Mail-Set abzustehen und was genau mit der Verschlüsselung ist und so, nervig. Und da sage ich unter Umständen einfach, ich schalte es ab, weil irgendwie kann ich die Mail nicht lesen und das nervt mich. Und diese Probleme, da sind wir in, sage ich mal, ist der Grundansatz in Autocrib auf jeden Fall ziemlich defensiv. Also sofern wir nicht sicher wissen, dass das, dass auf mehreren Devices das gelesen werden kann, lieber nicht der anderen Seite empfehlen, an mich zu verschlüsseln. Aber an der Stelle direkt in so eine, sozusagen eine Usability oder eine UI, die wir gemockt haben, mal reingehen, da bräuchte ich mal den Bildschirm zu, damit das vielleicht etwas konkreter wird, wie das dann aussieht. Im Prinzip könnten wir es auch so machen, wenn irgendjemand hier auf meiner englischen Tastatur sich bereitfindet. Also ich brauche einen Freiwilligen, der sich mal in dieses User-Interface setzt. Oh, ist noch nicht da. Achso. Jetzt kommt was. Ich muss noch kurz Mirroring einstellen. Also eine Freiwillige, einen Freiwilligen, der einfach nur kurz, ich sage gleich was dazu, das ist sozusagen der neue Mail-Client. Super simple. Das ist nicht schwer. Also es ist so, der wurde gesagt, Szenario, der wurde gesagt, dass du jetzt ein autokriptfähigen Mail-Client hast, den du jetzt gerade installiert hast und der wurde auch gesagt, dass du das in den Settings irgendwie einschalten musst und eine anderen Person, Bob, die heißt zwangsweise Bob und du bist Alice. Achso. Ja, kann ich. Control ist bei mir Funktion. So. Oh, ist gut. Genau, also dir wurde gesagt, dass du jetzt einen autokriptfähigen Mail-Client hast und dass du in den Settings das einschalten kannst und dann anfangen kannst, anderen Leuten Mails zu schicken und wenn die das auch haben, also wenn die auch ein Client haben, dann kannst du sprechen dazu, ich kann dich auch mal setzen so, jetzt hast du gerade enabled, genau. Ich will möglichst wenig sagen, also sollst du eine Mail schicken, jetzt musst du so sagen, selbst gucken. Ja, da kannst du zwischen Alice und Bob wechseln. Also das ist sozusagen nicht wirklich jetzt zwei Bildschirme, sondern wer wechseln, wenn die Mail geschickt ist, so ja, genau, du musst noch mal nach oben scrollen, die Mobilität, immer irgendwas zeppten. Sag dir Bescheid, wenn er soweit jetzt stabil, dann würde ich jetzt wahrscheinlich eine Mail schreiben. Also du musst an Bob schreiben, es ist ein bisschen eingeschränkt. Es musst du einfach lesen, ich sage jetzt nix. Ja, es ist wahrscheinlich ein Tick zu unten, das ist ein Scrollbalken oder einmal Control-Minus. Es fehlt nicht viel, also es fehlt nur ein bisschen. Ja, das ist Englisch und ich kann dir auch Deutsch einbieten. So, muss jetzt Chipfeller sind egal. Genau, senden musst du noch. Also Alice hat Bob eine Nachricht geschickt mit Subject Hello und jetzt müsste eigentlich noch jemand anders jetzt musst du Changes auf Bob, genau, du bist schon auf der Mailbox gerade und dann, sorry, das Y ist gerade kaputt, also du bist als Bob eingelockt, weißt du. Es gibt da keinen Save-Button, also, ja. Jetzt hat Bob, Changes die Pfeile einfach, ihr seht jetzt hier auch an dem Symbol, dass diese Mails hier jeweils verschlüsselt sind. Also es ist halt ein UI-Mockup, aber bis du als Alice eingelockt oder als Bob, wenn du als Bob eingelockt bist und dir die Nachricht von Alice an Bob, also die anschaust, die hier eben Message was encrypted. Also das ist sozusagen grundsätzlich der vielen Dank, dass das ist derzeit das, was sozusagen wie das gedacht ist, also das müssen User irgendwie verstehen. Das ist natürlich ein bisschen so, man muss irgendwie eine Mail schicken und wenn man quasi irgendwie so ein Contact schon established hat und der hat auch Autocrypt, dann muss er das nur irgendwie enablen und dann kann ich einfach encrypten. Es gibt auch Keys irgendwie da, es sind keine also man muss nicht irgendwie verstehen, was Keys sind oder so was, sondern hat das halt auf der Ebene. Es gibt eine Sache, die interessant ist, du bist gleich hingegangen und hast IPrefer encrypted und das ist auch der Grund, warum bei dem Reply, also wenn ich jetzt eine Mail schicke, als Bob an Alice, dann defaultet das auf encrypt. Ja, also dann habe ich sozusagen einfach nur weil ich Alice eingegeben habe und ich habe den Key und Alice hat in ihrem Setting gesagt, I prefer to receive encrypted mail. Deswegen ist der default hier encrypt. Was du allerdings nicht gemacht hast, glaube ich ist zu gucken, was da steht weil niemand liest irgendwelche Sachen, die sozusagen weil hier steht please enable auto-crypt and only one device und hier heißt es auto-crypt will encourage your peers to send you encrypted mail und das ist noch nicht ganz ausgereift also wir wollen da noch weitere usability Tests machen, weil das Problem ist jetzt folgendes dass wenn ich jetzt ein zweites Device habe dann kann ich derzeit also mit dem auto-crypt level 0, wie wir das nennen nicht einfach ich kann nicht sozusagen auf zwei Devices das betreiben ich kann es nur auf einem Device betreiben weil wir haben quasi so ein Schrittweises vorgehen, weil jetzt in den nächsten Monaten das quasi in verschiedenen Clients releasen und im nächsten Schritt dann Multi-Device automatisiert unterstützen da sage ich gleich noch ein bisschen was zu der Punkt ist halt hier in den Settings dadurch dass hier jetzt steht in den Advanced Settings I prefer to receive encrypted mail dass tatsächlich die andere Seite immer defaulten wird auf encrypted mail das heißt wenn ich jetzt noch ein Webmailer habe der kein Auto-crypt kann dann kriege ich da halt PGP Messages dann kriege ich da sozusagen encrypted messages und können sie nicht lesen und das ist auch der Grund warum das unter Advanced Settings ist und hier normalerweise gar nicht aufklappt und man leuten halt einfach nur sagt mach enable und das war es der default ist tatsächlich nicht sozusagen das weder das noch das sondern der default ist dass jeder wählen kann ob er verschlüsseln will oder nicht das ist der default und bei default heißt das es ist nicht verschlüsselt das heißt wenn Alice Bob eine Mail schickt und hat in den Settings eingestellt nicht so eingestellt quasi keine Preference dann wird Bob wenn er schickt dann wird dieser Button, wir können das auch kurz machen das müsste eigentlich funktionieren wenn ich jetzt als Alice mich einlogge in den Preferences die Advanced Settings das jetzt zurücknehme und dann eine Mail schreibe das ist noch wichtig jetzt an Bob Hallo ich kann auch immer von Hand das Encrypt wieder rausnehmen das ist auch eine Sache eine Entscheidung die wir getroffen haben weil Menschen in der Regel teilweise Sachen wissen die Maschinen nicht wissen wie zum Beispiel dass irgendjemand gerade auf Reisen ist und sowieso nur Webmail hat und es einfach keinen Sinn macht jetzt gerade zu verschlüsseln solche Situationen gibt es halt und da ist es dann halt schwierig wenn die Maschine das einfach entscheidet und ich kann es quasi überhaupt nicht mehr ändern also man könnte jetzt sagen nein wenn man Encrypten kann, dann muss man bei Encrypten bleiben aber das ist eben wichtig ist dass die Leute ihre Messages lesen können das ist sozusagen deren Interesse und wenn sie quasi keine Möglichkeit kriegen irgendwas zu schicken und die andere Seite kann es lesen auf ihrem Webmail klein zum Beispiel dann ist es nervig dann nervt mich dieses Feature sozusagen und ich werde es möglicherweise einfach deaktivieren ja kann ich es deaktivieren ohne Zugriff auf meinen privaten Schlüssel zu haben ja das ist einfach normalerweise nicht weil diese Mail normalerweise überhaupt nicht ankommen wird also z.B. Gmail macht zum Beispiel Decom Domain Key Identified Mail das heißt das ist eine Signatur das heißt wenn du jetzt einfach eine Mail schickst in meinem Gmail Account Namen dann wird das normalerweise von meinem Mail Provider einfach gar nicht an mich durchgereicht du schickst bei mir wahrscheinlich nicht und bei Google glaube ich auch nicht mit Decom Verification also ich glaube nicht, dass du einfach mal probierst holger.gemail.com und schick mir eine Mail was denn wenn ich jetzt irgendein Nutzer habe der da nicht weiß was zu tun oder so der ist das Hatchen zu setzen also also die Grundgeschichte ist, dass wir sagen der derzeitige Zustand ist Clear Text und wir wollen so viele wie möglich Clear Text Messages mit Encrypted Messages ersetzen aber unter der Restriktion dass die User nicht nervt das sozusagen nicht irgendwie die Flows unterbricht und man irgendwas nicht lesen kann und genervt ist einfach weil das dann meistens zum Abschalten führt und das heißt an der Stelle fällt derzeit, aber das ist aber noch pending Usability Tests glaube ich nicht dass jetzt zum Beispiel bei K9 oder anderen dann mal extra eine Warnung hochpoppt oder so also hier ist das natürlich irgendwie so dargestellt also wie das ganz genau visualisiert wird das hängt natürlich auch von dem Kontext ab weil das in Enigmail anders aussieht als in K9 was halt ein viel kleineren Screen hat und so was aber das sind, genau also ich sag mal so das Ding ist jetzt nicht gemeint als visueller Prototype es ist sozusagen eher um das Konzept zu verstehen und so ein bisschen den UI Flow wie das genau visualisiert wird das ist dann wirklich auch sehr Mail-Client spezifisch weil das eben also der Winsens also auf einem Android oder auf einem iOS System denkst du da ganz anders drüber nach als irgendwie in der Desktop oder Webmail oder irgendwas Geschichte muss man sozusagen sehr spezifisch dann da lösen und das hier ist quasi nur so ein vom Flow her ich will gerne kurz einmal machen dass ich die Preferences habe ich jetzt geändert jetzt will ich eine Mail schicken Bob, hallo zum zweiten was auch immer so die ist weiterhin verschlüsselt weil Bob hat gesagt er will prefer encrypted also Bob hat gesagt er will prefer encrypted ich gehe jetzt noch also eine Kleinigkeit es gibt noch einen Feature das werde ich sofort erklären ich gehe noch mal auf Preferences und mache bei Bob auch mal zur Symmetrie schalte ich das ab hatte ich das bei Alice auch abgeschaltet ich habe es aber beiden abgeschaltet ok hier hat jetzt Alice Bob eine verschlüsselte Mail geschickt das Ding ist wenn man da replied dann sagt die Autoscript Specification soll man unabhängig von dem Setting was da kam innerhalb der Encryption Geschichte bleiben also wenn es sozusagen Encrypted war und ich mache einen Reply auf eine Encrypted Mail es wird sozusagen die Recommendation dass man Encrypted bleibt auch wenn die das Setting von der Person also von Alice in diesem Fall eigentlich oder von Bob eigentlich sagt ich prefer to not receive Encrypted Mail ja explizit Encrypted das heißt darauf Encrypted zu antworten ist sozusagen normalerweise guter Stil und deswegen ist jetzt hier dieser Encrypt-Button auch enabled ich nehme den jetzt aber mal raus das war jetzt unverschlüsselt und wenn ich das ich kann das sozusagen forsten und jetzt ist, oh jetzt habe ich Alice an Alice geschickt naja ich schau mal eine neue Mail damit das nicht was hast du? ja ja gucken wir gleich ohne Preferences ohne Preferencrypt so und wenn ich jetzt auf hier wenn jetzt hier Bob diese Mail sieht muss kurz hier zurück ob diese Mail sieht dann ist tatsächlich auch der Reply nicht Encrypted weil jetzt sind sozusagen beide wieder auf dem Status dass sie das preferen das nicht zu kriegen und die Idee dahinter ist das ist eben speziell diese, sag ich mal Level 0 Geschichte dass wir das in verschiedene Levels aufteilen die Idee dahinter ist, dass wir auf jeden Fall den Schlüssel austauschen im Background haben, dass der sozusagen schon mal funktioniert und dass die User so eine Art von Handlungsfähigkeit haben und dass sie auf sie können jetzt Encryption verwenden aber es ist noch ein bewusster Akt das ist nicht bei Default sozusagen da muss ich schon zu den Preferences gehen und sagen ich möchte das immer so haben und das machen wir deswegen weil wir eben in Level 0 noch keinen Multidivice wir haben noch keinen Pairing zwischen zwei Devices da haben wir zwar schon eine Diskussion und wissen auch schon ungefähr wie wir das machen wollen aber das ist sozusagen in Level 0 noch nicht da sozusagen eine andere Komplexitätsstufe machen wir das derzeit so, dass die Entscheidung tatsächlich eine Bewusste ist und es kann auch sein, dass ich im Zuge der Deployments, das zeigt, dass es auch erstmal eine Weile so bleiben wird weil es gibt alle möglichen Situationen die Leute haben welche Make Lines sie verwenden und letztendlich wissen sie das selbst dann ganz gut also ich habe in meinem Setup zum Beispiel weiß ich, dass es okay, da habe ich Prefer Encrypt Yes, also ich will, ich sage allen ja ja, verstüttelt einfach, es ist alles okay, ich komme klar aber das wird nicht für alle gelten und bei Default sollte es halt nicht gelten in Level 0 genau eine Sache die hier nicht in dem die hier noch nicht drin ist und die wir jetzt im März bereits einigermaßen sozusagen im Konsens diskutiert haben ist dass wir in Level 0 noch eine Sache hinzufügen die wichtig ist, das nennt sich Transfer Key also wir wollen Leuten ermöglichen dass sie manuell quasi ein Pairing betreiben also die ganzen, sag ich mal, Multiplikatoren die vielleicht schon PGP PGP Keys haben und das vielleicht anderen Leuten beibringen wollen wie sie jetzt zum Beispiel dann Autocrypt nutzen oder so, die sollen halt in der Lage sein auch in ihrem eigenen Setup das zu benutzen und und dazu brauchen sie aber irgendwie die Möglichkeit diesen Key auch auf ein anderes Device zu bringen also wenn ich in Level 9 mit Open Key Chain ich weiß nicht wer das von euch kennt Open Key Chain und Android und so Herr Dominik, wenn ich da den Key importieren will und ich habe ihn aber in einigmail erzeugt, irgendwie, da muss ich ihn ja irgendwie rauskriegen so und wenn wir jetzt noch keinen Multidivice Pairing haben was etabliert ist dann müssen wir irgendeine Möglichkeit geben das heißt, das ist noch eine Sache die bei der Konfiguration hinzukommt also abgesehen von dem was ihr gesehen habt wird es noch einen Button geben der halt Transfer Key heißt und der erzeugt ein bestimmtes, spezifiziertes Format, was dann von allen Moors gelesen werden kann, die Autocrypt unterstützen und das kann man dann entweder auf irgendwie Storage tun oder auf ein USB Stick und halt zu dem anderen Device irgendwie transferieren oder irgendeinem anderen Kanal, den man sich ausdenkt und das wird auch mit einem Backup Code laufen also sprich so eine Art von Passphrase die ich verwende und das bedeutet dass ich diese Mail, die wird dann das ist eine sogenannte self sent mail das heißt, wenn ich mein Key generiere als Autocrypt Client und ein Transfer Key mache, dann kann ich wählen dass das an mich selbst geschickt wird und damit taucht es in meinem iMac Folder auf meiner Inbox damit kann der andere Client das feststellen, dass da plötzlich diese Mail ist und kann halt diesen Key lesen und bei sich importieren, das ist sozusagen so die Grundidee, aber das ist halbmanuell das ist sozusagen in Level 0 ist das nicht jetzt irgendwie komplett automatisiert das einzige was wir da machen ist quasi das Format zu spezifizieren und dann hängt es ein bisschen von den verschiedenen Moors ab wie sie das genau dem User anbieten, wo er das hinbringen kann also sei es Copy Paste oder sei es irgendwie weil auf dem Android hat man nicht unbedingt ein USB Stick und so, das ist ja alles ein bisschen unterschiedlich aber wir gehen davon aus dass die Leute, die sich einen Multidivis-Setting herstellen wollen dann in der Lage sind irgendwie das was sie aus dem Programm rauskriegen zu dem anderen Device irgendwie zu bringen und das ist dann die Geschichte die in Level 1 automatisiert sein soll also dass ich da sagen kann wenn ich ein Level 1 Client installiere dass der automatisch den anderen Level 1 Client bemerkt dass der da ist wahrscheinlich über IMAP und dann die Synchronisation zwischen den Ende zu Ende verschlüsselt also zwischen den beiden Mail Clients der Key ausgetauscht wird und dann muss ich mir als User auch keinen Backup Code oder irgendwas merken es wird einfach quasi auf das andere Device gemacht und das Pairing findet dann noch über einen typischen Diffy Helmen nochmal Zahlen gesicherten also wo ich quasi Passwords verifizieren muss 2x4 Zahlen dass die auf beiden Devices gleich aussehen und so was, das kennt ihr wahrscheinlich aber das ist eben Level 1 und wir haben uns deswegen entschieden das so zu teilen weil die meisten Mail Clients die derzeit entwickelt werden werden auf relativ wenig sage ich mal Manpower entwickelt das E-Mail-Ecosystem ist jetzt nicht so dass irgendwie 5 Leute fulltime an Enigmail sitzen und irgendwas machen wahrscheinlich kennen auch einige von euch die etwas vertragte Situation mit Thunderbird, was seit 2 Jahren so Mozilla irgendwie loswerden will und was sozusagen nicht so richtig in eine größere Weiterentwicklung kommt und auch eine relativ alte Software ist und das heißt größere Änderungen zu machen ist für die meisten Mail-Programme jetzt nicht mal einfach so eine Sache die sie mal eben machen können in 1, 2 Monaten und deswegen haben wir quasi diesen Cut gemacht im zweiten Schritt und gucken halt dass das dann gut funktioniert kriegen auch ein bisschen mehr Field Experience von dem wie das läuft und den zweiten Schritt der basiert dann eben auf diesem dass man schon das Transfer-Key Format definiert hat das wird dann weiterhin gelten nur es wird dann eben automatisiert ausgetauscht zwischen den Devices aber der Teil fehlt in Level 1 genau also ich denke dass diese diese Spezialität dieses mit dem Prefer Encrypt das ist eine Sache auf die haben wir sicherlich sowas wie 30, 40% unserer Diskussionen drehten sich um dieses Thema wie man das genau macht mit dem Prefer Encrypt und auch Multi-Device und das ist eine Sache die zum Beispiel bei bei WKD also Web-Key Directory also was die Nupel-G-Leute machen mit dem Provider-Look-Up die da halt erstmal nicht dabei ist also da gibt's sozusagen ich hab den Key und dann verschlüsse ich halt einfach und ob die andere Seite damit klar kommt oder nicht ist halt nicht mein Problem ich verschlüsse da halt weil ich hab ja den Key das heißt, dass da sozusagen die User kommunizieren können miteinander auf der Ebene was sie eigentlich wollen in ihrem Setting das findet da nicht statt könnte aber theoretisch stattfinden also da reden wir auch mit Leuten die das jetzt sind aus dem Umfeld und bei PEP bin ich mir auch nicht ganz sicher ich glaube da ist auch so eine Präferenz wenn man den Key hat zu verschlüsseln oder? ja ja genau und das ist halt eine Sache da gibt's sicherlich eine Differenz sozusagen dass wir da eben aus unseren usability-Überlegungen da nicht so ein Freund von sind einfach immer alles automatisch zu verschlüsseln weil das halt in realen Situationen Leute einfach extrem nervt dann dass du das Ding ausschalten kannst wir werden noch sehen ob die Mail ankam ich weiß es nicht Moment, was hast du gemacht du hast einfach irgendeine beliebige From-Adresse mit deinem nein nein, aber du hast es über deinen eigenen Mail-Saver der also schlecht konfiguriert ist weil eigentlich soll das zurückweisen, aber gut ja ah ok, ja ja gut aber da haben die großen Provider natürlich andere Policies das kannst du mit Dima nicht machen ok sag du mal kam nicht an ja gut, aber Inria würde ich jetzt auch nicht einen guten Mail-Saver, klar ja ja gut, die andere Frage ist ob man als Mail-Cline sich überhaupt Spam-Mails anschaut, im Hinblick auf irgendwie Kies rausziehen wahrscheinlich wird man Sachen die als Spam-Classifiziert sind, sich auch gar nicht anschauen weil es ist relativ klar, dass da irgendwie Wiruszeug drinstehen kann aber klar, ich meine das Problem ist ich würde jetzt ganz gerne ich gucke nicht so gerne meine Mail-Folder während es weißt du, es war ja es ist im Spam-Folder gelandet, genau also Dima sozusagen akzeptiert das so nicht so ein weiteres also das wäre jetzt, also ich sag mal so Autocrypt hat schon das Ding, dass man ich denke das, ich weiß nicht ob es explizit steht aber es ist relativ klar, dass wir ja gut, aber ja ok, also es ist sicherlich wahr also vielleicht ein Schaubild diese Alice-Bob-Geschichten, die wir gemacht haben jetzt auch die Englisch Images, also hier gibt es weiß nicht ob das groß genug ist so sieht das sozusagen in den also links ist Alice, ist das so noch groß genug? Nee, ne? Ok, also wenn Alice-Bob hier eine Mail schickt, dann ist dieser Autocrypt da dabei und da steht eben abgesehen mit dem Key, das ist ein Base64 encoded bei näherer PGP Key, steht hier eben noch das Prefer Encrypted Yes in dem Fall, also sprich die andere Seite soll an mich verschlüsseln ja ja Moment, aber zum Beispiel jetzt wenn das zum Beispiel also wenn jetzt zum Beispiel, das Problem ist jetzt also in real, der Mail-Saver von in real, keine Ahnung, aber wenn ich also wir gucken uns halt an was irgendwie Posteo was macht, WebDE macht, was macht Gmail was machen die ganzen großen Mail-Provider und wenn wir das Problem haben, hier eine Gmail-Adresse zu haben und das zum Beispiel an eine Posteo-Adresse zu schicken oder an irgendwelche anderen die werden diese Mail, da kannst du nicht einfach im Namen von Gmail, die immer Dickim signieren und was die Provider miteinander abchecken, einfach so Sachen schicken, das heißt nicht, dass es nicht irgendwelche Setups gibt wie von Inria und ZTC, wo man das doch irgendwie hinkriegt, aber wir gucken halt schon auf die Provider, das heißt also auf die großen Provider was wie ja, SPF, genau also, eine Sache die wir aber das kommt halt, also das ist sicherlich eine Sache die auf jeden Fall sozusagen in der Praxis getestet werden muss, ein Problem ist auf jeden Fall, das hatten wir in unserer Gruppe auch, wir sind natürlich von den Leuten die da zusammenkommen also eben aus Enigmel, K9 MailPile, diverse andere Geschichten, die es sind natürlich Leute die irgendwie mit Mail schon ewig Sachen machen, die irgendwie verschiedene Mail-Server benutzen, verschiedene Identitäten haben, ich habe auch irgendwie vier verschiedene Mail-Accounts die ich benutze und so was, das ist aber nicht das was normalerweise Leute machen also das heißt die meisten Leute haben halt nicht die Setups und haben auch nicht Linux und haben auch nicht alles mögliche und das Problem ist halt wenn ich jetzt in der Diskussion damit anfange naja ich nehme jetzt hier diesen ZTC und dann irgendwie Inria und irgendwelche Mail-Server und dann klappt das nicht und so das ist ein Problem, das muss man sich anschauen, aber man muss sich auch immer anschauen was ist sozusagen der etwas allgemeinere Problem ist ja, also was haben Leute wirklich weil so Provider wie Gmail und auch GMX die haben natürlich was dagegen dass Sachen mit Falschen fromverschickt werden wegen Fishing und so was, also da kommen sozusagen Leute an Viren und alles mögliche und ja genau und das insofern ist auch die Frage wo sich das hinentwickelt und meiner Ansicht nach in den letzten Jahren sind die ganzen Policies da tendenziell alle eher strikter geworden also die ich weiß ja ja kann nichts verwerfen, ja ja das ist prinzipiell, also vielleicht ganz kurz für die die es jetzt noch nicht so ganz gut kennen, was auch um Fishing zu vermeiden und genau dieses dass irgendjemand einfach eine from-Adresse nimmt die nicht stimmt, haben halt verschiedene Provider das eingeführt dass sie eine Signatur auf die Header machen, genau wie du gesagt hast das heißt domain key identified mail, das heißt da steht im Prinzip im DNS für den Provider einem Public Key in einer bestimmten kanonischen Weise wo ich also rankomme und dann kann ich also wenn ich eine Mail kriege wo ein bestimmter from steht, nachgucken ist die Signatur korrekt, das heißt ist diese from-Adresse tatsächlich von dieser Domain gekommen, ja das wurde vor 3 Jahren oder 5 Jahren, also was 4 Jahre, 5 Jahre standardisiert und wird von vielen verwendet, nicht von vielen, aber von vielen, also von Gmail vor allen Dingen auch und ist aber eine Sache und da ist sozusagen das Problem, das ist eine Sache die vor allen Dingen zwischen den Providern funktioniert, also du kannst sozusagen ein Provider kriegt von einem anderen Provider eine Mail und der sieht dann dieses, ah das kommt von Gmail und macht dann diese Verifikation, dass die Header stimmen, ja, du kannst aber dann wenn diese Mail weiter wandert zum End Device diese dicken Verifikationen nicht mehr ganz so stabil machen und das liegt daran, dass zum Beispiel Microsoft Exchange, was auch eine Realität ist, ganz gerne Sachen umschreibt und dann hast du sozusagen der Provider kann zwar noch checken, dass es dann von Gmail kommt, aber das ist ein Exchange Server und dann schickt er das weiter auf das End Device und das End Device guckt dann, ich gucke mal ob die Signatur stimmt und die stimmt dann nicht, weil das sozusagen genau also nehmen wir an Gmail würde sich genau, genau, das ist so ein einigen Fällen geht es, ich sag mal so du kannst zumindest, also es war im Prinzip genau der Ansatz den ich auch vor einigen Monaten favorisiert hab, aber ich weiß von Leuten die da ein bisschen mehr drin hängen noch in dem Mail Ecosystem die sagen, naja, die come auf End Devices ist nicht ganz so einfach, also das ist nicht so eine, End Device ist gar keins, ah ok Provider Level naja klar also auf jeden Fall sind sag ich mal Sachen die, wenn es, also es gibt nicht nur, das Problem ist gar nicht so sehr also ich würde sagen, ob man jetzt den Encrypt Default Status auf Ja, Prefer Encrypt Yes oder No ändert für jemanden, das ist zwar unschön, aber noch nicht so schlimm als wenn ich einen Key unterjuble der dann zur Unreadable Mail führt dann kann ich also sozusagen einfach euch allen irgendwie eine Mail schicken so tun, als wenn der Key von zwar sich geändert hat und dann das nächste mal, wenn ihr dann irgendwie ihr eine Mail schickt, kann sie es halt nicht lesen also sozusagen so eine Art Denial of Service an der Stelle das heißt das Problem ist schon klar, ja also wenn ich anfangen kann einfach wild Mail sich die gingen zu schicken und die kommen alle an und werden alle gesehen dann habe ich ein Problem und die These die ich da hab ist, das ist zumindest sag ich mal im größeren Ecosystem ja, du kannst nicht einfach, also jetzt in real TTC, ok, aber du kannst nicht einfach irgendwie als Gmail an Posteo einfach irgendeine Mail schicken und Posteo sagt, jo jo, passt schon das kommt von Gmail, alles klar sondern die werden über Spam- Auswahlverfahren dann irgendwie zumindest lecker ordnet und damit sieht sie dann der Mail-Klein nicht, also er würde sicherlich nicht den Spam-Folder das haben wir schon gesagt, er würde nicht in den Spam-Folder gucken, um sich die Keys und so was rauszuziehen also in dem Sinne nicht jede reinkommende Mail sondern jede reinkommende Mail die ist in meiner Inbox schafft die nicht Spam ist, ja die schau ich mir an im Bezug auf, so kurz nachher zum Konzept also hier ist es im Header, hier ist es im Header und in der in der zweiten Mail also wenn Alice bobbende Mail geschickt hat und dann bobbende Mail zurück schickt dann ist bereits dann kann die bereits verschlossen sein weil Alice hat ja schon ihren Key mitgeteilt hier, das heißt bobb kann dann in dem Fall sofort an Alice quasi im Reply encrypten und macht das auch in diesem Fall weil hier Prefer Encrypted jetzt steht, ja der Vorteil ist, dass zwar Leute die Enigma installiert haben und vielleicht auch K9 mit Attachments wo ihr Mail Kleine anbietet die zu importieren was anfangen können aber die ganzen Leute die nicht Enigma sind ja auch einige nicht Enigma oder K9 oder irgendein der Verschlüsselungs-Kleins haben die kriegen dann einfach irgendwie Punkt Eski irgendein komische Datei und das löst bei vielen Leuten Irritation aus wenn da irgendwelche komischen Attachments sind weil eine der Geschichten die Usern erzählt wird ist, wenn du komische Attachments grist dann ist das ein Spam oder ist irgendwie ein Problem das heißt wenn du nicht einen Verschlüsselungen Kleinen tast dann siehst du quasi in einem so und das ist die eine der es gab glaube ich zwei bis drei Sachen es war ein wesentlicher Punkt warum wir sagen wir machen das in den Headern weil das ist eigentlich eine Sache die die Mail-Kleins miteinander verhandeln sozusagen also das muss der user nicht der muss keine Keys sehen sozusagen es hat natürlich auch den Nachteil das für die ich sage mal jetzt für 2017 wenn es dann AutoCrip-fähige Kleins gibt dann können die mit existieren einen PGP wenn ich jetzt irgendein tolles E-Max oder irgendwas anderes ein Setup habe wo ich PGP Sachen mache dann kriege ich das quasi im Header kann mit meinem Tooling aber nichts anfangen während einen Attachment könnte ich einfach doppelklicken oder irgendwas machen und es würde einfach importieren das heißt da ist dann sozusagen die Interoperabilität mit der existierenden mit dem existierenden PGP Tooling nicht so gut aber da ist halt auch ich sage mal so dass da ist zumindest jetzt von den AutoCrip-Leuten einfach die Ansicht gut wir wollen ja viel mehr User bringen auf Verschlüsselung das heißt an der Stelle müssen halt die Leute die schon PGP-fähige Kleins haben halt ein bisschen was noch in einem Tooling machen dass sie halt diese dass sie diesen Key halt lesen können aus dem Header statt aus dem Attachment ist auch nicht so schwierig das ist auch der Teil den ich jetzt noch im Hands on weil das Ganze ist es gibt eine quasi nicht direkt Referenzimplementierung aber zumindest eine Implementierung mit der man auch umspielen kann und die ich auch in meinem eigenen Mail Setup quasi in Produktion hab aber das ist natürlich auch ein spezielles Mail Setup und da ist es dann einfach so dass ich den Tool sagen kann hier ist die Mail und dann kommt zum Schluss einfach ein Key raus oder ich kann den einfach dann in GPG importen das heißt ich kann das in alle möglichen Setups die das halt irgendwie schon können für die Leute die schon irgendwie PGP-Kleins haben ist der Aufwand nicht sehr groß einfach diesen Key zu importieren aber eben aus besagten Grund ist es nicht einfach ein Attachment weil das die meisten anderen User ein Problem ist ja Frage wie geht ihr denn mit Keys um die sich ändern also wenn ein Nutzer jetzt ein neues Handy kriegt der keine Ahnung hat der richtet seinen Mail Account ein dieser neue Klein den er auch nutzt ist auch Autocrypt fähig er kriegt aber jetzt einen neuen Key weil der Autocrypt Klein sagt ihm er stellt auch einen Key dann kannst du verschlüsselt mit deinen Freunden senden aber natürlich hat er vorher kein Backup gemacht noch kein QR-Code weil den ersten Klein ist das noch nicht drin oder whatever was zeigt ihr dann an wenn es der Key auf der Gegenseite ändert genau Willkommen im Team das sind genau die Fragen die wir auch wo es sozusagen immer sehr viel drum geht um dieses User macht einfach irgendwas an weiße behaupten was er macht und hat einfach ein neues Device und sagt Enable Autocrypt oder was auch immer und eine Antwort darauf ist dass wir eine Recommendation drin haben das ganze ist ja wenn ihr auf autocrypt.org geht und dann hier auf Level 0 Support da sind sozusagen die derzeitigen Sachen festgehalten und da gibt es halt eine Recommendation dass wenn wenn ein Autocrypt Klein ein Autocrypt fähiger Klein quasi anfängt zu arbeiten also ein neues Release ein Autocrypt oder ein neues Device dann soll der die Inbox checken und gucken ob sozusagen schon Mails rausgeschickt wurden, der muss ja irgendwie zugekriegen auf einem App, muss ihn ja irgendwie konfigurieren über Autoconfig oder wie auch immer und in dem Moment kann er ja schon mal feststellen dass zumindest schon mal ein Autocrypt Klein aktiv war ist schon mal ein Indiz sozusagen dass ich vielleicht nicht einfach nur den Default Screen zeige und das zweite ist dass wenn der einen neuen Key generiert und den dann dran hängt dann wird der in Zukunft benutzt werden und es gibt auch keine Warnung also sprich wenn Alice ein neues Device hat und dort eine und dort Autocrypt einrichtet sich einen neuen Key generiert und dann Bob eine Mail schickt genau jetzt in unserem Szenario und dann wird Bob einfach diesen neuen Key nehmen so, da wird sich also nicht irgendwie jetzt wundern oder so, da würde ich einfach sagen na gut, es gibt irgendwie einen neuen Key weswegen auch immer und den nehme ich jetzt einfach das ist sozusagen genau der Punkt warum die sich nicht um aktive Attacken zu kümmern ist an der Stelle natürlich massiv vereinfacht weil sonst würde man sagen, ja kann der Provaler einfach mal einen anderen Key dran hängen und dann habe ich ein Problem um benommen da trotzdem eine Warnung anzuzeigen oder irgendwas, das ist sozusagen aber man kennt es von Signal und Usability Studies zum Beispiel das halt wenn man in so einer Gruppe ist in Signal mit 10 Leuten oder 20 Leuten, ich habe das oft gemacht und dann alle möglichen Leute ihre Keys wechseln weil sie ein neues Handy haben und so weiter und wer macht dann wirklich die Verifikation die angeraten ist von Signal da hat sich irgendwas geändert, das ist irgendwie Rot oder hat irgendwie ein Warnfarbe oder so aber das macht man in der Regel nicht, es macht kaum jemand man sieht dann quasi diese sich ändern in Keys und denkt sich ja wird schon passen verify okay, da gibt es sehr interessante Studies wie User tatsächlich darauf reagieren das ist total fatal ich habe auch einen kleinen Nachfrage dazu also ja, ich weiß, die Nutzer schauen sich das nicht an und nutzen es einfach was dann aber auch dazu führt, man kann ihn jeder Art Key unterschieben ich kenne es nur jetzt aus meiner Praxis weil ich halt einfach in der Woche so 3-5 Keys unterschreibe weil wir das halt relativ heftig nutzen und ich habe neulich einen Kollegen gehabt von dem ich ein Key unterschrieben habe der mir extra gesagt hat bitte geh auf den Keyserver, ich mach das eh mal und prüfe gegen den ganzen String des Hashes für den PGB Key weil nämlich er in so einem Botrun dabei war der über die Keyserver gelaufen ist und da gab es einfach einen Botrun der über diverse Keyserver gelaufen ist und versucht hat die letzten 8 Stellen des Hashes eben nachzubauen und ne Kulissen zu bilden und es ist ihm für deren Key auch gelungen das heißt, es gibt jetzt nicht 2-mal nur seinen Key unter der E-Mail-Adresse auf dem Keyserver sondern die letzten 8 Stellen passen auch genau zusammen das heißt da gibt es schon Probleme im aktuell bestehenden System die extrem problematisch sind in den Keyservern wie versucht Autocrypter vielleicht darauf zu reagieren zu sagen keine Ahnung, es gibt jetzt einen neuen Key der hat ein Hashes, der sieht vielleicht so ähnlich aus dann muss ich ihm Nutzer eigentlich ne Warnung geben weil dann hat vielleicht aktiv jemand versucht mich zu betrügen oder so naja, das Problem ist ja, also jetzt gerade das Keyserver Beispiel was du gerade gebracht hast da ist es natürlich so, dass es einfach sichtbar ist bei Autocrypt sind die Keys einfach für niemanden erst mal sichtbar wenn Alice Bob ne Mail schickt dann ist dieser Key außer bei Alice und Bob's Provider nirgends wo irgendwie gespeichert es gibt also sozusagen keine konzentralen Ort wo ich einfach hingehen kann und anfangen kann überhaupt irgendwelche Hashes-Kulissen zu berechnen weil ich kenn den Key nicht aber ich kann natürlich als jemand, wenn du mir jetzt ne Mail schickst und irgendwie jetzt anzufangen deinen Key irgendwie Fingerprint-mäßig irgendwas zu machen aber das würde mir jetzt noch nicht helfen deinen Key auszutauschen also ich könnte sozusagen zu keinem Keyserver gehen irgendwas uploaden oder so weil deine Conversations-Partner Partnerinnen werden sich nur daran orientieren, was sie von dir als Mail bekommen, was darin steht und das ist halt ein relativ authentisierter Strang, weil du musst dich gegenüber deinem Provider authentisieren sich gegenseitig und das heißt es gibt nicht so ohne weiteres die Möglichkeit einer dritten Person irgendwie zu sagen dein Key ist das und das ist auch ein bisschen die Frage die Christian schon aufgeworfen hat, aber also es gibt ziemlich viele FCs für E-Mail Ja, also auch eine alten E-Mail-RFC 822 und in der aktualisierten Fassung 532 steht drin, dass die maximale Länge eines Headers darf nicht über 998 Zeichen sein und sie soll nicht über 78 Zeichen sein und dann hab ich grad mal geguckt wie groß ist denn mein PGP Public Key und der ist 4.773 Zeilen Zeichen, Entschuldigung Zeichen, der ist immer noch 5 mal länger als was der Standort euch maximale erlaubt aber meiner Ansicht nach ich hab es jetzt nicht genau im Kopf aber soweit ich weiß die sind 998 sowas also das wird von allen möglichen Leuten werden schon größere Header verwendet also Exchange voran die haben 10k Header und sowas es geht um das Limit pro Zeile nicht um das gesamte Limit für den Header Ach so, ja gut, aber das ist, sorry ja, ja, ja, warte ein moment wie das nicht weit mit sind, deswegen hab ich's grad noch Ja, ja, aber das, klar aber zum Beispiel, ich zeig es euch mal ganz kurz also wenn ich zum Beispiel hier Make Header und ich mach jetzt von meiner Eigenemail-Adressen ein, dann sieht das halt so aus und das wird also hier umgebrochen einfach dann zählt es nicht und das haben wir auch schon mit allen möglichen Servern getestet im Provider und das geht überall durch, auch bei Gmail und überall und doch klar, doch klar also Dickham hat ne genau, das gehört zum Autocrypt Header ja, durch diese Inventierung hier also du kannst quasi einen Header hier mit ich glaube Backslash R, Backslash N oder so, wenn du sicher gehen willst und dann halt hier Inventierung gehört das alles zum selben Value und genau ne, moment, du sagst, das versteh' ich nicht ganz Provider, sag's nochmal Nein, ihr wollt ihr wollt Provideragnostisch sein genau, okay das heißt die Frage, die erfahr ich mir jetzt eigentlich nach DNSsec und irgendwelchen Schlüsselaustausch in DNS ist irrelevant soll alles nur in den E-Mail Header also wir bauen quasi einfach auf der Tatsache, dass einigermaßen die eine E-Mail Message von A nach B zu schicken zwar nicht perfekt, aber einigermaßen gesichert ist zwischen den Providern und verschicken dann einfach da drin die Keys und daran unterscheidet sich es auch von allen Systemen, die quasi irgendwelche zentralen Lockups haben sowohl Webkey Directory als auch Keysaver und das heißt nicht, dass es nicht ohne Probleme ist es gibt Probleme also es gibt, wenn ihr in DNSsec guckt oder so dann schreiben wir verschiedene Risiken da gibt's ein ganzes Potential Ecosystem Dangerous auf Autocraft gibt's eine ganze Menge Sachen, die wir sozusagen die uns schon aufgefallen sind wo sozusagen ein bisschen problematische Areas sind und so also die genau, aber das ist sozusagen eine sehr minimale Geschichte also ich glaube das wird nicht so schwierig sein Provider zu überzeugen dass sie in ihrem bestehenden Decam zu euch noch diesen Header sein da müssen sie wirklich nur eine Konfiguration ändern das ändert nicht die Art der Operation die sie betreiben sie müssen nicht plötzlich irgendwie als Certificate Authority Keys ausliefern oder sowas genau gut also also ich hoffe, dass ich jetzt ein bisschen vermitteln konnte wo derzeit die Email Encryption Ansätze stehen Webkey Directory Pep Engine Dark Internet Mail Extension also ich weiß es nicht, ich hab's gelesen, die haben sich extrem viele Gedanken gemacht also wahrscheinlich kennt ihr diese Story um Lava Bit wer ist der Allison so und so der Typ der seinen Laden dazu gemacht hat Lava Bit glaube ich oder wie es ist Lava Bit oder so im Zuge des Asnorgengeschichte, weil er irgendwie sein SSL Route Certificat sein Certificat rausrücken sollte damit die irgendwie alles entschlüsseln können und sowas und der hat zusammen ein Jahr lang oder noch länger an was gearbeitet das heißt Dark Internet Mail Exchange Environment oder sowas genau und das hat eine ganze Menge interessante Gedanken drin eine ganze Menge interessante Skriptodesign ist aber genauso wie aus meiner Sicht jetzt ist genauso wie ganz viele andere Ansätze hat das das Problem dass sich quasi die gesamte Welt ändern muss es gab sozusagen schon verschiedene Ansätze was besseres zu machen als Email mit Verschlüsselung und so die aber den Ansatz verfolgen ihr müsst sowohl in diesem Fall daimfähige Clients haben und ihr müsst auch daimfähiges Server haben also du musst quasi die gesamte Infrastruktur in der Stelle ändern du musst sowohl die Provider ändern als auch die Clients und das ist halt eine relativ extrem hohe Uptake also da gibt es sozusagen keinen richtigen incrementellen Path irgendwie zu einer besseren Situation zu kommen und wenn man einen schrittweisen Weg geht dann ist das alles ein bisschen nerviger weil man kann nicht einfach sagen ihr müsst jetzt alle das installiert haben oder ihr müsst alle irgendwie folgende Software benutzen oder sowas das ist schade dass man das nicht sagen kann aber andererseits hat man eben den Vorteil dass man einen schrittweisen Weg hat mit dem Existieren und daim hat eben das Problem dass du entweder daim machst oder das jetzige Ecosystem und es gibt sozusagen keinen richtigen incrementellen Weg dahin und insofern glaube ich ist es eine sehr schwierige schwierige Ansatz einfach auch wenn da sehr viele spannende Sachen drinstehen ich habe es mal durchgelesen war recht beeindruckt was die sich alles für Gedanken gemacht haben auch zu spezifizieren aber bin halt ein bisschen skeptisch was den Ansatz an sich angeht um die Welt so ungefähr es ist halt immer schwierig sowas durchzusetzen ja ich bin jetzt noch ein bisschen da ja und wann sind die leitenden Talks? ok es war jetzt auch schon ne es war noch, hatte hier jemand? ne ok gut also wie gesagt ich habe jetzt meiner Ansicht nach so ungefähr also die 3 Sachen die 3 Projekte die quasi da unterwegs sind derzeit angerissen ein bisschen erzählt was irgendwie aus dem wie ich das bei Autocryp wahrnehme was da sozusagen so die Ansätze sind und wo wir gerade stehen wir haben jetzt nächste Woche treffen wir uns wahrscheinlich wieder ein paar Leute zumindest um das sozusagen weiter auch in die auch geht es auch nochmal um Webmail wie man das da reinbringt und das kennen vielleicht einige Melvylope Melvylope ist ein Plugin was man bei Gmx und bei Postero und auch bei anderen verwenden kann das ist quasi ein Plugin für Chrome und Firefox und es ist eigentlich so eine Art Mua im Browser, also ein Mail-Programm im Browser weil es bedeutet, dass wenn ich dieses Plugin installiere und damit Ende zu Ende Verschlüsselung mache über Webmail dass der Provider nicht diese Kontrolle über den Code hat weil ich installiere das Plugin im Firefox oder im Chrome und das kann der Provider also Postero oder andere kann das nicht verändern dass das sozusagen auf meiner lokalen Maschine installiert und dadurch kriege ich dann quasi auch ein Webmail so eine gewisse Ende zu Ende Sicherheit rein und das wollen wir halt auch möglichst mit Autocrypt kompatibel machen dann zum Beispiel, dass das halt da dann auch gemacht wird, das Ganze ist also eines der Probleme ist, dass eigentlich alle Plattformen und auch teilweise die Mail-Programme auch zum Beispiel eine recht unterschiedliche Architektur haben zum Beispiel auf Android K9 die Mail-App die man da benutzt die hat zum Beispiel das ganze Key-Management was wir ja auch machen, was nur recht verborgen ist so, hat das ausgelagert in Open Keychain was eine eigene App ist das heißt da werden dann die Keys auch da kann ich auch Verification machen bezüglich Keys und so was anderes als so was wie zum Beispiel AnicMail wo das ein Plug-in ist, wo auch das Key-Management da ist, was dann aber wiederum auch GPG verwendet das ist eine spezielle Geschichte bei IOS, also Apple ist die Architektur von den Mail-Programmen wieder ein bisschen anders weil da nutzen zum Beispiel teilweise Mail-Programme das Feature, das man verschlüsselt über die iCloud über die Apple-Geschichte die Weiße synchronisieren kann und da auch die Keys das heißt, alle diese Geschichten sind alle immer ein bisschen unterschiedlich und deswegen haben wir da immer auch eine ganze Menge Diskussionen um erstmal zu verstehen wie überhaupt die andere Architektur funktioniert um dann zu überlegen, wie kann man was eigentlich am einfachsten machen also ein kleines Beispiel wenn ich irgendwie sage ich mache irgendwas mit iMap zum Beispiel was bei uns halt auch beim Multidivice kommt dann ist es zum Beispiel bei K9 tricky, wenn das dann irgendwie Open Keychain machen muss weil Open Keychain hat überhaupt kein iMap-Zugriff, das macht nur die Key Verwaltung, wenn da jetzt irgendwas mit iMap laufen sollte, dann wäre das ein Problem während K9 wiederum nichts mit Keys macht, das dedikiert jetzt alles anders als Open Keychain das heißt, wenn ich dann irgendwas mache mit iMap, dann muss ich mir halt überlegen wie wir das mal bauen in diese spezielle Android-Situation und das ist eben je nachdem was man genau anguckt, Enigmail was auf verschiedenen Plattformen läuft oder Webmail sind das alles recht unterschiedliche Konstruktionen also die Webmail-Konstruktionen von Mail-Programmen ist zum Beispiel auch wieder völlig anders also wie das sozusagen da funktioniert und diese Andersartigkeiten die sind sozusagen symptomatisch für das e-mail-Ikosystem die sind oft als irgendwas Blödes also als irgendwas was halt hinderlich ist dadurch kann man keine Innovationen sozusagen in die Leute bringen angesehen ich sehe es aber eben auch genau als einen Effekt dieser ganzen Federation dass es eben nicht in der Kontrolle einer Entität ist, die dann sozusagen die Welt einfach definieren kann so wie WhatsApp zum Beispiel WhatsApp ist halt die Quelle aller WhatsApp-Clients so ungefähr das wird immer auch definieren wie irgendwas läuft aber hat natürlich dann auch bei die Software eine ziemliche Kontrolle das heißt wenn dann gesagt wird, da muss irgendwas eingebaut werden dann muss man halt letztendlich nur zu WhatsApp gehen und die irgendwie mehr oder minder freundlich überzeugen dass sie das tun und hat es damit erreicht während wenn das jetzt der BND versucht zum Beispiel die Email-Clients dann hätte er sozusagen echt ein Problem so einfach werden das einzubauen genau also es ist ein bisschen so eine stärke schwächer Geschichte und wir sehen das eigentlich als ein Feature dass es sozusagen diese Sachen gibt aber es erfordert eben relativ viel miteinander reden und verstehen wie das funktioniert und mittlerweile sind zumindest die Leute die damit beschäftigt sind da ganz guter Dinge dass ich sozusagen klappen kann