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.

7 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. 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.

  5. 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.

  6. 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.

Schreibe einen Kommentar

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