it-swarm.com.de

Warum verwendet Git kein moderneres SHA?

Ich habe darüber gelesen, dass Git SHA-1 Digest als ID für eine Revision verwendet. Warum wird keine modernere Version von SHA verwendet?

74
qazwsx

Warum wird keine modernere Version von SHA verwendet?

Dezember 2017: Es wird. Und Git 2.16 (Q1 2018) ist die erste Veröffentlichung, die diese Absicht veranschaulicht und umsetzt.

Hinweis: Siehe Git 2.19 unten: Es wird SHA-256 sein.

Git 2.16 wird eine Infrastruktur vorschlagen, um zu definieren, welche Hash-Funktion in Git verwendet wird, und wird sich bemühen, diese in verschiedenen Codepfaden auszuloten.

Siehe commit c250e02 (28. November 2017) von Ramsay Jones (``) .
Siehe commit eb0ccfd , commit 78a6766 , commit f50e766 , commit abade65 (12.11.2017) von brian m. Carlson (bk2204) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 721cc4 , 13. Dezember 2017)


Fügen Sie eine Struktur hinzu, die den Hash-Algorithmus darstellt

Da wir in Zukunft einen zusätzlichen Hash-Algorithmus unterstützen möchten, fügen Sie eine Struktur, die einen Hash-Algorithmus und alle dazugehörigen Daten darstellt hinzu .
Fügen Sie eine Konstante hinzu, um eine einfache Aufzählung von Hash-Algorithmen zu ermöglichen .
Implementieren Sie function typedefs , um eine abstrakte API zu erstellen, die von jedem Hash-Algorithmus verwendet werden kann, und Wrapper für die vorhandenen SHA1-Funktionen, die dieser API entsprechen.

Setzen Sie ein Wert für die Hex-Größe sowie die Binärgröße .
Während einer immer doppelt so groß ist wie der andere, werden beide Werte in der gesamten Codebasis sehr häufig verwendet und führen zu einer besseren Lesbarkeit.

Fügen Sie keinen Eintrag in die Hash-Algorithmus-Struktur für die Null-Objekt-ID ein.
Da es sich bei diesem Wert nur um Nullen handelt, kann eine beliebige Objekt-ID mit einer geeigneten Größe und Nullen verwendet werden, und es ist nicht erforderlich, eine bestimmte Objekt-ID pro Hash zu speichern.

Der aktuelle Plan für den Übergang zu Hash-Funktionen sieht einen Zeitpunkt vor, an dem wir Eingaben vom Benutzer akzeptieren, die möglicherweise im SHA-1-Format oder im NewHash-Format vorliegen.
Da wir nicht wissen können, was der Benutzer angegeben hat, fügen Sie eine Konstante, die den unbekannten Algorithmus darstellt hinzu, damit wir angeben können, dass wir suchen müssen der richtige Wert auf.


Integrieren Sie die Unterstützung von Hash-Algorithmen in das Repo-Setup

In zukünftigen Versionen von Git planen wir die Unterstützung eines zusätzlichen Hash-Algorithmus.
Integrieren Sie die Aufzählung von Hash-Algorithmen in das Repository-Setup, und speichern Sie einen Zeiger auf die aufgezählten Daten im Struktur-Repository .
Natürlich, wir unterstützen derzeit nur SHA-1, also codieren Sie diesen Wert in read_repository_format.
In Zukunft werden wir diesen Wert aus der Konfiguration auflisten.

Add eine Konstante, the_hash_algo , das auf das hash_algo Strukturzeiger im Repository global.
Beachten Sie, dass dies der Hash ist, der zum Serialisieren von Daten auf die Festplatte verwendet wird, nicht der Hash, der zum Anzeigen von Elementen für den Benutzer verwendet wird.
Der Übergangsplan geht davon aus, dass diese unterschiedlich sein können.
Wir können in Zukunft ein zusätzliches Element hinzufügen (sagen wir ui_hash_algo) für diesen Fall vorzusehen.


