it-swarm.com.de

Sollten wir SHA3 verwenden? (2017)

Diese Frage ist ein Duplikat , aber ich denke, dass es angesichts der Frage notwendig ist. Das Original wurde 2012 veröffentlicht: vor ungefähr 5 Jahren, bevor NIST die endgültige Spezifikation überhaupt veröffentlicht hatte.

Die Frage ist mehr oder weniger dieselbe wie das Original. Wurde SHA3 ausreichend untersucht, um als sicher für Situationen mit hohem Wert angesehen zu werden, und hat die Verwendung einen Vorteil gegenüber dem Vorgänger SHA2. Grundsätzlich sollten wir es verwenden?

12
Awn

Ich bin nicht davon überzeugt, dass wir sollten. SHA-3 hat sicher einige NiceFeatures , aber aus den unten aufgeführten Gründen würde ich wahrscheinlich vorschlagen, vorerst SHA-2 oder BLAKE2 zu verwenden. Sogar NIST selbst sagen:

Derzeit ist es nicht erforderlich, Anwendungen von SHA-2 auf SHA-3 umzustellen.


Das heißt, Sie denken vielleicht immer noch "warum nicht"?

  1. SHA- ist noch nicht FIPS-140-konform . Ohne FIPS 140- ist es für nichtmilitärische Regierungsbehörden und Regierungsunternehmen unerreichbar. Wenn Sie sich Sorgen über die Konformität mit FIPS) machen, bleiben Sie vorerst bei der SHA-2-Suite.  SHA-3 was enthalten in FIPS 140-2 Anhang A, und obwohl In diesem Dokument steht immer noch "Entwurf" auf dem Deckblatt. Es scheint über diesezwei Seiten abgeschlossen worden zu sein.
  2. Leistung . SHA-3 ist nglaublich schnell in Hardware (ASIC) -Implementierungen . Es ist jedoch viel langsamer in Software, die auf CPUs mit begrenzten Registern ausgeführt wird, was bedeutet, dass es im Allgemeinen weniger nützlich ist *. Sein Hauptkonkurrent (zumindest nach dem Wettbewerb) ist BLAKE2, das sich auf allgemeinen CPUs als viel schneller erwiesen hat und manchmal gegenüber Keccak/SHA-3 für andere) bevorzugt wird Gründe . Ich bin der Meinung, dass NIST die Unterschiede in der Software-Leistung zwischen den Finalisten unterschätzt hat, aber ihre Kommentare zur Leistung in der letzten Entscheidungsrunde können hilfreich sein, um den Kontext bereitzustellen. Aus NISTIR 7896 , Abschnitt 3.2:

    ein. Alle fünf Finalisten schneiden gut genug ab, um in den meisten Anwendungen eingesetzt werden zu können.
    B. Keiner der fünf Finalisten ist der Beste für jede Anwendung, und keiner bietet wirklich überzeugende Verbesserungen gegenüber den SHA-2-Algorithmen.
    C. Die ARX-basierten Algorithmen BLAKE und Skein arbeiten in Software sehr gut.
    D. Keccak hat einen klaren Vorteil in Bezug auf Durchsatz-/Bereichsleistung bei Hardware-Implementierungen.
    E. Grøstl und JH sind in den meisten Software-Implementierungen erheblich langsamer als die anderen drei Algorithmen.

  3. Möglicherweise unnötige Vorsicht . Es ist auch erwähnenswert, dass BLAKE aufgrund von wie ähnlich es war zu SHA-2 negative Bemerkungen erhielt. Aus Vorsicht half dies Keccak/SHA-3, den Wettbewerb zu gewinnen. Aus NISTIR 7896 , Abschnitt 3.4:

    b. Da SHA-2 ein ARX-basiertes Design mit einem Schlüsselplan ist, hat es einige wichtige Designelemente gemeinsam mit BLAKE und Skein, obwohl keines eng mit SHA-2 verwandt ist. Kryptoanalytische Tools, die in Zukunft für SHA-2 gelten, gelten jedoch eher für BLAKE oder Skein als für die anderen drei Finalisten.

* Denken Sie daran, dass wir hier kryptografische Hash-Funktionen diskutieren, nicht unbedingt Passwort-Hashing-Funktionen oder KDFs.


Noch etwas Lesen, das die Zeit wert sein könnte:

  1. NIST hat Sie vielleicht nicht im Sinn , von Adam Langley
  2. Die Keccak-Schwammfunktionsfamilie
  3. NISTIR 7896
  4. BLAKE2: "Härter, besser, schneller, stärker" als MD5
  5. Warum SHA-1 durch BLAKE2 ersetzen?
  6. Vielleicht SHA-3 überspringen
7
JZeolla