Warum wird das Tag in einem getaggten Hash zweimal wiederholt?

Mir ist aufgefallen, dass der Hash-Nachricht für den getaggten Hash in BIP340 das Präfix SHA256(tag) || vorangestellt ist SHA256(tag), was auch den Grund beschreibt

Da es sich um eine 64 Byte lange kontextspezifische Konstante handelt und die SHA256-Blockgröße ebenfalls 64 Byte beträgt, sind optimierte Implementierungen möglich (identisch mit SHA256 selbst, jedoch mit geändertem Anfangszustand). Die Verwendung von SHA256 des Tag-Namens selbst ist relativ einfach und effizient für Implementierungen, die sich nicht für die Verwendung der Optimierung entscheiden.

Aber ich habe einige Verwirrung

  1. "Optimierte Implementierungen sind möglich": Worüber wird hier konkret gesprochen, wird die Optimierung dadurch verursacht, dass das Präfix dieselbe Größe wie die Blockgröße von SHA-256 hat? Wenn ja, kann diese Schlussfolgerung auf alle Block-Hashing-Algorithmen verallgemeinert werden? dh die gleiche Größe des Präfixes und des Blocks des Algorithmus kann zu einer Optimierung führen.
  2. „Die Verwendung von SHA256 für den Tag-Namen selbst ist ziemlich einfach und effizient für Implementierungen, die sich nicht für die Verwendung der Optimierung entscheiden.“ : Bedeutet dies, dass, wenn die Implementierung keine Optimierung übernehmen möchte, das Tag nicht wiederholt werden kann? dh der getaggte Hash wäre SHA256 (SHA256(tag) || msg).

Antworten (1)

  1. "Optimierte Implementierungen sind möglich": Worüber wird hier konkret gesprochen, wird die Optimierung dadurch verursacht, dass das Präfix dieselbe Größe wie die Blockgröße von SHA-256 hat? Wenn ja, kann diese Schlussfolgerung auf alle Block-Hashing-Algorithmen verallgemeinert werden? dh die gleiche Größe des Präfixes und des Blocks des Algorithmus kann zu einer Optimierung führen.

Ja, das bedeutet, dass der SHA256-Hashing-Status bei SHA256(SHA256(tag)||SHA256(tag)||vorberechnet werden kann. Wenn das Tag nur 32 Byte lang wäre, würde dies nicht funktionieren, da Sie 32 Byte Daten kennen müssten, bevor Sie den ersten Block verarbeiten können.

  1. "Die Verwendung von SHA256 des Tag-Namens selbst ist relativ einfach und effizient für Implementierungen, die sich nicht für die Verwendung der Optimierung entscheiden.": Bedeutet dies, dass die Implementierung das Tag nicht wiederholen kann, wenn sie nicht beabsichtigt, die Optimierung zu übernehmen? dh der getaggte Hash wäre SHA256 (SHA256(tag) || msg).

Nein, das würde zu einem anderen Ergebnis führen. All dies sagt aus, dass es eine einfache Konstruktion ist, das gehashte Tag zweimal zu verketten. Natürlich wäre es noch einfacher, es nicht zu verdoppeln, aber das würde die Optimierung aus dem vorherigen Punkt aufgeben.

Vielen Dank für Ihre Antwort. Für Q1: Diese Optimierung muss also den Zwischenzustand SHA256(SHA256(tag) || SHA256(tag)||lokal zwischenspeichern? Also in Zukunft jedes Mal, wenn der Hash des Tags berechnet wird, beginnend mit dem Lesen des Cache-Status? Für Q2: Es tut mir sehr leid, dass ich diese Aussage vorher missverstanden habe, jetzt verstehe ich, dass dies der Grund ist, warum tagged SHA256 direkt auswählt.
Richtig, der Zustand nach der Verarbeitung der ersten 64 Bytes kann vorab berechnet werden, und daher kann die Berechnung eines getaggten Hashs an diesem Punkt beginnen, anstatt ihn jedes Mal wiederholen zu müssen.
Wenn also die Länge des Präfixes ein Vielfaches der Blockgröße ist, funktioniert die Optimierung trotzdem? dh ein direktes Auffüllen des Tags und dessen Verwendung als Präfix. Zum Beispiel prefix = (tag_size, tag, padding), ich muss nur sicherstellen, dass es ein Vielfaches der Blockgröße ist. Der Nachteil ist jedoch, dass dies die Länge des Tags einschränken würde. Stimmt es? Ich werde Ihre Antwort zu schätzen wissen!