DEC Design Frage (SHA3)

[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

[Michael II]

Hallo TM

ich habe in der vergangenen Nacht deine DEC geladen, getestet und dann gesehen, dass in deiner Schleife der Data-Pointer nicht angepasst wird. absorb() liest deshalb immer die ersten Bytes der Nachricht und liefert falsche Resultate (ausser bei N=xxxxxxxxx.xxxxxxxxx, x=0..255)

Bei deinem Test mit der Nachricht for var i := 1 to 200 do s := s + #$A3; fällt das Problem nicht auf, da absorb() immer nur #$A3 liest. Dein absorb() in der Schleife las halt bei jedem Durchlauf die ersten Bytes anstatt korrekt der Reihe nach irgendwann alle.

So sollte es funktionieren (Code unten). Du oder irgendwer hier im Forum können das sicher schöner schreiben . V.a. aber nicht nur Englischer und so...

Ich habe hier unten im Code eine Variable prorunde eingebaut. Das war nur zum Testen der Funktionsweise von absorb(N,x). (Ein Kontentheoretiker hat uns mal während einer Woche besucht und jene mathematische Probleme aufgezählt, für welche 17 die Lösung ist. Wenn man also mal nicht weiter weiss, dann ist 17....).
absorb(N,x) ist so geschrieben, dass du für prorunde irgend einen positiven Wert <= maxint div 8 wählen kannst. Ein hoher Wert macht natürlich Sinn.

Delphi-Quellcode:

procedure THash_SHA3Base.Calc(const Data; DataSize: Integer);
var prorunde, absorb_byte : integer;
    gelesen : integer;
    p : PByte;

begin
  // due to the way the inherited calc is constructed it must not be called here!
  if (DataSize > 0) then
  begin
    p := Pointer(@Data);
    gelesen := 0;
    prorunde := 17;
    while ( DataSize > 0 ) do
    begin
      absorb_byte := DataSize;
      if absorb_byte > prorunde then absorb_byte := prorunde;
      Absorb( @p[gelesen], absorb_byte*8);
      inc( gelesen, absorb_byte );
      dec( DataSize, absorb_byte );
    end;
  end
  else
    FinalStep;
end;

Ich habe die Funktion getestet mit drei SHA3-224 Onlinerechnern; scheint OK zu sein.