Um meine vorherige Antwort aus dem Jahr 2012 zu ergänzen , gibt es jetzt (Februar 2017, fünf Jahre später) ein Beispiel für eine tatsächliche SHA-1-Kollision mit shattered.io , bei der Sie zwei kollidierende PDF-Dateien erstellen können: das heißt, Sie erhalten eine SHA- 1 digitale Signatur in der ersten PDF-Datei, die auch als gültige Signatur in der zweiten PDF-Datei missbraucht werden kann.
Siehe auch " Seit Jahren vor der Tür des Todes ist die weit verbreitete SHA1-Funktion jetzt tot " und diese Abbildung .
Update 26. Februar: Linus hat die folgenden Punkte in einem Google+ Beitrag bestätigt :
(1) Zunächst einmal - der Himmel fällt nicht. Es gibt einen großen Unterschied zwischen der Verwendung eines kryptografischen Hashs für Dinge wie Sicherheitssignaturen und der Verwendung eines solchen zum Generieren einer "Inhaltskennung" für ein inhaltsadressierbares System wie git.
(2) Zweitens bedeutet die Art dieses speziellen SHA1-Angriffs, dass es eigentlich ziemlich einfach ist, ihn abzuwehren, und es wurden bereits zwei Sätze von Patches für diese Abschwächung veröffentlicht.
(3) Und schließlich gibt es tatsächlich einen recht einfachen Übergang zu einem anderen Hash, der die Welt nicht zerstören wird - oder sogar zu alten Git-Repositories.
Bezüglich dieses Übergangs siehe die Q1 2018 Git 2.16 , in dem eine Struktur hinzugefügt wird, die den Hash-Algorithmus darstellt. Die Umsetzung dieses Übergangs hat begonnen.
Ab Git 2.19 (Q3 2018) hat Git ausgewählt SHA-256 als NewHash ausgewählt und ist dabei, es in den Code zu integrieren (was bedeutet, dass SHA1 immer noch die Standardeinstellung ist (Q2 2019, Git 2.21), aber SHA2 wird der Nachfolger sein).
Ursprüngliche Antwort (25. Februar) Aber:
- Dies ermöglicht das Schmieden eines Blobs, jedoch würde sich die SHA-1 des Baums immer noch ändern, da die Größe des gefälschten Blobs möglicherweise nicht mit der ursprünglichen Größe übereinstimmt: siehe " Wie wird der Git-Hash berechnet? "; Ein Blob SHA1 wird basierend auf Inhalt und Größe berechnet .
Es gibt jedoch einige git-svnProbleme . Oder besser gesagt mit svn selbst als hier zu sehen .
- Wie ich in meiner ursprünglichen Antwort erwähnt habe , sind die Kosten eines solchen Versuchs derzeit noch unerschwinglich (6.500 CPU-Jahre und 100 GPU-Jahre). Siehe auch Valerie Anita Aurora in " Lebensdauern kryptografischer Hash-Funktionen ".
- Wie bereits erwähnt, geht es hier nicht um Sicherheit oder Vertrauen, sondern um Datenintegrität (Deduplizierung und Fehlererkennung), die von a leicht erkannt werden kann
git fsck, wie Linus Torvalds heute erwähnt. git fsckwürde vor einer Festschreibungsnachricht mit undurchsichtigen Daten warnen, die nach a ausgeblendet werden NUL(obwohl dies NULin einer betrügerischen Datei nicht immer vorhanden ist ).
Nicht jeder schaltet sich ein transfer.fsck, GitHub jedoch: Jeder Push wird abgebrochen, wenn ein fehlerhaftes Objekt oder ein defekter Link vorhanden ist. Obwohl ... es gibt eine Grund dies nicht standardmäßig aktiviert .
- Eine PDF-Datei kann beliebige Binärdaten enthalten, die Sie ändern können, um einen kollidierenden SHA-1 zu generieren, im Gegensatz zu gefälschtem Quellcode.
Das eigentliche Problem beim Erstellen von zwei Git-Repositorys mit demselben Head-Commit-Hash und unterschiedlichen Inhalten. Und selbst dann bleibt der Angriff verwickelt .
- Linus fügt hinzu :
Der springende Punkt eines SCM ist, dass es sich nicht um ein einmaliges Ereignis handelt, sondern um eine kontinuierliche Geschichte. Das bedeutet im Grunde auch, dass ein erfolgreicher Angriff über einen längeren Zeitraum funktionieren und nicht erkennbar sein muss.
Wenn Sie einen SCM einmal zum Narren halten, Ihren Code einfügen können und er nächste Woche erkannt wird, haben Sie eigentlich nichts Nützliches getan. Du hast dich nur verbrannt.
Joey Hess probiert diese PDFs in einem Git-Repo aus und fand :
Dazu gehören zwei Dateien mit demselben SHA und derselben Größe, die aufgrund der Art und Weise, wie git den Header dem Inhalt voranstellt, unterschiedliche Blobs erhalten.
joey@darkstar:~/tmp/supercollider>sha1sum bad.pdf good.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65 bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1 good.pdf
Das Anhängen identischer Daten an diese kollidierenden Dateien führt zwar zu anderen Kollisionen, das Voranstellen von Daten jedoch nicht.
Der Hauptangriffsvektor (Schmieden eines Commits) wäre also :
- Generieren Sie ein reguläres Festschreibungsobjekt.
- Verwenden Sie das gesamte Festschreibungsobjekt + NUL als ausgewähltes Präfix und
- Verwenden Sie den Kollisionsangriff mit identischem Präfix, um die kollidierenden guten / schlechten Objekte zu generieren.
- ... und das ist nutzlos, weil die guten und schlechten Commit-Objekte immer noch auf denselben Baum zeigen!
Außerdem können Sie bereits kryptoanalytische Kollisionsangriffe gegen SHA-1 erkennen, die in jeder Datei mit vorhanden sind cr-marcstevens/sha1collisiondetection
Das Hinzufügen einer ähnlichen Prüfung in Git selbst würde einige Berechnungskosten verursachen .
Beim Ändern des Hashs kommentiert Linux :
Die Größe des Hashs und die Wahl des Hash-Algorithmus sind unabhängige Aspekte.
Was würden Sie vermutlich tun , ist Umstellung auf einen 256-Bit - Hash, die Verwendung , die intern und in der nativen git Datenbank, und dann standardmäßig nur
zeigen , als die Hash - 40-Zeichen Hex - String ( eine Art, wie , wie wir abkürzen schon Dinge in viele Situationen).
Auf diese Weise sehen Tools um git die Änderung nicht einmal, es sei denn, sie werden in einem speziellen " --full-hash" Argument (oder " --abbrev=64" oder was auch immer übergeben - die Standardeinstellung ist, dass wir mit 40 abkürzen).
Ein Übergangsplan (von SHA1 zu einer anderen Hash-Funktion) wäre immer noch komplex , würde aber aktiv untersucht.
Eine convert-to-object_idKampagne ist im Gange :
Update 20. März: GitHub beschreibt einen möglichen Angriff und seinen Schutz :
SHA-1-Namen können über verschiedene Mechanismen als vertrauenswürdig eingestuft werden. Mit Git können Sie beispielsweise ein Commit oder Tag kryptografisch signieren. Dadurch wird nur das Commit- oder Tag-Objekt selbst signiert, das wiederum unter Verwendung ihrer SHA-1-Namen auf andere Objekte verweist, die die tatsächlichen Dateidaten enthalten. Eine Kollision in diesen Objekten könnte eine Signatur erzeugen, die gültig erscheint, aber auf andere Daten verweist als der beabsichtigte Unterzeichner. Bei einem solchen Angriff sieht der Unterzeichner nur die eine Hälfte der Kollision und das Opfer die andere Hälfte.
Schutz:
Der jüngste Angriff verwendet spezielle Techniken, um Schwachstellen im SHA-1-Algorithmus auszunutzen, die eine Kollision in viel kürzerer Zeit finden. Diese Techniken hinterlassen ein Muster in den Bytes, das erkannt werden kann, wenn der SHA-1 einer der Hälften eines kollidierenden Paares berechnet wird.
GitHub.com führt diese Erkennung jetzt für jeden berechneten SHA-1 durch und bricht die Operation ab, wenn Anzeichen dafür vorliegen, dass das Objekt die Hälfte eines kollidierenden Paares ist. Dies verhindert, dass Angreifer GitHub verwenden, um ein Projekt davon zu überzeugen, die "unschuldige" Hälfte ihrer Kollision zu akzeptieren, und verhindert, dass sie die böswillige Hälfte hosten.
Siehe " sha1collisiondetection" von Marc Stevens
Mit dem Hinzufügen einer Struktur, die den Hash-Algorithmus darstellt, im ersten Quartal 2018, Git 2.16 , wurde erneut die Implementierung eines Übergangs zu einem neuen Hash gestartet.
Wie oben erwähnt, wird der neue unterstützte Hash SHA-256 sein .