DEC Design Frage (SHA3)

[himitsu]

Zitat:

Wolfgang Erhardts DEC wird erwähnt

Wolfgang hatte auch eine kryptographische Bibliothek,
aber das DEC (Delphi Encryption Compendium) und DECMath waren von Hagen Redmann.

[Michael II]

Zitat von TurboMagic:

Hallo,

1. Der Benchmark bezieht sich auf diese hier, oder?
https://github.com/Xor-el/HashLib4Pascal

2. An der bin ich nicht beteiligt, die enthält aber ein paar Algorithmen (ich rede jetzt nicht
von den nicht kryptographischen) die in DEC noch fehlen. Aber eins nach dem anderen.

3. Der ursprüngliche Autor der DEC war Haagen Redmann. Ist der gestorben?
Der hatte irgendwann einfach kein Interesse mehr daran. Die DEC ging dan auf Assertor
(Frederik Winkelsdorf, Freelancer aber leider nicht mehr im Delphi Umfeld) über und
dann bin ich eingestiegen und habe nauch einiger Zeit der "Betreuung" meines Tuns durch
Frederik die DEC dann ganz übernommen, freue mich aber genre über weitere unterstützer,
da auch meine Zeit und Kenntnisse endlich sind.

4. Der Autor der eingebauten SHA3 Lösung war der tatsächlich gestorbene Wolfgang Erhardt.

So und ich mach mich jetzt an ein paar Formatierungsverbesserungen und in der SHA3Base
sind glaube ich auch noch ein paar Sachen public die eher private/protected sein sollten...

Grüße
TurboMagic

1. Ja genau. DEC ist schneller auf meinem Uraltnotebook (i7-3632QM CPU).

2. OK. V.a. für heute noch genutzte Dinge interessant und natürlich nur wenn schneller als bei den anderen .

3. Merci. Ich schreibe heute noch 10 Mal von Hand "RTFM".

4. Eric Grange beschreibt wie er ThetaRhoPiChiIota schneller als Wolfgang Erhardt geschafft hat. Das tönt interessant.

[TurboMagic]

Hallo,

hier noch der relevante Auszug aus meiner Anfrage an das NIST wegen der Testdaten die ich dort gefunden hatte:

"Your observation is correct that the example values do not catch some implementation failures. However, this is not their intended purpose: they are sample values, not test vectors.

The goal of the sample values is to make it easy to understand the intermediate values of the algorithm. By choosing a repeating pattern, we can recognize many other repeating patterns in the first few intermediate values of the algorithm. The non-repeating pattern that you propose does not have this property, and may therefore be less suitable as sample to understand the intermediate values.

If test vectors for SHA-3 are needed, they can be found here: https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/Secure-Hashing"

Grüße
TurboMagic

[Michael II]

Die Seite Cryptographic Standards and Guidelines ist auch sehr interessant (nicht nur für SHA3). Dort wird für SHA3 (FIPS 202) für einige Testvektoren Runde für Runde die Keccak Permutation (Beispiel) durchgerechnet. Das ist v.a. für Leute sehr brauchbar, welche den schnellsten SHA3 Hash Code programmieren wollen und nicht gleich auf Anhieb den gewünschten Output erhalten.

Wieso NIST derart den Narren gefressen hat an Testvektoren wie 43434343.... ist schwer nachvollziehbar. Sie publizieren aber zum Glück auch (gut sortiert) massenhaft andere.

[Michael II]

Ich habe jetzt noch die in #25 erwähnte Optimierung getestet. Eric Granges optimierter ASM-Code schafft bei SHA3_256 rund 160MB/s. DEC momentan rund 52MB/s.

[ Ganz was anderes, aber auch SHA3... im Netz gibt es viele Webseiten, auf welchen man eigene Passwörter eingeben kann, um zu prüfen, wie Hacker sicher diese sind. Man kann auch den SHA3 Hash eines Passwortes eingeben und raus kommt das Passwort, (natürlich) falls in der jeweiligen DB vorhanden. Wenn das Passwort in DB noch nicht vorhanden war, dann sicher bald in der nicht öffentlichen DB2 . ]

[TiGü]

Wie soll denn das gehen?
Wie soll denn aus dem SHA-3 Hash das Passwort zurück gerechnet werden?

[himitsu]

ähnlich wie für MD5?

Da gibt es schon vollständige Rainbowtables, mit jedem existierenden Hash, zu dem "irgendein" Passwort hinterlegt ist. (oder sogar Mehrere)


Du bekommst also nicht "dein" Passwort, sondern Igendeines, welches aber den selben Hash besitzt.

[Rollo62]

Zitat von Michael II:

Wieso NIST derart den Narren gefressen hat an Testvektoren wie 43434343.... ist schwer nachvollziehbar.

Vielleicht weil viele Leute auch Passwörter wie CCCCCC nutzen

[TurboMagic]

Zitat von Michael II:

