Ich habe echt viel zu lange in der letzten Nacht darauf gestarrt, wie sich zwei Wallet-Setups nebeneinander vergleichen: eine Browser-Erweiterung und die native App von DUSK. Ich habe versucht herauszufinden, welches tatsächlich ein gesperrtes Vault besser schützt. Im Thread wurde sich die ganze Zeit gestritten, dass Argon2 PBKDF2 überlegen ist – so als würde der Algorithmusname das schon klären. Tut er nicht. Argon2id mit eher schwachen Anforderungen an Speicher und Iterationszahl kann milder sein als PBKDF2, das auf 900k Runden hochgefahren ist. Der Name sagt dir nichts, wenn man die Parameter nicht kennt.
An der Stelle bin ich an eine Wand gestoßen. DUSK hat seine nativen KDF-Parameter nirgendwo veröffentlicht, zumindest habe ich sie nicht finden können, also ist der ganze Vergleich „Extension vs. DUSK-nativ“ zurzeit im Grunde nicht falsifizierbar. Man kann nicht benchmarken, was nicht offengelegt wird.
Aber das, was meine Denkweise dann wirklich neu ausgerichtet hat: Die Stärke des KDF schützt das Vault nur, während es gesperrt ist. Sobald du es entsperrst, bist du in einem völlig anderen Bedrohungsmodell – Stichwort JS-Heap-Exposition, eine bösartige Erweiterung, ein kompromittiertes Gerät. Kein Passwort-Hashing-Schema löst das, egal ob es um DUSK geht oder um die Wallet einer beliebigen anderen Chain. Viele behandeln „stärkeres KDF“ und „kürzere Expositionsdauer“ als dieselbe Diskussion. Sind sie nicht. Das sind orthogonale Probleme.
Und Zeroisierung löst das auch nicht sauber. Eine Wallet kann bei Timeout zwar eine Referenz fallen lassen, aber sie kann weder Garbage Collection erzwingen noch beweisen, dass der Speicher wirklich gesäubert wurde. Das ist nicht einzigartig für DUSK – so funktioniert JS nun mal.
Ich würde mir tatsächlich wünschen, dass DUSK drei Dinge veröffentlicht: native KDF-Parameter, einen gleich aufgebauten Benchmark mit gleichem Passwort über beide Wege hinweg und echte Zahlen zur Expositionsdauer. Und um fair zu sein: Diese Frage „Wie ist die Exposition nach dem Entsperren wirklich?“ muss man auf der DUSK-nativen Seite genauso stellen – hat Stronghold überhaupt eine eigene Re-Lock-Richtlinie? Falls nicht, ist der Vergleich nicht nur unvollständig, sondern asymmetrisch.
#dusk $DUSK @Dusk
An der Stelle bin ich an eine Wand gestoßen. DUSK hat seine nativen KDF-Parameter nirgendwo veröffentlicht, zumindest habe ich sie nicht finden können, also ist der ganze Vergleich „Extension vs. DUSK-nativ“ zurzeit im Grunde nicht falsifizierbar. Man kann nicht benchmarken, was nicht offengelegt wird.
Aber das, was meine Denkweise dann wirklich neu ausgerichtet hat: Die Stärke des KDF schützt das Vault nur, während es gesperrt ist. Sobald du es entsperrst, bist du in einem völlig anderen Bedrohungsmodell – Stichwort JS-Heap-Exposition, eine bösartige Erweiterung, ein kompromittiertes Gerät. Kein Passwort-Hashing-Schema löst das, egal ob es um DUSK geht oder um die Wallet einer beliebigen anderen Chain. Viele behandeln „stärkeres KDF“ und „kürzere Expositionsdauer“ als dieselbe Diskussion. Sind sie nicht. Das sind orthogonale Probleme.
Und Zeroisierung löst das auch nicht sauber. Eine Wallet kann bei Timeout zwar eine Referenz fallen lassen, aber sie kann weder Garbage Collection erzwingen noch beweisen, dass der Speicher wirklich gesäubert wurde. Das ist nicht einzigartig für DUSK – so funktioniert JS nun mal.
Ich würde mir tatsächlich wünschen, dass DUSK drei Dinge veröffentlicht: native KDF-Parameter, einen gleich aufgebauten Benchmark mit gleichem Passwort über beide Wege hinweg und echte Zahlen zur Expositionsdauer. Und um fair zu sein: Diese Frage „Wie ist die Exposition nach dem Entsperren wirklich?“ muss man auf der DUSK-nativen Seite genauso stellen – hat Stronghold überhaupt eine eigene Re-Lock-Richtlinie? Falls nicht, ist der Vergleich nicht nur unvollständig, sondern asymmetrisch.
#dusk $DUSK @Dusk
