- In der Low-Level-Funktion
crypto_core_ed25519_is_valid_point() von libsodium wurde ein Fehler bei der unzureichenden Punktvalidierung auf der Edwards25519-Kurve entdeckt
- Die Funktion sollte prüfen, ob ein Punkt zur primären kryptografischen Gruppe gehört, ließ aber fälschlich einige Punkte aus gemischten Ordnungen (subgroup) passieren
- Ursache war ein Codefehler bei der internen Koordinatenprüfung: Es wurde nur X=0 geprüft, die Prüfung Y=Z jedoch ausgelassen, sodass ungültige Punkte als gültig behandelt werden konnten
- In der korrigierten Version werden nun beide Bedingungen (X=0, Y=Z) geprüft; betroffen sind Versionen bis einschließlich 1.0.20 bzw. Releases vor dem 30. Dezember 2025
- Die High-Level-API (
crypto_sign_*) ist nicht betroffen; die Verwendung der Ristretto255-Gruppe wird im Hinblick auf Sicherheit und Performance empfohlen
Überblick über das libsodium-Projekt
- libsodium ist ein vor 13 Jahren gestartetes Projekt, das darauf abzielt, Kryptografie mit einer einfachen API leicht nutzbar zu machen
- Es wurde so entworfen, dass Nutzer nur High-Level-Operationen ausführen müssen, ohne die internen Algorithmen kennen zu müssen
- Das Projekt legt großen Wert auf Kompatibilität der API und hat auf Basis der NaCl-API bis heute Konsistenz bewahrt
- Da einige Nutzer Low-Level-Funktionen direkt verwenden und dabei über die in der Dokumentation genannten Grenzen hinausgehen, wird die Bibliothek zunehmend wie ein Kryptografie-Toolkit eingesetzt
Ursache des entdeckten Bugs
- Betroffene Funktion:
crypto_core_ed25519_is_valid_point()
- Sie sollte Punkte ablehnen, die auf der Edwards25519-Kurve nicht zur primären Gruppe (Ordnung L) gehören
- Einige Punkte mit gemischter Ordnung (2L, 4L, 8L usw.) bestanden die Prüfung jedoch
- Intern wird zur Bestimmung der Punktordnung mit L multipliziert und anschließend geprüft, ob das Ergebnis der neutrale Punkt (identity) ist
- Der neutrale Punkt wird in der Form X=0, Y=Z dargestellt, aber der bisherige Code prüfte nur X=0
- Dadurch konnten fehlerhafte Punkte mit Y≠Z als gültig behandelt werden
- Beispiel: Addiert man zu einem Punkt Q der primären Gruppe den Punkt der Ordnung 2
(0, -1), dann ist Q+(0, -1) ein ungültiger Punkt, wurde vor dem Fix aber akzeptiert
Inhalt der Korrektur
- Der Patch-Commit enthält folgende Änderung
- Bisheriger Code:
return fe25519_iszero(pl.X);
- Korrigierter Code:
fe25519_sub(t, pl.Y, pl.Z); return fe25519_iszero(pl.X) & fe25519_iszero(t);
- Jetzt werden sowohl X=0 als auch Y=Z geprüft, wodurch die Validierung korrekt erfolgt
Auswirkungsbereich
- Betroffen sein können Fälle mit folgenden Bedingungen
- Verwendung von Version 1.0.20 oder älter bzw. Releases vor dem 30. Dezember 2025
- Validierung nicht vertrauenswürdiger Eingabepunkte mit
crypto_core_ed25519_is_valid_point()
- Nutzer, die Edwards25519-Kurvenoperationen direkt implementieren
- Die meisten Nutzer sind jedoch nicht betroffen
- Die High-Level-API (
crypto_sign_*) verwendet diese Funktion nicht
crypto_scalarmult_ed25519 führt auch mit fehlerhaften öffentlichen Schlüsseln nicht zu Informationslecks- Mit
crypto_sign_keypair und crypto_sign_seed_keypair erzeugte Schlüssel gehören zur korrekten Gruppe
Empfohlene Maßnahmen
- Die Verwendung der Ristretto255-Gruppe wird empfohlen
- Sie ist seit 2019 in libsodium enthalten und löst Probleme im Zusammenhang mit dem Cofactor
- Dekodierte Punkte sind automatisch sicher, eine zusätzliche Validierung ist nicht erforderlich
- Sie bietet schnellere Rechenleistung als Edwards25519
- Falls ein Update nicht möglich ist, kann zur Validierung die vorgeschlagene Alternative auf Anwendungsebene (
is_on_main_subgroup) verwendet werden
Korrigierte Distributionen und Support
- Das Problem wurde unmittelbar nach der Entdeckung behoben und ist in allen stabilen Versionen enthalten, die nach dem 30. Dezember 2025 veröffentlicht wurden
- Einschließlich offiziellem Tarball, Visual Studio/MingW-Binärdateien, NuGet-Paketen, Builds für Android,
swift-sodium xcframework, Rust libsodium-sys-stable und libsodium.js
- Ein neuer Point Release ist ebenfalls geplant
- Das Projekt wird von einem einzelnen Maintainer betreut; laufende Verbesserungen können über OpenCollective-Sponsoring unterstützt werden
Noch keine Kommentare.