Git bør nok begynde at skifte til en mere sikker hashalgoritme end SHA-1. Så langt vil Linus Torvalds, skaberen af det udbredte versionsstyringsværktøj, gerne gå, men han maner alligevel til besindelse i en mail til Git-mailinglisten.
Google har i samarbejde med forskningsinstitutionen CWI i Holland demonstreret, at det er muligt at udføre et kollisionsangreb mod SHA-1-algoritmen. Det vil sige, at det er muligt at generere en tekst, der giver samme hashværdi, når den køres gennem SHA-1, som man får ud af en anden tekst.
Vel at mærke uden bare at prøve sig frem. Googles metode er 100.000 gange hurtigere end 'brute force', og krævede alligevel, hvad der svarer til 6.500 års beregninger, hvis man udført dem på én processorkerne.
»Jeg tvivler på, at himlen falder ned om ørerne på Git som versionsstyringsværktøj. Bør vi migrere til en anden hashalgoritme? Ja. Er det 'game over' for SHA-1, som folk siger? Formentligt ikke,« skriver Linus Torvalds.
Git benytter SHA-1 til at generere hashværdier for hver ændring, der laves i det, der ligger i et Git-repository. På den måde kan Git se, om to udgaver er ens, uden at skulle lave en sammenligning hver gang. Og i princippet kan hashværdien også bruges til at tjekke, at man har fat i den rigtige udgave.
Lettere med PDF
Med det menes også implicit, at man har fat i en udgave, som en ondsindet part ikke har ændret i. Googles metode kunne give anledning til, at man i et Git-repository med kode kunne ændre indholdet på en måde, hvorpå det både gjorde noget ondsindet og fik den samme hashværdi som den rigtige udgave.
Helt så let er det imidlertid ikke. Som Linus Torvalds påpeger, så har Google valgt at bruge dokumenter i PDF til demonstrationen, fordi PDF giver mulighed for at lave en fil med en fast dokumentheader samt noget indhold, der ikke bliver vist.
På den måde kan man lave mange forskellige mutationer af dokumentet, som for brugeren vil se normalt ud, men hvor der er ændret i skjult indhold for at få hashværdien til at blive noget bestemt.
Det er vanskeligere i Git, fordi Git også tager tekstens længde med i sin beregning. Man skal altså finde en kollision, hvor længden er den samme som før. Det var ikke nødvendigt i Googles PDF-forsøg, lyder forklaringen fra Linus Torvalds.
Kollisioner vil udløse fejl
Det var Linus Torvalds, som skabte Git, men Git vedligeholdes i dag af Junio Hamano, som i samme tråd på mailinglisten henviser til et indlæg fra 2005 af Linus Torvalds. I indlægget forklarer Linus Torvalds, at selvom et kollisionsangreb mod SHA-1 skulle være muligt, så vil det være vanskeligt at bruge mod Git.
Versionsstyring bruges typisk til at give flere mulighed for at arbejde på de samme dokumenter - for Gits vedkommende især kildekode. Det betyder, at der som regel vil være flere kopier af indholdet.
Selv hvis man får ændret i master-kopien, som alle sender deres ændringer til og henter andres ændringer fra, så vil der være flere 'uskadte' kopier, der ligger hos de enkelte udviklere.
Linus Torvalds argument lød den gang, at det ville være usandsynligt, at man kunne skabe en ondsindet kopi, som ikke også ville indeholde nogle ændringer i forhold til tidligere versioner, som simpelthen ikke ville give mening.
Når en udvikler forsøgte at flette sine ændringer, lavet på den 'gode' kopi, sammen med den onde, ville der altså opstå fejl, som ville blive bemærket. Og selv hvis der ikke opstod synlige fejl, så ville det være muligt at markere den pågældende ondsindede version som ugyldig, når det på et tidspunkt blev opdaget.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