Update August 2018, für Git 2.19 (Q3 2018), scheint Git SHA-256 als NewHash auszuwählen.

Siehe commit 0ed8d8d (04. August 2018) von Jonathan Nieder (artagnon) .
Siehe commit 13f5e09 (25. Juli 2018) von Ævar Arnfjörð Bjarmason (avar) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 34f2297 , 20. August 2018)

doc hash-function-transition : wähle SHA-256 als NewHash

Aus Sicherheitssicht scheinen SHA-256, BLAKE2, SHA3-256, K12 usw. ähnliche Sicherheitseigenschaften zu haben.
Unter Sicherheitsaspekten sind alle gute Optionen.

SHA-256 bietet eine Reihe von Vorteilen:

  • Es gibt es schon eine Weile, es ist weit verbreitet und wird von nahezu jeder einzelnen Kryptobibliothek (OpenSSL, mbedTLS, CryptoNG, SecureTransport usw.) unterstützt.

  • Im Vergleich zu SHA1DC sind die meisten vektorisierten SHA-256-Implementierungen sogar ohne Beschleunigung schneller.

  • Wenn wir mit OpenPGP (oder sogar CMS) signieren, werden wir SHA-2 verwenden. Daher ist es nicht sinnvoll, unsere Sicherheit von zwei getrennten Algorithmen abhängig zu machen, wenn einer von ihnen einer ist Allein könnte die Sicherheit brechen, wenn wir uns nur auf eine verlassen könnten.

Also SHA-256 ist es .
Aktualisieren Sie das Entwurfsdokument für Hash-Funktionen-Übergänge, um dies zu sagen.

Nach diesem Patch gibt es keine weiteren Instanzen der Zeichenfolge "NewHash", mit Ausnahme einer unabhängigen Verwendung ab 2008 als Variablenname in t/t9700/test.pl .


Sie können diesen Übergang zu SHA 256 in Bearbeitung mit Git 2.20 (Q4 2018) sehen:

Siehe commit 0d7c419 , commit dda6346 , commit eccb5a5 , commit 93eb00f , commit d8a3a69 , commit fbd0e37 , commit f690b6b , commit 49d166 , commit 268babd , commit fa1308 , commit 7b5e614 , commit 58ce21b , commit 2f0c9e9 , commit 825544a (15. Oktober 2018) bis brian m. Carlson (bk2204) .
Siehe commit 6afedba (15. Oktober 2018) von SZEDER Gábor (szeder) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit d829d49 , 30. Oktober 2018)

ersetzen Sie hartcodierte Konstanten

Ersetzen Sie mehrere 40-basierte Konstanten durch Verweise auf GIT_MAX_HEXSZ oder the_hash_algo, wie angemessen.
Konvertiere alle Verwendungen des GIT_SHA1_HEXSZ benutzen the_hash_algo, damit sie für eine bestimmte Hash-Länge geeignet sind.
Anstatt eine fest codierte Konstante für die Größe einer hexadezimalen Objekt-ID zu verwenden, wechseln Sie zur Verwendung des berechneten Zeigers aus parse_oid_hex, der auf die analysierte Objekt-ID verweist.

GIT_SHA1_HEXSZ wird weiter entfernt/ersetzt durch Git 2.22 (Q2 2019) und commit d4e568b .


Dieser Übergang wird mit Git 2.21 (Q1 2019) fortgesetzt, bei dem sha-256-Hash hinzugefügt und durch den Code gesteckt wird, damit Git mit dem "NewHash" erstellt werden kann.

Siehe commit 4b4e291 , commit 27dc04c , commit 13eeedb , commit c166599 , commit 37649b7 , commit a2ce0a7 , commit 50c817e , commit 9a3a0ff , commit 0dab712 , commit 47edb64 (14. November 2018) und commit 2f90b9d , commit 1ccf07c (22. Oktober 2018) von brian m. Carlson (bk2204) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 33e4ae9 , 29. Januar 2019)

