DEC Design Frage

[TurboMagic]

Hallo,

beim Untersuchen eines mir gemeldeten Bugreports zum SHA3 Algorithmus bin ich auf ein Design
Detail gestoßen welches den Bug verursacht hat und das ich hier mal diskutieren möchte um
Rat zu erhalten.

Der Bug ist, dass bei nutzung von CalcStream oder CalcFile (das ruft intern CalcStream auf)
mit dem SHA3 Algorithmus eine Exception ausgelöst wird, wenn nach CalcStream Done aufgerufen
wird. Fängt man die ab, kann man trotzdem den korrekten hash Wert abrufen.

Done ist eigentlich zum Abschließen einer Hash Operation gedacht (so verstand ich jedenfalls
was ich da geerbt habe).

Jetzt habe ich herausgefunden, dass Done auch im CalcStream am Ende aufgerufen wird und
beim SHA3 wird innerhalb des Done eine Methode aufgerufen, die man für eine SHA3 Verarbeitung
nur einmalig aufrufen darf. Da es intern ein Flag gibt das ich nutzen kann, hab' ich im
Entwicklungszweig das mal einfach abgefragt und den Aufruf dann unterdrückt. Damit ist die
Exception zwar weg, aber ich frage mich, ob der Done aufruf im CalcStream so das wahre ist.

CalcStream ist bisher aber auch so gebaut, dass es direkt den berechneten Hash zurückliefert
und dazu Done vorher aufgerufen werden muss. Die Frage ist halt auch, ob mehrere verkettete
CalcStream Aufrufe in der Praxis irgendwie sinnvoll sein können, dann wäre die Architektur
wie sie ist nicht gut, oder ob ich mir zu arg den Kopf über unwichtige Dinge zerbreche?

Grüße
TurboMagic

[Sinspin]

Hey,

CalcStream ist selber kein Teil von SHA3?
CalcStream mach das Init selber?
CalcStream könnte nicht mehrmals aufgerufen werden um verschiedene Streams zu dem SHA3 hinzuzufügen?
Alles nein, dann frage ich mich warum sich CalcStream herausnimmt den SHA3 abzuschließen ;-).

Generell ist das aber eine globale Designfrage.
Wie ist es für alle anderen Hashes gelößt?

Generell bevorzuge ich eine klare Stuktur für solche Verfahren.
Ein Satz Methoden die ich einzel aufrufen kann um flexibel zu sein (Init, Data, Done)
Und einen weiteren Satz Methoden (Funktionen) die alles Kapseln um mit einem Aufruf ein verwertbares Ergebnis zu haben. Zum Beispiel für einen String, einen Stream....

[TurboMagic]

Hallo,

falls interessant: ich habe im Entwicklungszweig jetzt eine Fassung die ein weiteres Overload für CalcStream erhalten hat.
Dieses ruft init nicht auf, das muss man irgendwo vorher mal selber tun, liefert keinen berechneten Hash zurück,
den kann man ja via DigestAsXXX methoden bekommen und hat aber einen neuen Parameter: IsLastCall.
Beim Letzten Aufruf vor dem Abrufen des berechneten Hashes muss dieser Parameter true sein, sonst muss er false sein.
Der führt zum Aufrufen von Done und bei SHA3 ggf. zur korrekten Behandlung des letzten ggf. unvollständigen Bytes.

Da letzteres von Anwendern sicher gerne vergessen worden wäre und ich zumindest anfänglich Probleme in den Unit Test
hatte als ich auch das Done aus der Methode haben wollte, hab' ich mich für diese Variante entschieden.

Im Falle leerer Daten muss man es ja trotzdem mit 0 Byte als Längenangabe aufrufen und IsLastCall muss auch true sein.

Ich hoffe das ist so akzeptabel, auf alle Fälle kann man dadurch Streams besser nutzen.

Grüße
TurboMagic

[EdAdvokat]

Hallo TurboMagic,
an welche praktischen Anwendungsfälle hast Du gedacht, als Du die neue zusätzliche Überladung für CalcStream aufgenommen hast?

Damit soll es möglich sein, einem Stream mehrmals Daten hinzuzufügen und dann erst den Hashwert berechnen zu lassen.
Ich frage mal vorsichtig, ist dies denn mit den Vorgaben für den SHA3-Algorithmus vereinbar oder gibt es dazu keine Festlegungen.

[TurboMagic]

Naja, die Idee ist simple:
Man weiß vorher noch nicht wie viele Daten es sein werden oder es ist mehr, als man im Speicher puffern will.
Also möchte man diese Daten stückweise verarbeiten und füttert immer ein weiteres Stückchen dem CalcSteam, bis man
weiß, das man jetzt das letzte Stück bekommen hat. In dem Fall setzt man diesen letzten parameter auf true.

Danach kann man seinen berechneten Hash-Wert vie DigestAsXXX Methode abholen.
Und ja, das verträgt sich mit SHA3, wie meine Unit Tests für die neue CalcStream Variante ja zeigen dürften.
Die nudeln wieder alle SHA3 Testvektoren aus den Testdatendateien durch.

Ich hoffe damit alle Zweifel beseitigt zu habern?

Grüße
TurboMagic

[Sinspin]

Zitat:

Zitat von TurboMagic (Beitrag 1498675)

Ich hoffe damit alle Zweifel beseitigt zu habern?

Ich habe meine Zweifel an der Sinnfälligkeit des Parameters

Delphi-Quellcode:

IsLastCall

.
Das mag jetzt ein etwas grenzwertiges Beispiel sein. Aber versuch den Parameter mal ein einer rekursiven Funktion mit zufälliger Tiefe zu setzen.
Es ginge dann nur indem ich hinterher noch einen Call mache mit einem Byte Müll, nur um

Delphi-Quellcode:

IsLastCall

setzen zu können.

[TurboMagic]

Zitat:

Zitat von Sinspin (Beitrag 1498680)

Zitat:

Zitat von TurboMagic (Beitrag 1498675)

Ich hoffe damit alle Zweifel beseitigt zu habern?

Ich habe meine Zweifel an der Sinnfälligkeit des Parameters

Delphi-Quellcode:

IsLastCall

.
Das mag jetzt ein etwas grenzwertiges Beispiel sein. Aber versuch den Parameter mal ein einer rekursiven Funktion mit zufälliger Tiefe zu setzen.
Es ginge dann nur indem ich hinterher noch einen Call mache mit einem Byte Müll, nur um

Delphi-Quellcode:

IsLastCall

setzen zu können.

Hallo,

wozu der Aufruf mit 1 Byte Müll?
Du kannst das legal auch mit einem Count von 0 aufrufen.

Wie gesagt: ich hatte es auch versucht ohne den Parameter umzusetzen und man hätte dann nach dem letzten
Aufruf selber manuell DOne aufrufen müssen. Nur hat da was irgendwie nicht geklappt und ich habe auch nicht
wirklich rausgefunden wie ich das ändern müsste damit es auf diese weise funktioniert. Auch meine Zeit ist
leider endlich...

=> wenn mir jemand eine funktionierende Lösung liefert bei der man sich diesen Boolschen Parameter sparen kann
gerne, das muss aber auch mit dem SHA3 funktionieren, also alle vorhandenen Unit Tests bestehen!
Freiwillige vor ;-)

Grüße
TurboMagic