Warum Solo-PQ ein Sicherheitsdesaster wird: Bugs sind unvermeidlich
Bugs happen: The easy way to compare solo PQ to ECC+PQ
In seinem Blog vergleicht Daniel J. Bernstein die Sicherheit von rein post-quantum (PQ) basierten Protokollen mit Hybriden aus ECC und PQ. Er argumentiert, dass Softwarefehler in PQ-Implementierungen unvermeidlich und oft ausnutzbar sind, weshalb das Beibehalten von ECC als Sicherheitsnetz entscheidend ist. Er verweist auf zahlreiche CVEs und Timing-Leaks in ML-KEM/ML-DSA-Implementierungen und kritisiert die Pseudowissenschaft hinter Sicherheitsbehauptungen. Bernsteins Fazit: Die Kosten für ECC sind vernachlässigbar, während die Risiken von Solo-PQ inakzeptabel hoch sind.
Die Kosten für ECC sind im Vergleich zu PQ leicht erschwinglich, also gibt es keine Entschuldigung, ECC wegzuwerfen.
- Retr0id
Früher war ich ein Befürworter von Hybrid-Lösungen, aber heute bin ich da eher unentschlossen. ECC-Software kann auch Fehler haben, aber ich glaube nicht, dass ernsthaft jemand vorgeschlagen hat, zwei verschiedene ECC-Implementierungen zu hybridisieren, zum Beispiel.
- rot256
Kauf das Argument nicht, das Zeug ist einfach genug, dass wir es formal verifizieren und sehr sorgfältig prüfen können. Außerdem hatte NIST die Weitsicht, alle Algorithmen zu derandomisieren, sodass wir jetzt zum Beispiel überprüfen können, was eine korrekte Implementierung bei bestimmten Seeds erzeugt. Das ist eine große Sache, weil viele ECDSA-Bugs, wie voreingenommene Nonces oder wiederverwendete Nonces, durch solche Tests/derandomisierung trivial erkannt werden. TLDR: Die Bugs werden woanders sein.
- libeclipse
Warum nutzen wir dann nicht hybrides RSA und ECC? Oder hybrides AES und ChaCha20? Software-Bugs sind ein schwaches Argument für einen neuen Hybrid-Standard und rechtfertigen nicht die zusätzliche Komplexität.