018 – Kryptografie

ZLU KDHWWHQ GLHVH IROJH YHUVFKOXHVVHOQ NRHQQHQ KDEHQ ZLU DEHU QLFKW DXFK ZHQQ HV XP NUBSWRJUDILH JHKW LQIRUPDWLNHU MRKDQQHV HUNODHUW KHXWH ZLH PDQ QDFKULFKWHQ DXVWDXVFKW RKQH GDV MHPDQG DQGHUHV PLWEHNRPPW ZRUXP HV JHKW DVWURQRP IORULDQ XQG ELRLQIRUPDWLNHULQ IUDQCL SODXGHUQ GHUZHLO XHEHU NLVWHQ PLW VFKORHVVHUQ XQG DP HQGH IUDJHQ VLFK DOOH ZDUXP GDV QLFKW HLQIDFKHU JHKW

Verschlüsselte Formeltiere

Und hier ist der direkte mp3-Link zur Folge.

11 thoughts on “018 – Kryptografie

  1. ZLU KDHWWHQ GLHVH IROJH YHUVFKOXHVVHOQ NRHQQHQ KDEHQ ZLU DEHU QLFKW DXFK ZHQQ HV XP NUBSWRJUDILH JHKW LQIRUPDWLNHU MRKDQQHV HUNODHUW KHXWH ZLH PDQ QDFKULFKWHQ DXVWDXVFKW RKQH GDV MHPDQG DQGHUHV PLWEHNRPPW ZRUXP HV JHKW DVWURQRP IORULDQ XQG ELRLQIRUPDWLNHULQ IUDQCL SODXGHUQ GHUZHLO XHEHU NLVWHQ PLW VFKORHVVHUQ XQG DP HQGH IUDJHQ VLFK DOOH ZDUXP GDV QLFKW HLQIDFKHU JHKW

  2. Meine 2 Cent in rot(26):

    Dass die Mailserver sich um die Verschlüsselung kümmern, wollt ihr nicht, weil das Ziel ja eine Ende-zu-Ende-Verschlüsselung ist. Die Nachricht soll meinen Rechner also erst verlassen, wenn der ganze Prozess schon abgeschlossen ist. Darunter liegt dann idealerweise nochmals eine Transportverschlüsselung, und ja, dort geht das “automatisch”, ist aber ein anderes Thema.

    Das gute Bild mit den zwei Schlössern an der Kiste ist das Sinnbild für asynchronen Austausch für synchrone Schlüssel (key exchange)… ein Sinnbild für asynchrone Verschlüsselung mit public und private keys wären zum Beispiel zwei Farbeimer (Primzahlen) die man zu einem Produkt mischt und damit verschlüsselt.

    Gruss aus der Schweiz
    Martin

  3. GDV ELOG YRP VFKOXHVVHO XQG GHP VFKORVV NRPPW JODXEH LFK YRQ ZDX KROODQG, HLQHP GHU JUXHQGHUYDHWHU GHV FFFV. VWUHQJ JHQRPPHQ LVW GLH DOOHUGLQJV IDOVFK, GHQQ VFKOXHVVHO YHUVFKLHEHQ HOHPHQWH LP VFKORVV VR GDVV VLH DXI HLQHU OLQLH VLQG. PDQ NDQQ VRPLW VFKOXHVVHO XQG VFKORVV JHJHQVHLWLJ DEOHLWHQ.

    https://chaosradio.ccc.de/ctv035.html

    DOVR EHL H-PDLO PXVV PDQ CZLVFKHQ HQGH CX HQGH YHUVFKOXHVVHOXQJ XQG WUDQVSRUWYHUVFKOXHVVHOXQJ XQWHUVFKHLGHQ. GDV CZHLWHU IXQNWLRQLHUW JHQDX VR ZLH EHL ZHEVLWHV XQG LVW LQCZLVFKHQ QRUPDO, GDIXHU JHKW GDV DEHU QXU CZLVFKHQ EHLGHQ PRPHQWDQ EHWHLOLJWHQ VHUYHUQ. GDV SUREOHP EHL GHU HQGH CX HQGH YHUVFKOXHVVHOXQJ LVW, GDVV PDLOSURJUDPPH MD QLFKW GLUHNW VSUHFKHQ. VR RGHU VR LVW QDWXHUOLFK GDV PDQ LQ WKH PLGGOH SUREOHP HLQ SUREOHP.

    EHVRQGHUV JXW ZLUG GDV SUREOHP EHL VVK JHORHVW. GRUW VLHKW PDQ EHL GHU HUVWHQ YHUELQGXQJ GHQ SXEOLF NHB GHV VHUYHUV PLW GHP PDQ VLFK JHUDGH YHUELQGHQ ZLOO. EHL ZHLWHUHQ YHUELQGXQJHQ ZLUG GDV QXU QRFK LQWHUQ JHSUXHIW. DHQGHUW VLFK GHU VFKOXHVVHO, VR ZHUGH LFK JHZDUQW XQG NDQQ QLFKW VR HLQIDFK HLQH YHUELQGXQJ DXIEDXHQ.

  4. PRLQ
    HJDO ZR GDV SUREOHP LVW XQG HJDO ZDV GDV SUREOHP LVW HPDLO LVW QLH GLH ORHVXQJ VRQGHUQ LPPHU QXU GDV QDHFKVWH SUREOHP
    GDV QDFKVFKODJHQ RE QRFK SODWC DXI GHP VHUYHU LVW ILQGHW HUVW QDFK GHP YHUVDQG GHU PDLO VWDWW
    HV JLEW HLQH PHWKRGH XP CX SUXHIHQ RE HLQH EHVWLPPWH PDLOERA DXI GHP CLHOVBVWHP EHNDQQW LVW GDV ZDHUH YLHOOHLFKW SDVVHQG XQG SDVVHQG ZLUG GDV DXFK QXU GDCX EHQXWCW XP PDLODGUHVVHQ CX VDPPHOQ IXHU VSDPCZHFNH
    GD YHUVFKOXHVVHOWH PDLOV QDFK YHUOXVW GHV VFKOXHVVHOV QXU QRFK PXHOO VLQG PXVV GHU XVHU DXI VHLQHQ SULYDWH NHB DXISDVVHQ XQG GDV NDQQ HU QXU ZHQQ HU ZHLVV GDVV HV GLHVHQ NHB JLEW
    LFK ZHLVV DXFK QLFKW ZLH PHLQ DXWR IXQNWLRQLHUW DEHU GDVV LFK GHQ VFKOXHVVHO QLFKW YHUOLHUHQ GDUI

    QHWWH LGHH PLW GHP URW

  5. Puh, was für eine Folge. Erst einmal vielen Dank dafür und auch für den Podcast an sich. Nach der letzten Folge zu den Primzahlen hatte ich mich ja schon darauf gefreut auch etwas über Kryptographie zu hören, aber – und das ist nicht böse gemeint – es wäre sinnvoll gewesen vielleicht einen Kryptographen oder ein paar Leute aus der FOSS Community zu diesem Thema zu befragen.

    Ich selbst bin jetzt auch kein Kryptograph (aber ich versuche mich auf IT Security zu spezialisieren), und hoffe hier ein paar sinnvolle Sachen beisteuern zu können.

    Symmetrische und Asymmetrische Verschlüsselung wurden ja schon genannt, und es ist in der Tat so, das man bei modernen, aktuellen Verfahren/Protokollen die eigentlichen Inhalte symmetrisch verschlüsselt – einfach, weil’s schneller geht. Lediglich der Verschlüsselungskey wird asymmetrisch verschlüsselt.

    Das Thema Perfect Forward Secrecy (https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy) habt ihr leider komplett außen vor gelassen, das wäre auch noch interessant gewesen.

    Dann ist es noch so, dass man Daten ja nicht nur verschlüsseln will, man will auch ihre Authentizität gewährleisten. Das geht über das gleiche Verfahren wie für die Verschlüsselung, nur indem man Daten halt signiert. Man signiert aber nicht die Daten direkt, weil das zu lange dauern würde, sondern man generiert einen Hashwert (https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion) der Daten und signiert diesen mit dem eigenen Private Key. Der Empfänger kann dann mit meinem Public Key die Echtheit bestätigen. Hat der Empfänger meinen Public Key nicht, kann er die Daten trotzdem lesen, nur eben die Echtheit nicht bestätigen. Das ganze (Also Daten und signierter Hashwert) verpackt man dann ordentlich und verschlüsselt diese symmetrisch. Der symmetrische Verschlüsselungskey wird anschließend asymmetrisch mit dem Public Key des Empfängers bzw. der Empfänger verschlüsselt und kann dann an diesen bzw. diese übermittelt werden.

    Dass man die Daten symmetrisch verschlüsselt hat zudem noch einen anderen Vorteil: Wenn ich mehr als einen Emfpänger habe, oder mein Empfänger mehr als ein Gerät hat (und diese Geräte alle einen eigenen Schlüssel haben) muss ich nur den Verschlüsselungskey selbst mehrfach verschlüsseln (pro Gerät/Empfänger einmal), nicht aber die Daten selbst (die halt mehrere Mega- oder auch Gigabyte groß sein können). Ich spare mir dadurch ordentlich Bandbreite und etwas Zeit.

    Zu E-Mail Verschlüsselung gibt es grob gesagt zudem zwei Lager: Die, die das für sinnvoll erachten, und die, die das nicht für sinnvoll erachten. Ich gehöre zu letzteren, und zwar aus folgendem Grund: Optionale Verschlüsselung für E-Mail gibt es jetzt seit Jahrzehnten, die Protokolle sind alt, haben weder Verschlüsselung noch PFS im Standard drin und wenn es einfach wäre, hätten es alle. Die Realität sieht aber so aus, dass man manche Provider durch ein Gesetz (!) zwingen musste, überhaupt erst einmal eine Transportverschlüsselung für E-Mail umzusetzen. Deshalb halte ich das für kompletten Unsinn. Mir persönlich wäre ein neues Protokoll, was dem aktuellen technischen Stand entspricht, wesentlich lieber.

    Für all diejenigen, die das trotzdem haben wollen, einen kleinen Überblick: Unternehmen setzen in der Regel auf S/MIME (https://de.wikipedia.org/wiki/S/MIME). Privatpersonen in der Regel auf PGP bzw. das freie GPG/OpenPGP, welche als diverse Extensions für E-Mailprogramme verfügbar sind (etwa K-9 Mail für Android, Enigmail für Thunderbird, etc.). Dann gibt es auch noch p≡p (oder “pEp”), welches das ganze ursprünglich mal vereinfachen wollte. Und mit Sicherheit noch ein dutzend anderer Projekte. Ich selbst habe das auch mal alles genutzt, aber die Anzahl der verschlüsselten E-Mails (in einem technischen Umfeld!) war dermaßen gering, und der Wartungsaufwand relativ hoch, dass ich es wieder gelassen habe.

    Zudem ein Problem all dieser Erweiterungen ist: Es läuft nicht automatisch. Ich muss als Nutzer selbst die Erweiterung installieren, einen Schlüssel erstellen, und ich muss diesen selbst verteilen. Für die Verteilung nutzt man in der Regel Keyserver (https://de.wikipedia.org/wiki/Schl%C3%BCsselserver).

    Das Problem mit Keyservern ist aber folgendes: Ich kann jederzeit einen Key für eine beliebige Adresse erstellen und diese auf einen Keyserver hochladen. D.h. ein Keyserver überprüft nicht, ob ich auch wirklich E-Mails für die von mir angegebene Adresse empfangen kann. Und das ist auch der größte Kritikpunkt an Keyservern: Dutzende Keys, die dort hochgeladen wurden, wurden von Dritten erstellt. Es ist zudem nicht klar, wenn mehrere Keys dort zu finden sind, welchen man jetzt zur Verschlüsselung nutzen soll. Alles in allem also Mist.

    Lösen kann man das natürlich, entweder indem ich beweise, dass ich tatsächlich Zugang zu diesem E-Mail Postfach habe (indem der Keyserver mir eine E-Mail mit Bestätigungslink schickt auf die ich klicken muss), oder mein Mailanbieter halt direkt ein Verzeichnis für Public Keys implementiert und gewährleistet, dass er diese Verschüsselung nicht bricht (was wiederum auf Vertrauen basiert, was wiederum in der Kryptographie eher nicht zu empfehlen ist). Alternativ kann man auch ein Projekt wie Keybase (https://en.wikipedia.org/wiki/Keybase) nutzen. Ich persönlich mag Keybase nicht weil ich hier auch wieder einem einzigen Anbieter vertrauen muss, und man will eigentlich keine zentralen Angriffsstellen haben, schon gar nicht in einem dezentralen System wie E-Mail. Sinnvoll wäre es tatsächlich, wenn es eine well-known URI gäbe (https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers) für E-Mail Verschüsselung, und jeder E-Mail Server unter eine Adresse die Public Keys für alle bei ihm liegenden Postfächern vorhalten würde. Diesen Standard gibt es aber, soweit ich weiß, nicht.

    Nächster Punkt: Es gibt ein geniales Verfahren für den Schlüsseltausch: Und zwar den Diffie-Hellman Schlüsseltausch (https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch). Ich weiß gerade nicht, ob ihr das angesprochen hatten. Aber ist auf jeden Fall Wert sich den Artikel einmal durchzulesen.

    Noch ein Punkt: Das Problem mit “ich bin tatsächlich wer ich vorgebe zu sein” hat man auch bei Domains. Und zwar gibt es da Zertifizierungstellen, die einem ein Zertifikat ausstellen. Die meisten Zertifizierungsstellen überprüfen aber nicht großartig, ob man wirklich Inhaber einer Domain ist, und ermöglichen damit Man-in-the-middle Angriffe. Also: doof. Ein Projekt welches das gelöst hat ist “Let’s Encrypt” (https://de.wikipedia.org/wiki/Let%E2%80%99s_Encrypt). Let’s Encrypt implementiert hierbei die ACME-Spezifikation (https://de.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) und dient als Zertifizierungsserver. Die Zertifikate selbst halten maximal drei Monate, dann muss ich diese erneuern. Sinn dahinter ist, dass ich mir nicht einmal ein Zertifikat holen kann, was dann auch noch in zwei Jahren gültig ist, obwohl ich schon lange nicht mehr Inahber der Domain bin. Manche Webserver/Proxies haben das ganze zudem vollautomatisiert (etwa Traefik oder Caddy), wodurch ich als Serverbetreiber mich nicht mehr darum kümmern muss. Ich sage nur noch welche Domain mir gehört und den Rest erledigt die Software selbst. Weiteres entnehmt ihr bitte den verlinkten Artikeln 🙂

    Um jetzt zum Abschluss meines zugegebenermaßen sehr langen Kommentars zu sein: Es gibt eine handvoll Messenger-Apps (die so richtig Slack und E-Mail gehen), die hervorragende Verschlüsselung implementieren, und die das alles sehr bequem machen. Ich bitte euch, diese mal anzusehen.

    Das eine Projekt heißt Signal bzw. Signal Messenger (https://signal.org/de/), und implementiert das Signal-Protokoll (https://de.wikipedia.org/wiki/Signal-Protokoll). Das ist *der* Standard aktuell. Es gibt nichts besseres, zumindest wäre mir nichts besseres bekannt. Wer wissen möchte warum, dem empfehle ich deren Blog zu lesen. Da stehen Leute dahinter die wirklich an alles denken. Die Authentifizierung erfolgt hierbei über die Handynummer (was auch der einzige Kritikpunkt an diesem Messenger ist, den ich für valide halte).

    Der zweite Messenger ist Wire (https://de.wikipedia.org/wiki/Wire_(Messenger)). Der hat zugegebenermaßen ein paar mehr Kritikpunkte, ist aber immer noch ein sehr gut. Von deren Seite bitte nicht abschrecken lassen, die wollen zwar auch Geld verdienen, und richten sich mehr an Businesskunden, man kann den Messenger aber als Privatperson komplett kostenlos herunterladen, sich registrieren, und dann benutzen. Zumal Wire halt ein wirlicher Multi-Device-Messenger ist, diese Eigenschaft fehlt leider vielen anderen Messenger.

    Und das dritte ist Matrix (https://matrix.org/). Matrix ist jetzt mehr als nur ein Messenger, es ist ein Protokoll. Der Messenger dazu nennt sich Riot (https://de.wikipedia.org/wiki/Riot_(Instant-Messenger)). Sehr zu empfehlen auch sich mal mit diesem zu befassen.

    Und wer es geschafft hat bis hierher zu lesen: Vielen Dank. Falls Fragen offen sind oder ich noch irgendwie weiter helfen kann (zumindest hoffe ich, dass ich helfen konnte): Ihr habt ja meine E-Mail-Adresse.

    Grüße, Florian

  6. Erstmal, es heißt hier symmetrisch und asymmetrisch, nicht synchron und asynchron. Das ist bei ADSL sogar noch schlimmer, da das zwar asymmetrisch, aber synchron ist.

    Das Problem mit Schlüsselaustauschverfahren ist, dass man zwar mit jemanden einen Schlüssel austauschen kann, aber nie weiß, wer das denn ist. Sprich Alice könnte mit Bob sprechen wollen, die Daten werden jedoch zu Malice umgeleitet, welche den Schlüsselaustausch mit Alice und Bob macht und dann in der Mitte die Daten trotzdem abgreifen kann.

    Um dieses offensichtliche Problem zu umgehen gibt es unterschiedliche Lösung. GPG/PGP legt das in die Hand des Nutzers, der Schlüssel selbst beglaubigen muss, oder von dritten beglaubigte Schlüssel akzeptiert. S/MIME oder TLS (was man für Websites verwendet) verwendet das Konzept von Certificate Authorities. Man hat eine Reihe von Organisationen welche Antragssteller prüfen und dann deren öffentliche Schlüssel unterschreiben. Diese Organisationen sind zum Beispiel im Browser hinterlegt. So lange _keine_ dieser Organisationen einen Fehler begeht, ist das System sicher. So bald eine dieser Organisationen einen Fehler begeht ist das System unsicher.
    Stichwort: Diginotar

    Im Prinzip ist GPG/PGP schon sehr nahe an dem was man eigentlich will. Es kommt ohne zentrale Stelle aus. Was man hier eigentlich noch bräuchte wäre deutlich bessere Integration in Mailclients.

    Sprich der öffentliche Schlüssel wird per Default an E-Mails angehängt und die E-Mail signiert. Bei jeder neuen E-Mail die mit öffentlichen Schlüssel ankommt wird dieser extrahiert und gespeichert.
    Wenn man dann eine Antwort schickt, so sagt einem der Mailclient “Hey Du hast jetzt schon 3 mal E-Mails von diesem Absender mit diesem öffentlichen Schlüssel bekommen, wenn das der richtige Schlüssel ist kann ich das für ihn verschlüsseln. Willst Du diese E-Mail verschlüsseln.” und dann macht der das einfach.

    Macht doch mal wieder eine Sommerfolge und nehmt dann noch mal Gästeformeln dran. Wenn das lange genug vorher bekannt ist, könnte sogar ich da hin kommen.

  7. Im Prinzip redet alles Mögliche in Rechnern verschlüsselt miteinander.
    “Hallo, hier ist Webserver 1, ich will gern mit dir, Webserver 2 reden. Gib mir mal deinen Public Key!”
    “Hallo, hier ist Word, ich würde gern mal mit der CPU reden und mir Rechenzeit erbitten, wie ist denn dein Public Key, Rechenzeit?”
    Die schnacken dann kurz über die asymmetrische Verschlüsselung und einigen sich auf ein symmetrisches Verschlüsselungsverfahren und tauschen dazu den Schlüssel aus.
    Und das große Problem ist, wie ihr auch erkannt habt, dass ja keiner weiß, ob der genannte Public Key der echte ist. Denn wenn er das nicht ist, kann ich es gleich ans schwarze Brett hängen …
    Bei E-Mail gab es dazu die Idee des Web of Trust. Ich kenne Franzi schon ewig und wir reden verschlüsselt miteinander, und deswegen kann ich Florian auch bestätigen, dass der Public Key, den er von Franzi erhalten hat, wirklich der von Franzi ist. Das Problem hierbei ist, dass sich das nie durchgesetzt hat – unter anderem, weil jeder ja mal ohne Freunde auftaucht und da nicht reinkommt.
    Die aktuelle Lösung geht hierbei über Zertifikate. Es gibt eine Stelle, die absolutes Vertrauen genießt und bei der man mit einem eigenen Schlüssel antanzt, sich ausweist, und die den Schlüssel signiert, also ein Echtheitszertifikat erwirbt. Wenn ich jetzt Franz meinen Public Key gebe mit Zertifikat dazu, kann sie mithilfe des Public Key der Zertifikatsstelle überprüfen, ob das Zertifikat echt ist, also ob die Zertifizierungsstelle mit ihrem Privaten Schlüssel signiert hat, und ob der Inhalt des signierten Schlüssels dem entspricht, was ich ihr auf den Tisch geklatscht habe.
    Das große Problem hierbei ist natürlich, dass die Zertifizierungsstelle absolutes Vertrauen genießen muss, deswegen findet es die IT-Gemeinde gar nicht so toll, wenn irgendwo rauskommt, dass Zertifizierungsstellen nicht sauber arbeiten oder es Pannen gibt. Weil davon die gesamte Webkommunikation abhängt.
    Der geheime Schlüssel der Zertifizierungsstelle (und auch andere geheime Schlüssel, zB in Unternehmen) sind dann auch besonders geschützt, gern auch in (sehr teuren) Hardware-Modulen (HSMs), die also einzige Möglichkeit physisch angegriffen werden können, aber nicht übers Netzwerk. Irgendeinen Pferdefuß gibt es immer, deswegen wird versucht, alles so sicher wie möglich zu machen.

  8. Zu der Endfrage wer jetzt recht hat ob das nicht alles einfach so funtionieren könnte mit den Public Keys: Ja das könnte es! Die Technologie existiert auch schon in der Praxis (WKS/WKD)! Aber:
    * Der Public Key wird auf dem Empfängerserver hinlegt – soweit muss man also seinem Mail-Anbieter vertrauen, dass er keine falschen Schlüssel austeilt.
    * JEDER Mail-Anbieter muss diese Protokolle (WKS & WKD) unterstützen – Derzeit nur eine Handvoll und viele kleinere Mail-Server stehen seit Jahren praktisch ungewartet herum; wer soll die dann Updaten?
    * JEDER Client muss geupdatet werden, derzeit kann das soweit ich weiß nur Thunderbird mit Enigmail selbstständig abfragen und hochladen und viele Nutzer kleben an uralten Clients (Pegasus Mail, anybody?) die das wohl nie unterstützen werden…
    * GMail/Google ünterstüzt das nicht, da braucht man eigentlich gar nicht weiterreden
    * Web-Clients allgemein: Es müsste eine Infrastruktur geschaffen werden, damit diese Private Schlüssel unabhängig von anderen Daten verwalten können und es nicht auf einmal heißt: „Sorry, dein Private Key ist weg. Alle deine bisher empfangenen E-Mails sind damit leider für immer unlesbar geworden.“

    Ich sag nicht dass es unmöglich ist, aber die PRAKTISCHEN Probleme sind enorm. E-Mail wurde in einer Zeit entwickelt als man noch ALLES unverschlüsselt durch die Gegend gesendet wurde. Verschlüsselung? Das war was Militärs und Geheimdienste. Die historische Last ist ein riesiges Problem bei dieser Art von Veränderung und es braucht einfach sehr sehr viele im System beteiligte um etwas die Richtung zu verändern die zB bei den meisten Mobil-Chat-Apps längst Standard ist.

    • Ihr habt außerdem den wichtigsten Punkt vergessen zu Erwähnen warum nicht einfach jeder mit dem öffentlichen Exponenten e den geheimen Exponenten d berechnen kann: Um d zu berechnen braucht man das Eingangs kurz erwähnte Φ(N) und um Φ(N) zu berchnen braucht man defakto die beiden ursprünglichen Primzahlen p & q aus N=p•q, da (wie in der Folge erwähnt) Φ(N)=(p-1)•(q-1). Warum man da jetzt genau Φ(N) braucht ist etwas komplizierter – ich wollte nur eine Idee davon geben warum es nicht für jeden trivial ist aus e auf d zu schließen und damit den gesammten Alogrithmus kaputt zu machen.

  9. Puh, was für eine Folge. Erst einmal vielen Dank dafür und auch für den Podcast an sich. Nach der letzten Folge zu den Primzahlen hatte ich mich ja schon darauf gefreut auch etwas über Kryptographie zu hören, aber – und das ist nicht böse gemeint – es wäre sinnvoll gewesen vielleicht einen Kryptographen oder ein paar Leute aus der FOSS Community zu diesem Thema zu befragen.

    Ich selbst bin jetzt auch kein Kryptograph (aber ich versuche mich auf IT Security zu spezialisieren), und hoffe hier ein paar sinnvolle Sachen beisteuern zu können.

    Symmetrische und Asymmetrische Verschlüsselung wurden ja schon genannt, und es ist in der Tat so, das man bei modernen, aktuellen Verfahren/Protokollen die eigentlichen Inhalte symmetrisch verschlüsselt – einfach, weil’s schneller geht. Lediglich der Verschlüsselungskey wird asymmetrisch verschlüsselt.

    Das Thema Perfect Forward Secrecy (https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy) habt ihr leider komplett außen vor gelassen, das wäre auch noch interessant gewesen.

    Dann ist es noch so, dass man Daten ja nicht nur verschlüsseln will, man will auch ihre Authentizität gewährleisten. Das geht über das gleiche Verfahren wie für die Verschlüsselung, nur indem man Daten halt signiert. Man signiert aber nicht die Daten direkt, weil das zu lange dauern würde, sondern man generiert einen Hashwert (https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion) der Daten und signiert diesen mit dem eigenen Private Key. Der Empfänger kann dann mit meinem Public Key die Echtheit bestätigen. Hat der Empfänger meinen Public Key nicht, kann er die Daten trotzdem lesen, nur eben die Echtheit nicht bestätigen. Das ganze (Also Daten und signierter Hashwert) verpackt man dann ordentlich und verschlüsselt diese symmetrisch. Der symmetrische Verschlüsselungskey wird anschließend asymmetrisch mit dem Public Key des Empfängers bzw. der Empfänger verschlüsselt und kann dann an diesen bzw. diese übermittelt werden.

    Dass man die Daten symmetrisch verschlüsselt hat zudem noch einen anderen Vorteil: Wenn ich mehr als einen Emfpänger habe, oder mein Empfänger mehr als ein Gerät hat (und diese Geräte alle einen eigenen Schlüssel haben) muss ich nur den Verschlüsselungskey selbst mehrfach verschlüsseln (pro Gerät/Empfänger einmal), nicht aber die Daten selbst (die halt mehrere Mega- oder auch Gigabyte groß sein können). Ich spare mir dadurch ordentlich Bandbreite und etwas Zeit.

    Zu E-Mail Verschlüsselung gibt es grob gesagt zudem zwei Lager: Die, die das für sinnvoll erachten, und die, die das nicht für sinnvoll erachten. Ich gehöre zu letzteren, und zwar aus folgendem Grund: Optionale Verschlüsselung für E-Mail gibt es jetzt seit Jahrzehnten, die Protokolle sind alt, haben weder Verschlüsselung noch PFS im Standard drin und wenn es einfach wäre, hätten es alle. Die Realität sieht aber so aus, dass man manche Provider durch ein Gesetz (!) zwingen musste, überhaupt erst einmal eine Transportverschlüsselung für E-Mail umzusetzen. Deshalb halte ich das für kompletten Unsinn. Mir persönlich wäre ein neues Protokoll, was dem aktuellen technischen Stand entspricht, wesentlich lieber.

    Für all diejenigen, die das trotzdem haben wollen, einen kleinen Überblick: Unternehmen setzen in der Regel auf S/MIME (https://de.wikipedia.org/wiki/S/MIME). Privatpersonen in der Regel auf PGP bzw. das freie GPG/OpenPGP, welche als diverse Extensions für E-Mailprogramme verfügbar sind (etwa K-9 Mail für Android, Enigmail für Thunderbird, etc.). Dann gibt es auch noch p≡p (oder “pEp”), welches das ganze ursprünglich mal vereinfachen wollte. Und mit Sicherheit noch ein dutzend anderer Projekte. Ich selbst habe das auch mal alles genutzt, aber die Anzahl der verschlüsselten E-Mails (in einem technischen Umfeld!) war dermaßen gering, und der Wartungsaufwand relativ hoch, dass ich es wieder gelassen habe.

    Zudem ein Problem all dieser Erweiterungen ist: Es läuft nicht automatisch. Ich muss als Nutzer selbst die Erweiterung installieren, einen Schlüssel erstellen, und ich muss diesen selbst verteilen. Für die Verteilung nutzt man in der Regel Keyserver (https://de.wikipedia.org/wiki/Schl%C3%BCsselserver).

    Das Problem mit Keyservern ist aber folgendes: Ich kann jederzeit einen Key für eine beliebige Adresse erstellen und diese auf einen Keyserver hochladen. D.h. ein Keyserver überprüft nicht, ob ich auch wirklich E-Mails für die von mir angegebene Adresse empfangen kann. Und das ist auch der größte Kritikpunkt an Keyservern: Dutzende Keys, die dort hochgeladen wurden, wurden von Dritten erstellt. Es ist zudem nicht klar, wenn mehrere Keys dort zu finden sind, welchen man jetzt zur Verschlüsselung nutzen soll. Alles in allem also Mist.

    Lösen kann man das natürlich, entweder indem ich beweise, dass ich tatsächlich Zugang zu diesem E-Mail Postfach habe (indem der Keyserver mir eine E-Mail mit Bestätigungslink schickt auf die ich klicken muss), oder mein Mailanbieter halt direkt ein Verzeichnis für Public Keys implementiert und gewährleistet, dass er diese Verschüsselung nicht bricht (was wiederum auf Vertrauen basiert, was wiederum in der Kryptographie eher nicht zu empfehlen ist). Alternativ kann man auch ein Projekt wie Keybase (https://en.wikipedia.org/wiki/Keybase) nutzen. Ich persönlich mag Keybase nicht weil ich hier auch wieder einem einzigen Anbieter vertrauen muss, und man will eigentlich keine zentralen Angriffsstellen haben, schon gar nicht in einem dezentralen System wie E-Mail. Sinnvoll wäre es tatsächlich, wenn es eine well-known URI gäbe (https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers) für E-Mail Verschüsselung, und jeder E-Mail Server unter eine Adresse die Public Keys für alle bei ihm liegenden Postfächern vorhalten würde. Diesen Standard gibt es aber, soweit ich weiß, nicht.

    Nächster Punkt: Es gibt ein geniales Verfahren für den Schlüsseltausch: Und zwar den Diffie-Hellman Schlüsseltausch (https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch). Ich weiß gerade nicht, ob ihr das angesprochen hatten. Aber ist auf jeden Fall Wert sich den Artikel einmal durchzulesen.

    Noch ein Punkt: Das Problem mit “ich bin tatsächlich wer ich vorgebe zu sein” hat man auch bei Domains. Und zwar gibt es da Zertifizierungstellen, die einem ein Zertifikat ausstellen. Die meisten Zertifizierungsstellen überprüfen aber nicht großartig, ob man wirklich Inhaber einer Domain ist, und ermöglichen damit Man-in-the-middle Angriffe. Also: doof. Ein Projekt welches das gelöst hat ist “Let’s Encrypt” (https://de.wikipedia.org/wiki/Let%E2%80%99s_Encrypt). Let’s Encrypt implementiert hierbei die ACME-Spezifikation (https://de.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) und dient als Zertifizierungsserver. Die Zertifikate selbst halten maximal drei Monate, dann muss ich diese erneuern. Sinn dahinter ist, dass ich mir nicht einmal ein Zertifikat holen kann, was dann auch noch in zwei Jahren gültig ist, obwohl ich schon lange nicht mehr Inahber der Domain bin. Manche Webserver/Proxies haben das ganze zudem vollautomatisiert (etwa Traefik oder Caddy), wodurch ich als Serverbetreiber mich nicht mehr darum kümmern muss. Ich sage nur noch welche Domain mir gehört und den Rest erledigt die Software selbst. Weiteres entnehmt ihr bitte den verlinkten Artikeln 🙂

    Um jetzt zum Abschluss meines zugegebenermaßen sehr langen Kommentars zu sein: Es gibt eine handvoll Messenger-Apps (die so richtig Slack und E-Mail gehen), die hervorragende Verschlüsselung implementieren, und die das alles sehr bequem machen. Ich bitte euch, diese mal anzusehen.

    Das eine Projekt heißt Signal bzw. Signal Messenger (https://signal.org/de/), und implementiert das Signal-Protokoll (https://de.wikipedia.org/wiki/Signal-Protokoll). Das ist *der* Standard aktuell. Es gibt nichts besseres, zumindest wäre mir nichts besseres bekannt. Wer wissen möchte warum, dem empfehle ich deren Blog zu lesen. Da stehen Leute dahinter die wirklich an alles denken. Die Authentifizierung erfolgt hierbei über die Handynummer (was auch der einzige Kritikpunkt an diesem Messenger ist, den ich für valide halte).

    Der zweite Messenger ist Wire (https://de.wikipedia.org/wiki/Wire_(Messenger)). Der hat zugegebenermaßen ein paar mehr Kritikpunkte, ist aber immer noch ein sehr gut. Von deren Seite bitte nicht abschrecken lassen, die wollen zwar auch Geld verdienen, und richten sich mehr an Businesskunden, man kann den Messenger aber als Privatperson komplett kostenlos herunterladen, sich registrieren, und dann benutzen. Zumal Wire halt ein wirlicher Multi-Device-Messenger ist, diese Eigenschaft fehlt leider vielen anderen Messenger.

    Und das dritte ist Matrix (https://matrix.org/). Matrix ist jetzt mehr als nur ein Messenger, es ist ein Protokoll. Der Messenger dazu nennt sich Riot (https://de.wikipedia.org/wiki/Riot_(Instant-Messenger)). Sehr zu empfehlen auch sich mal mit diesem zu befassen.

    Und wer es geschafft hat bis hierher zu lesen: Vielen Dank. Falls Fragen offen sind oder ich noch irgendwie weiter helfen kann (zumindest hoffe ich, dass ich helfen konnte): Ihr habt ja meine E-Mail-Adresse.

    Grüße, Florian

  10. End-to-end Verschlüsselung hat sich ja auch bei vielen Messenger-Apps durchgesetzt. Bei WhatsApp wird mit den Installation ein Keypaar generiert und der Public key an WhatsApp geschickt. WhatsApp verwaltet die also. Man kann sich über die Einstellungen auch anzeigen lassen, wenn sich der vom anderen ändert. Ich schreibe dann oft “oh, hast du WhatsApp neu installiert” und bekomme verwunderte Antworten “ja, woher weißt du das?”

    Der Nachteil ist, dass du nicht weißt, ob WhatsApp deinen Private Key weiter schickt, bzw. ob dein private Key auch beim Gegenüber angekommen ist. (Gefahr von Man in the Middle angriffen.)

    Eine gute Lösung bietet da Threema an. Da werden die Schlüssel auch zentral ausgetauscht, dann wird das aber als weniger sicher dargestellt. Man kann den Schlüssel von anderen aber auch per QR-Code scannen. Der wird auf dem einen Gerät angezeigt und mit dem anderen fotografiert dadurch ist physisch sicher gestellt, dass es der richtige Schlüssel ist.

Schreibe einen Kommentar zu Florian Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.