Hallo TM
kannst du mal anhand eines konkreten Beispiels
- Länge Zustandsvektor
- Länge Hash
- Blockgrösse bei Absorption
erläutern, was du tust?
Durch die "Länge" des verwendeten Zustandsvektors und die Länge des Hashs ist die Blockgrösse bei jedem Absorptionsschritt ja eigentlich vorgegeben - und du hast damit keinen Spielraum, wie viele Bits des Zustandsvektors bzw. der Nachricht je Absorptionsschritt verwendet werden dürfen.
Oder anders geschrieben: Falls deine absorb() Funktion genau einen Absorptionsschritt erledigt, dann ist der zweite Parameter nicht frei wählbar.
Zitat:
Ich habe es mittels Schleife jetzt so umgesetzt, dass er immer max.
BufferSize an Daten berechnet, damit auch große Datenmengen möglich sind.
Ich kenne eure Codes nicht. Da aber sowohl der Zustandsvektor wie auch der Hash feste (von der Länge der Nachricht unabhängige) Grösse haben, sehe ich nicht, wo bei der Absorption ein Problem entsteht, wenn eine lange Nachricht verarbeitet werden muss. War es im ursprünglichen Code schlicht nicht vorgesehen/möglich?
(Delphi technisch: Da SHA3 die Nachricht Block nach Block absorbiert, wäre in einigen Anwendungsfällen (zum Beispiel bei grossen Nachrichten) die Verwendung eines Streams ok(?))
Deine Frage 2 ist - wenn ich dich richtig verstehe - Delphi technischer Natur und nicht SHA3 Mathe.
Punkto Mathe hast du ja bereits alles. Da Nachrichtenlänge mod Blocklänge selten 0 ist, musst du auch bereits bei deiner Byte basierten Lösung meistens den letzten zu verarbeitenden Nachrichtenblock auffüllen (10..01 Padding). Das ist Bit basiert genau gleich.