Curve25519/Curve447: Neue elliptische Kurven von der IETF
Die Krypto-Arbeitsgruppe der IETF hat RFC 7748 veröffentlicht. Darin spezifiziert sind die zwei elliptischen Kurven Curve25519 und Curve447. Sie sind das Ergebnis einer langen Diskussion.

Die IETF hat eine Spezifikation für die elliptischen Kurven Curve25519 und Curve447 öffentlich gemacht. RFC 7748 definiert beide Kurven und entsprechende Algorithmen für einen Diffie-Hellman-basierten Schlüsselaustausch. Vorausgegangen war eine lange Diskussion und ein Streit darüber, wie man am besten Kurven ohne fragwürdige Konstanten definiert.
Wo kommen die Konstanten her?
Nach den Snowden-Enthüllungen hatten einige Kryptographen Bedenken über die bislang zumeist verwendeten Kurven der US-Standardisierungsbehörde Nist geäußert. Der Grund: Sie enthielten einige Konstanten, deren Herkunft nicht geklärt war. Die Nist-Kurven wurden ursprünglich von der NSA entwickelt. Dieses Problem war bereits früher aufgefallen, weshalb die vom BSI mitentwickelten Brainpool-Kurven ein Verfahren verwendeten, bei dem die Parameter aus bekannten mathematischen Konstanten generiert wurden. Doch das Brainpool-Verfahren erwies sich ebenfalls als problematisch.
Zwar hielten viele Kryptographen es für kaum realistisch, dass es sich bei diesen unerklärten Konstanten um NSA-Hintertüren handelt, doch das Misstrauen war geweckt. Unabhängig von dieser Diskussion gab es auch andere Kritik an den Nist-Kurven: Diese seien schwer sicher zu implementieren, zu kompliziert und anfällig für Seitenkanalangriffe und Implementierungsfehler. Insbesondere der letzte Punkt wurde im vergangenen Jahr noch einmal deutlich, als es Sicherheitsforschern der Ruhr-Universität Bochum gelang, einen Angriff mittels ungültiger Kurvenpunkte auf verschiedene Implementierungen praktisch durchzuführen. Ein derartiger Angriff wäre zwar auch mit Curve25519 denkbar, aber nicht mit den damit üblicherweise verwendeten Algorithmen, die Kurvenpunkte komprimiert übertragen.
Bereits vor zwei Jahren gab es daher den Wunsch, neue elliptische Kurven zu spezifizieren. Die von Dan Bernstein entwickelte Kurve Curve25519 hatte bereits einige Fans, viele Krypto-Tools unterstützen sie schon, etwa Textsecure (heute Signal), GnuPG und OpenSSH. Bernstein verzichtete beim Design seiner Kurve auf unerklärte Zahlen und wählte einen anderen Weg: Er definierte eine Reihe von Sicherheitseigenschaften und wählte die schnellste Kurve einer bestimmten Größe, die alle Eigenschaften erfüllt.
Doch genau um dieses "rigorose" Wahlverfahren gab es wieder einigen Streit. Kryptographen von Microsoft nutzten ein ähnliches Verfahren, kamen aber auf andere Kurven. Es folgte eine lange Diskussion, in der darüber gestritten wurde, welches "rigorose" Verfahren nun korrekt sei. Microsoft änderte sein Verfahren während der Diskussion und kam auf unterschiedliche Kurven.
Letztendlich konnte sich Curve25519 durchsetzen und ist nun ein offizielles IETF-Dokument. Die Kurve ist 255 Bit lang. Eine längere Kurve - Curve447 - wurde ebenfalls spezifiziert, diese wurde mit einem vergleichbaren Verfahren generiert.
Chrome plant Implementierung
Chrome-Entwickler David Benjamin kündigte bereits an, in Kürze den auf der Kurve basierten Schlüsselaustausch X25519 in Chrome zu implementieren. Allerdings: Während der Algorithmus selbst nun einen RFC hat, ist die Einbindung in TLS bisher nur ein Entwurf. Benjamin rechnet aber nicht damit, dass sich dieser Entwurf noch ändert.
Ebenfalls noch in Arbeit ist ein Signaturverfahren auf Basis der neuen Kurven. Vorerst kann man also - RFC-konform - nur den Schlüsselaustausch einsetzen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Nachdem ich kurz das RFC zur Kurve überflogen hatte habe ich eine zufällige RFC ID...