7. Security Considerations (Sicherheitsüberlegungen)
7. Security Considerations (Sicherheitsüberlegungen)
Das Sicherheitsniveau (d. h. die Anzahl der »Operationen«, die für einen Brute-Force-Angriff auf eine primitive Funktion nötig sind) von curve25519 liegt leicht unter dem üblichen 128-Bit-Niveau. Das ist akzeptabel, weil die Standard-Sicherheitsniveaus vor allem von viel einfacheren symmetrischen Primitiven bestimmt werden, bei denen das Sicherheitsniveau naturgemäß auf einer Zweierpotenz liegt. Bei asymmetrischen Primitiven würde ein starres Festhalten an einem Sicherheitsniveau als Zweierpotenz Kompromisse in anderen Teilen des Designs erzwingen, die wir ablehnen. Zudem kann der Vergleich von Sicherheitsniveaus zwischen verschiedenen Arten von Primitiven unter gängigen Bedrohungsmodellen, in denen mehrere Ziele parallel angegriffen werden können, irreführend sein [bruteforce].
Das ~224-Bit-Sicherheitsniveau von curve448 ist ein Kompromiss zwischen Leistung und Vorsicht. Große Quantencomputer würden, falls sie je realisiert werden, sowohl curve25519 als auch curve448 brechen, und vertretbare Projektionen der Fähigkeiten klassischer Computer kommen zu dem Schluss, dass curve25519 völlig ausreichend ist. Einige Entwürfe haben jedoch gelockerte Leistungsanforderungen und möchten sich gegen einen gewissen analytischen Fortschritt bei elliptischen Kurven absichern; daher wird auch curve448 bereitgestellt.
Protokollentwickler, die Diffie-Hellman über die in diesem Dokument definierten Kurven einsetzen, dürfen nicht annehmen, dass die privaten Schlüssel beider Parteien gemeinsam zum resultierenden gemeinsamen Schlüssel beitragen (im Sinne eines »beitragsleistenden Verhaltens« beider Schlüssel). Da curve25519 und curve448 die Kofaktoren 8 bzw. 4 haben, hebt ein Eingabepunkt kleiner Ordnung jeden Beitrag des privaten Schlüssels der anderen Partei auf. Diese Situation kann durch Prüfung auf die reine Nullausgabe erkannt werden, was Implementierungen wie in Abschnitt 6 beschrieben KÖNNEN tun. Eine große Zahl bestehender Implementierungen tut dies jedoch nicht.
Entwickler, die diese Kurven verwenden, sollten wissen, dass es zu jedem öffentlichen Schlüssel mehrere öffentlich berechenbare öffentliche Schlüssel gibt, die ihm äquivalent sind, d. h. dieselben gemeinsamen Geheimnisse erzeugen. Die Verwendung eines öffentlichen Schlüssels als Identifikator und die Kenntnis eines gemeinsamen Geheimnisses als Eigentumsnachweis (ohne die öffentlichen Schlüssel in die Schlüsselableitung einzubeziehen) kann daher zu subtilen Schwachstellen führen.
Entwickler sollten außerdem wissen, dass Implementierungen dieser Kurven die Montgomery-Leiter wie in diesem Dokument spezifiziert möglicherweise nicht verwenden, sondern stattdessen generische Bibliotheken für elliptische Kurven. Solche Implementierungen könnten Punkte auf der Twist-Kurve ablehnen und nicht-minimale Körperelemente ablehnen. Obwohl nicht empfohlen, werden solche Implementierungen mit der hier spezifizierten Montgomery-Leiter interoperieren, lassen sich von ihr aber möglicherweise trivial unterscheiden. Beispielsweise kann das Senden eines nicht-kanonischen Werts oder eines Punkts auf der Twist-Kurve dazu führen, dass solche Implementierungen einen beobachtbaren Fehler erzeugen, während eine Implementierung, die dem Entwurf in diesem Text folgt, erfolgreich ein gemeinsames Geheimnis erzeugt.