SIMD-0215 haelt einen Kollisionsangriff mit 2^81 auf den Konten-Hash fest und begruendet, warum er nicht baubar ist
Victoria Shinder2 Min. LesezeitEin Commit im Repository der Solana Improvement Documents schreibt den Sicherheitsabschnitt von SIMD-0215 neu, dem Vorschlag zum Accounts Lattice Hash. Bisher stand dort ein Satz: LtHash mit BLAKE3 und 2048 Byte Ausgabe biete die angestrebte 128-Bit-Sicherheit. Der Ersatz umfasst zwanzig Zeilen und ist deutlich nuetzlicher.
Die Parameter werden jetzt genannt: 1024 Elemente zu sechzehn Bit, Arithmetik modulo 2^16, gewaehlt mit dem Ziel einer Kollisionssicherheit von 128 Bit. Dann folgt, was die Ueberarbeitung ausgeloest hat. Eine spaetere Analyse beschreibt einen Kollisionsangriff auf genau diese Parameter mit erwarteten Kosten von etwa 2^81 Hash-Abfragen, bei Obergrenzen von 2^101 Binaeroperationen und 2^88,45 Bit Spitzenspeicher einschliesslich der Datensaetze, die zur Rekonstruktion der kollidierenden Mengen noetig sind. Das Dokument haelt ausdruecklich fest, dass die berichtete Abfragekomplexitaet unter 2^128 liegt und der bewertete Angriff dennoch unpraktikabel bleibt.
Das zweite Argument ist das strukturelle. Mit den bewerteten Parametern enthalten die beiden kollidierenden Mengen zusammen mindestens 550^8 Elemente, etwa 2^72,83. Zum Accounts Lattice Hash tragen nur Konten mit Lamport-Guthaben ungleich null bei, und da die Gesamtkapitalisierung in ein u64 passen muss, enthaelt ein Kontenzustand hoechstens 2^64 - 1 solcher Konten — zwei gueltige Zustaende zusammen weniger als 2^65. Die kollidierenden Mengen sind damit zu gross, um zwei gueltige Kontenzustaende darzustellen.
Was das bedeutet
So sieht eine gute Sicherheitsnotiz aus, und das gehoert hervorgehoben. Ehrlich ist daran das Eingestaendnis: Die veroeffentlichten Parameter liefern nicht die runde Zahl, die der urspruengliche Satz behauptete, und das Dokument sagt es jetzt mitsamt Exponent. Eine runde Zusicherung durch eine Zahl zu ersetzen, die darunter liegt, ist fuer eine Spezifikation die schwierige Richtung.
Die Verteidigung erfolgt dann auf der richtigen Achse. Statt zu argumentieren, der Angriff sei teuer — 2^81 Abfragen sind teuer, aber dieses Argument hat ein Haltbarkeitsdatum —, zeigt die Notiz, dass die erzeugten Objekte gar keine Kontenzustaende sein koennen, weil ein gueltiges Hauptbuch nicht so viele gedeckte Konten enthaelt. Diese Schranke stammt aus der u64-Kapitalisierung, nicht aus der Kryptografie, und sie schwaecht sich mit besserer Hardware nicht ab.
Fuer Validator-Betreiber aendert sich heute nichts; der Vorschlag haelt in seinem Kompatibilitaetshinweis ohnehin fest, dass dies den Bank-Hash und damit den Konsens veraendert. Was sich aendert, ist die Qualitaet der Begruendung fuer alle, die den Entwurf pruefen — und genau dieser Teil fehlt sonst.