Hinzufügen einer Basisimplementierung der SHA-256-Unterstützung (Februar 2019)

SHA-1 ist schwach und wir müssen zu einer neuen Hash-Funktion übergehen.
Seit einiger Zeit bezeichnen wir diese neue Funktion als NewHash.
Vor kurzem haben wir beschlossen, SHA-256 als NewHash auszuwählen.
Die Gründe für die Wahl von SHA-256 sind in diesem Thread beschrieben und im Festschreibungsverlauf für das Hash-Funktionsübergangsdokument.

Hinzufügen einer Basisimplementierung von SHA-256 basierend auf libtomcrypt, die gemeinfrei ist.
Optimieren Sie es und strukturieren Sie es neu, um unseren Codierungsstandards zu entsprechen.
Holen Sie sich die Update- und Final-Funktionen aus der SHA-1-Blockimplementierung, da wir diese Funktionen bei allen Compilern korrekt kennen. Diese Implementierung ist langsamer als SHA-1, aber in zukünftigen Commits werden performantere Implementierungen eingeführt.

Schließen Sie SHA-256 in der Liste der Hash-Algorithmen an und fügen Sie einen Test hinzu, dass der Algorithmus ordnungsgemäß funktioniert.

Beachten Sie, dass es mit diesem Patch immer noch nicht möglich ist, auf die Verwendung von SHA-256 in Git umzuschalten.
Zusätzliche Patches sind erforderlich, um den Code für einen größeren Hash-Algorithmus vorzubereiten, und weitere Testkorrekturen sind erforderlich.

hash: Fügt eine SHA-256-Implementierung mit OpenSSL hinzu

Wir haben bereits OpenSSL-Routinen für SHA-1, fügen Sie also auch Routinen für SHA-256 hinzu.

Auf einem Core i7-6600U ist diese SHA-256-Implementierung günstiger als die SHA1DC-SHA-1-Implementierung:

SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408 MiB/s (16 KiB chunks)

sha256: Hinzufügen einer SHA-256-Implementierung mit libgcrypt

Im Allgemeinen erzielen kryptografische Routinen, die in Assembly geschrieben wurden, eine bessere Leistung als C, und dies gilt auch für SHA-256.
Darüber hinaus können die meisten Linux-Distributionen Git, das mit OpenSSL verknüpft ist, aus Lizenzgründen nicht vertreiben.

Die meisten Systeme mit GnuPG haben auch libgcrypt, da es sich um eine Abhängigkeit von GnuPG handelt.
libgcrypt ist auch schneller als die SHA1DC-Implementierung für Nachrichten von einigen KB und mehr.

Zum Vergleich: Auf einem Core i7-6600U verarbeitet diese Implementierung 16 KiB-Blöcke mit 355 MiB/s, während SHA1DC äquivalente Blöcke mit 337 MiB/s verarbeitet.

Darüber hinaus ist libgcrypt unter der LGPL 2.1 lizenziert, die mit der GPL kompatibel ist. Fügen Sie eine Implementierung von SHA-256 hinzu, die libgcrypt verwendet.

39
VonC

