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

[Michael II]

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.

[TurboMagic]

Hallo,

was ich tue ist im Development (und seit eben auch im Master) Branch dieses
Repositories zu finden:

https://github.com/MHumm/DelphiEncryptionCompendium

Als Beispiel kann der Unit Test mit dem originalen 1600 Bit NIST Testvektor
von A3 dienen. Beim SHA3-224 habe ich als Blockgröße 144 Byte drin, womit die
200 Byte des Testvektors größer wären als die Blockgröße.

Meine Schleife funktioniert in sofern, dass als Ergebnis auch der vom NIST
publizierte raus kommt.

So wie der ursprüngliche Code von W. Erhardt geschrieben war, musste man ja immer
die länge der zu verarbeitenden Daten in Bit angeben, was bei größeren Datenmengen
evtl. nicht ausgericht hätte, da man dann maximal MaxInt div 8 Byte verarbeiten
könnte.

Richtig?
Ich habe nur in Herrn Erhardts (un den kann man ja leider nicht mehr fragen) Code
nichts gesehen was diese Fälle behandelt hätte, daher die Schleife.

Zu der Stream Idee: die DEC bietet bereits Stream basierte Methoden, aber eben
nicht nur. Und alle Methoden rufen intern die Calc Methode auf, in welcher ich jetzt
die Schleife umgesetzt habe.

Hier ein etwas einfacheres Testprogramm als die Unit Tests:

Delphi-Quellcode:

program Hash_Console;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  DECFormat,
  DECHash;

var
  s  : RawByteString;
  WE : THash_SHA3_224;
begin
  WE := THash_SHA3_224.Create;
  try
    WriteLn('SHA3 224 Test');
    s := '';

    for var i := 1 to 200 do
      s := s + #$A3;

    s := WE.CalcString(s, TFormat_HexL);
    WriteLn(s);
  finally
    WE.Free;
  end;

  ReadLn;
end.

Korrektes Ergebnis (NIST) ist dieses:
9376816aba503f72f96ce7eb65ac095deee3be4bf9bbc2a1cb 7e11e0

Grüße
TurboMagic

[Michael II]

Das wollte ich eigentlich zuerst schreiben: Wenn's funktioniert, dann ist es ja sicher auch richtig ;-).

Deinen Code muss ich dann mal laden, wenn...

Du verarbeitest bei SHA3-224 bei einer Wortlänge von 2^6 im Zustandsvektor bei der Absorption jeweils eine Blockgrösse von r = 25*2^6 - 2*224 = 1600 - 2*224 = 1152 Bit, dies entspricht deinen 144 Byte. Also ok.

Dann nehme ich an, dass Blocksize in deinem Code in #4 in Byte abgespeichert ist (in deinem SHA3-224 Fall also 144) und deine Absorption absorb() (wie erwartet und sinnvoll) genau einen Absorptionsschritt durchführt, und der zweite Parameter deiner absobrb() Funktion die Blockgrösse in Bit (also hier 1152) erwartet (deshalb dein *8).

Du fragst in #4

Zitat:

Wie muss man folgenden Code ändern, damit nicht immer nur BlockSize
an Daten in einem Schritt verarbeitet werden, sondern soviel wie möglich

Geht nicht. Lass es so wie es ist. "Blocksize an Daten" ist genau soviel wie geht. Remember: SHA3 arbeitet die Nachrichtenblöcke nacheinander in deinen Zustandsvektor ein.

Besten Dank für deine Arbeit!

Gruss und viel Spass,
Michael

[TurboMagic]

Danke für deine Bestätigung!
Das hilft mir mental sehr!

Im übrigen scheinst du gute Kryptographiekenntnisse
zu haben!

Grüße
TurboMagic