heisenberg hat geschrieben: 
19.02.2025 16:37:48
Ich habe ein normales verschlüsseltes ZIP-File mit "zip" erstellt.
Ah. Also single unsalted SHA1.
unsalted macht in deinem Fall nichts aus. Aber prinzipiell kannst du damit mehrere zips in etwa der gleichen Zeit knackacken.
heisenberg hat geschrieben: 19.02.2025 16:37:48
Aber Faktor 60.000 zu einer aktuellen Single-GPU ist ja schon mal eine Aussage, mit der ich was anfangen kann, wenn Sie denn zutrifft.
Die rechnen ja glücklicher weise auch mit einem modifizierten SHA-1 über mehrere Runden. Das Verhältnis dürfte für dein ZIP also genau passen. Das war die 4090. Für die 5090 oswe die Tesla/Quadros finde ich man noch keine Benchmarks. Auf der anderen Seite wird die halt aktuell für 3000-5000€ gehandelt (je nachdem wie lange man auf die Lieferung warten will). Mit dem größten Modell von AMD (7900 XTX) dürfte man um ein vielfaches langsamer sein. (Aber auch entsprechend weniger Zahlen...) während bei Nvidia noch Platz nach oben ist.
War mir zu viel Zeit mich da einzulesen. Zeig' mal ein Beispiel wie das geht, aus einer Wortlistendatei beliebige Doppelkombinationen mit einem Sonderzeichen aus einem Zeichenvorrat (!,.;-*) am Ende zu testen.
Kann man schöner machen. Ich würde es so machen:
Code: Alles auswählen
hashcat -m 23003 -a 1 hash dict dict -k '$!'
hashcat -m 23003 -a 1 hash dict dict -k '$.'
..
Real sind über 50% der Sonderzeichen in Passwörtern ein ! am Ende...
Das bedeutet aber im Umkehrschluss mein Notebook mit LUKS2 ist gar nicht so sicher, auch wenn es gesperrt ist könnte man sich Kopien ziehen (wenn man an die Hardware kommt) und irgendwann Daten herstellen?
Und auch meine externe HDD die mit LUKS2 verschlüsselt ist wäre gar nicht so sicher und ich müsste vor jedem Backup das LUKS2 neu anlegen um das zu vermeiden?
Ja. Wie gesagt: Das besagte Beispiel (großes unkomprimierte Zeichnung) ist ziemlich optimal und real braucht es bei einer ganzen Festplatte vermutlich ganz schön lange bis einige ähnliche Dateien aus Zufall aufeinander fallen. Daneben bleibt die aes-cbc-essiv:sha256 Variante, die bei in der Kombination mit LUKS2 und --identity oder btrfs absolut keine Nachteile mehr hat außer dass sie relativ komplex und eventuell auf mancher Hardware langsamer ist.