Ich habe jetzt noch die in #25 erwähnte Optimierung getestet. Eric Granges optimierter ASM-Code schafft bei SHA3_256 rund 160MB/s. DEC momentan rund 52MB/s.

Wie hast du das getestet?
Sein Projekt runtergeladen und ausgeführt?

Ich muss meine SHA3 Arbeiten (da steht noch die Sache mit dem Umstellen des Fehlerhandlings
aus und sicherheitshalber die Integration der besseren NIST Testvektoren) wohl ein paar Tage auf Eis legen.
Jemand hat im SCOOP Algorithmus bugs gefunden, die aber scheinbar nur auf nicht Intel CPUs auftreten...
Scheint ein FPC Benutzer zu sein und hat auf Nachfrage (siehe Issues bei DEC) auch vernünftig reagiert.

Grüße
TurboMagic

[Michael II]

Zitat von TurboMagic:

Zitat von Michael II:

Ich habe jetzt noch die in #25 erwähnte Optimierung getestet. Eric Granges optimierter ASM-Code schafft bei SHA3_256 rund 160MB/s. DEC momentan rund 52MB/s.

Wie hast du das getestet?
Sein Projekt runtergeladen und ausgeführt?

Ich muss meine SHA3 Arbeiten (da steht noch die Sache mit dem Umstellen des Fehlerhandlings
aus und sicherheitshalber die Integration der besseren NIST Testvektoren) wohl ein paar Tage auf Eis legen.
Jemand hat im SCOOP Algorithmus bugs gefunden, die aber scheinbar nur auf nicht Intel CPUs auftreten...
Scheint ein FPC Benutzer zu sein und hat auf Nachfrage (siehe Issues bei DEC) auch vernünftig reagiert.

Grüße
TurboMagic

Hallo TM,
ja, ich habe sowohl mit DEC wie mit Grange (über KeccakPermutationKernel in dwsSHA3.pas) viele Male einen RawByteString mit Länge 100 Mio Bytes verarbeiten lassen und die Zeit gemessen. (Uralt Core(TM) i7-3632QM).

Hast du gesehen TM? Rollo62 weiss wieso einfache Textvektoren wie XXXXXX bei NIST sogar Testvektoren sind. Ich wäre selber nie darauf gekommen. Danke Rollo62.

Zu TiGü #36: Hashwert -> Passwort geht eben relativ schlecht . Deshalb werden die von in #35 und #37 erwähnten Datenbanken angelegt und genutzt.

Zu #37: Klar... Hash Funktionen sind nicht injektiv: Die Definitionsmenge hat in der Regel mehr Elemente als die Wertemenge. Deshalb könnten in der Tat mehrere Passworte den gleichen Hashwert haben. - Wenn du aber davon ausgehst, dass Passworte eine Länge l mit l<=16 aufweisen und pro Zeichen ca. 100 voneinander verschiedene Werte verwendet werden, dann hast du für l<=16 ~2^106,32 Passworte*, die Menge aller SHA3-256 Werte aber ist mit 2^256 Elementen mächtiger. D.h. es wird maximal (maximal, falls 0 Kollisionen) nur jeder 2^(256-2^106.32)=2^149.68ste Hashwert überhaupt getroffen.
*hier sind alle Summe(100^l (l=1 bis 16)) möglichen Zeichen-Kombinationen berücksichtigt - meistens weisen Passworte Muster auf. Effektiv verwendet wird nur ein sehr kleiner Bruchteil aller möglichen Passworte.

"Brute Force" für einfache Passwörter: Mit "Grange" kann ich auf meinem Core(TM) i7-3632QM pro Sekunde für 1.3 Mio Passworte die SHA3-256 Werte berechnen lassen (Da für alle Passworte mit Länge l<=135Byte in Bit gilt l < r=b-2*n-2=1600-512, wird immer nur genau eine Keccak Permutation durchgeführt). Wenn ich alle Passworte der Form 4'000 mögliche Namen, dann 1 bis 3 stellige Zahl, und abschliessend eines aus 30 möglichen Sonderzeichen durchchecken will, dann sind das 4000*1000*30=120 Mio Passworte. Mit meinem bescheidenen Rechner sind nach zwei Minuten alle solchen Passworte erstellt und alle SHA3 Werte (multithreaded) berechnet. Im Schnitt finde ich mit Grange zu gegebenem SHA3-256 Hash ein solches Passwort (falls es in der Liste der 120 Mio Passwörter vorkommt) also in einer Minute. Grossrechner schaffen mehrere Milliarden SHA3 Werte pro Sekunde.
Spielerei.., ich weiss. Sehr wahrscheinlich kennen aber viele Menschen andere Menschen, welche ziemlich genau diesen Passworttyp verwenden.

Falls sich jemand hier mal mit SHA3 Hashes von kurzen* Vektoren (*Hash nach einer Keccak Permutation berechnet) befasst hat oder ein Paper dazu kennt... das wäre interessant.