DEC Design Frage (SHA3)

[TurboMagic]

Hallo,

so wie es scheint, bekomme ich den SHA3 langsam in den Griff.
Ich habe mal SHA3 224 durch Umbau von Wolfgang Erhard's (WE) Code
"roh" umgesetzt (siehe Entwicklungszweig) und mit einem Konsolenprogramm
mit dem offiziellen NIST 200 Byte Testvektor mal grundsätzlich getestet.

Nur habe ich da ein paar Fragestellungen:

1. Der ganze SHA3 Code basiert immer auf Bit als Größenangabe statt Byte.
Ich habe es mittels Schleife jetzt so umgesetzt, dass er immer max.
BufferSize an Daten berechnet, damit auch große Datenmengen möglich sind.
Gegenüber WE's Code kann das leichte Performanceverluste ergeben, da
mehr Funktionsaufrufe als bei ihm nötig auftreten können. Es geht dabei
um den Absorb Aufruf.
Die Alternative wäre, bis zu einer maximalen Datengröße die in Bit in
das Größenfeld des Absorbs passt diesen direkt aufzurufen und dann für
den evtl. vorhandenen Rest nochmal. Wie muss ich eine Prüfung ob die zu
bearbeitende Datengröße * 8 ohne Überlauf in den entsprechenden Parameter
des Absorb Aufrufes passt?

2. Der SHA3 Algorithmus hat als besonderheit im Vergleich zu anderen
Hash-Algorithmen die Eigenschaft, dass auch unvollständige Bytes verarbeiten
können. Also das Bilden eines Hashes über nur 5 Bit oder über 9 Bit ist
möglich. Nur passt das bisher nicht zur Architektur der DEC.
Wie müsste sowas angeboten werden?
Als eigentsändige Methoden in der SHA3 Basisklasse?
Und für welche Datentypen sollte das sinnvollerweise umgesetzt werden?
Diese "Sondervarianten" wären dann halt nicht in den vorhandenen Interfaces
drin oder für andere Methoden wie KDF etc. verfügbar, das ist aber vermutlich
verschmerzbar, da Hashes für solche nicht in ganzen Bytes dimensionierten
Datengrößen sicher nicht so oft benötigt werden. Oder?

Wenn das so passt, was ich da umgesetzt habe sollte wohl in absehbarer Zeit
eine neue Version mit SHA3 Unterstützung verfügbar sein.

Grüße
TurboMagic

[Michael II]

Du solltest deine Arbeit unbedingt hier anmelden und verlinken lassen:

https://keccak.team/software.html

(Falls du nicht bereit drauf bist, unter anderem Namen )

[TurboMagic]

Hallo,

danke für den Tipp. Dazu muss es aber noch vollends reifen.
Und das war ja meine hauptsächliche Fragestellung: wie mit
diesen Bit Größenangaben sinnvoll umgehen?

Grüße
TurboMagic

[TurboMagic]

Hier eine meiner Fragestellungen präzisiert.
Wie muss man folgenden Code ändern, damit nicht immer nur BlockSize
an Daten in einem Schritt verarbeitet werden, sondern soviel wie möglich
aber ohne, dass dieses * 8 zur Umrechnung in Bit zu einer verminderung
der maximal insgesammt möglichen Datengröße führt?

DataSize ist übrigens ein Integer (ja man müsste mal untersuchen ob man das
problemfrei auf UInt32 oder UInt64 ändern kann, aber die Methodensignatur
nutzen auch alle anderen Hash Algorithmen der DEC).

Delphi-Quellcode:

while (UInt32(DataSize) >= BlockSize) do
begin
  Absorb(Pointer(@Data), BlockSize * 8);
  Dec(DataSize, BlockSize);
end;

Grüße
TurboMagic

[himitsu]

BlockSize erhöhen?

Ich denke mal das ist grade dafür da, um den gleichzeitig verwendeten Speicher zu begrenzen/partitionieren?

Gibt es nach der Schleife noch eine Behandlung für den "Rest"? (kleiner als Blocksize)

Delphi-Quellcode:

if UInt32(DataSize) >= BlockSize then  // falls Absorb bei Size=0 nicht abraucht, dann könnte man das IF auch weglassen
begin
  Absorb(Pointer(@Data), (UInt32(DataSize) div BlockSize * BlockSize) * 8);  // wenn BlockSize immer eine 2er-Potenz ist, dann könnte man auch einfach eine Bitmaske drüberegen/ANDen)
  DataSize = {Int32}(UInt32(DataSize) mod BlockSize);  // DateSize-Typ? um keinen eventuellen Überlaufcheck-Code vom Compiler reinzubekommen
end;

[TurboMagic]

Ja nach der Schleife gibt's noch einen Aufruf für den Rest.
Sonst wäre für alle Situationen wo's einen Rest gibt das
Ergebnis falsch.

Man könnte die Blocksize erhöhen ja, aber das wäre ja auch
wieder statisch und ich bin mir auch nicht mehr sicher, woher
ich die aktuell benutzten Werte für die Blocksize(s) der
SHA3 Varianten habe. Ich habe mir damals (musste das leider
immer wieder liegen lassen) hoffentlich was dabei gedacht...

Ich hatte mirn eigentlich einen allgemeinen Lösungsansatz
erhofft, bin mir nur halt nicht sicher wie ich mit dieser
Begrenzung durch die Basierung der Datengröße auf Bits statt
Byte umgehen müsste...

Grüße
TurboMagic