[~ # ~] Update [~ # ~] : Die obige Frage und diese Antwort stammen aus dem Jahr 2015. Seitdem hat Google den ersten SHA-1 angekündigt Kollision: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html


Natürlich kann ich nur von außen darüber spekulieren, warum Git weiterhin SHA-1 verwendet, aber dies kann einer der Gründe sein:

  1. Git war Linus Torvalds Schöpfung, und Linus will SHA-1 derzeit anscheinend nicht durch einen anderen Hashalgorithmus ersetzen.
  2. Er macht plausible Behauptungen, dass erfolgreiche SHA-1-Angriffe auf Kollisionsbasis gegen Git viel schwerer sind als das Erreichen der Kollisionen selbst, und dass SHA-1 schwächer ist, als es sein sollte, und nicht vollständig gebrochen ist, was es wesentlich weit von a entfernt praktikabler Angriff zumindest heute. Darüber hinaus merkt er an, dass ein "erfolgreicher" Angriff sehr wenig bewirken würde, wenn das kollidierende Objekt später als das existierende eintrifft, da davon ausgegangen wird, dass das spätere Objekt dasselbe wie das gültige ist und ignoriert wird (obwohl andere darauf hingewiesen haben das Umgekehrte könnte passieren).
  3. Das Ändern von Software ist zeitaufwendig und fehleranfällig, insbesondere wenn vorhandene Infrastrukturen und Daten vorhanden sind, die auf den vorhandenen Protokollen basieren, die migriert werden müssen. Sogar diejenigen, die Software- und Hardwareprodukte herstellen, bei denen die kryptografische Sicherheit der einzige Punkt des Systems ist, migrieren immer noch von SHA-1 und anderen schwachen Algorithmen. Stellen Sie sich all diese hartcodierten unsigned char[20] puffert überall ;-), es ist viel einfacher, die kryptografische Agilität zu Beginn zu programmieren, als sie später nachzurüsten.
  4. Die Leistung von SHA-1 ist besser als bei den verschiedenen SHA-2-Hashes (wahrscheinlich nicht so sehr, dass es jetzt zum Deal Breaker wird, aber vielleicht vor 10 Jahren ein Knackpunkt war), und die Speichergröße von SHA-2 ist größer .

Einige Links:

Meine persönliche Meinung wäre, dass, während praktische Angriffe wahrscheinlich eine gewisse Zeit in Anspruch nehmen und selbst dann, wenn sie auftreten, die Leute wahrscheinlich anfänglich mit anderen Mitteln als dem Ändern des Hash-Algorithmus selbst Abhilfe schaffen, dass Sie sich irren sollten, wenn Sie sich um die Sicherheit kümmern Gehen Sie bei der Auswahl der Algorithmen vorsichtig vor und verbessern Sie Ihre Sicherheitsstärken ständig, da die Fähigkeiten von Angreifern nur in eine Richtung gehen. Es wäre daher unklug, Git als Vorbild zu nehmen, insbesondere als Ziel in Die Verwendung von SHA-1 soll keine kryptografische Sicherheit darstellen.

50
softwariness

Dies ist eine Diskussion über die Dringlichkeit einer Migration von SHA1 für Mercurial, sie gilt jedoch auch für Git: https://www.Mercurial-scm.org/wiki/mpm/SHA1

Kurz gesagt: Wenn Sie heute nicht besonders fleißig sind, haben Sie viel schlimmere Schwachstellen als sha1. Trotzdem hat Mercurial vor über 10 Jahren damit begonnen, sich auf die Abwanderung von sha1 vorzubereiten.

seit Jahren wird daran gearbeitet, die Datenstrukturen und Protokolle von Mercurial für die Nachfolger von SHA1 nachzurüsten. Mit der Einführung von RevlogNG wurde vor über 10 Jahren in Mercurial 0.9 Speicherplatz für größere Hashes in unserer Revlog-Struktur zugewiesen. Das kürzlich eingeführte Bundle2-Format unterstützt den Austausch verschiedener Hash-Typen über das Netzwerk. Die einzigen verbleibenden Teile sind die Wahl einer Ersatzfunktion und die Wahl einer Abwärtskompatibilitätsstrategie.

Wenn git nicht vor Mercurial von sha1 weg migriert, können Sie jederzeit eine weitere Sicherheitsstufe hinzufügen, indem Sie einen lokalen Mercurial-Spiegel mit hg-git beibehalten.

Es gibt jetzt einen Übergangsplan für einen stärkeren Hash, so dass es in Zukunft so aussieht, als würde er einen moderneren Hash als SHA-1 verwenden. Aus dem aktueller Übergangsplan :

Einige in Betracht gezogene Hashes sind SHA-256, SHA-512/256, SHA-256x16, K12 und BLAKE2bp-256

3
Paul Wagland