Hashalgoritmer i forensic: MD5, SHA‑1 og SHA‑256

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Hashværdien er det tekniske fundament for at vise, at en forensisk kopi er uændret. MD5 og SHA-1 betragtes som brudte til kryptografiske formål, fordi man kan fremstille kollisioner. Men en kollision er noget andet end at forfalske data, så de matcher en eksisterende hashværdi. For integritetskontrol af sikrede data er risikoen derfor langt mindre, end overskrifterne antyder. Alligevel bør SHA-256 være standard ved nye sikringer, og hashværdien skal kunne følges fra sikring til fremlæggelse.

Grundbegrebet er forklaret på hubben i Hashværdier forklaret. Her går vi i dybden med algoritmernes egenskaber, hvad der hashes på hvert niveau, hvordan værdien bruges gennem sagens forløb, og hvad det betyder for en indvending. Artiklen er samtidig indgangen til de mere specialiserede artikler om hash, som der linkes til undervejs.

Hvad en hashfunktion skal kunne

En kryptografisk hashfunktion laver et fingeraftryk med fast længde af vilkårlige data. Den samme input giver altid samme output, og en lille ændring i input giver et helt andet output. Tre sikkerhedsegenskaber er vigtige:

Preimage-modstand · Betydning: Man kan ikke finde data ud fra en hashværdi · Relevans for sikrede data: Lav
Second preimage-modstand · Betydning: Givet bestemte data kan man ikke finde andre data med samme hashværdi · Relevans for sikrede data: Høj
Kollisionsmodstand · Betydning: Man kan ikke finde to vilkårlige datasæt med samme hashværdi · Relevans for sikrede data: Middel, afhængigt af situationen

Fast længde og lavineffekt

Uanset om input er en tekstfil på få byte eller en disk på flere terabyte, har resultatet samme længde. Det gør hashværdien praktisk at skrive i en log, en rapport eller et manifest. Lavineffekten betyder, at selv en ændring af en enkelt bit i input ændrer omkring halvdelen af bittene i output. Der findes derfor ingen “næsten ens” hashværdier, der antyder, at data er næsten ens. To værdier er enten identiske, eller også siger de intet om graden af forskel.

En hashværdi er heller ikke kryptering. Den kan ikke “dekrypteres” til de oprindelige data, og den skjuler ikke indholdet, hvis dataene i forvejen er kendte. Det er netop den egenskab, der udnyttes, når man sammenligner med lister over kendte filer.

Algoritmerne i forensisk praksis

MD5 · Længde: 128 bit (32 hex-tegn) · Status: Kollisioner kan fremstilles hurtigt på almindelig hardware. Intet praktisk second preimage-angreb kendt.
SHA-1 · Længde: 160 bit (40 hex-tegn) · Status: Første offentlige kollision i 2017. Chosen-prefix-kollisioner demonstreret i 2020. Intet praktisk second preimage-angreb kendt.
SHA-256 · Længde: 256 bit (64 hex-tegn) · Status: Ingen kendte kollisioner. Anbefalet standard.
SHA-512 · Længde: 512 bit (128 hex-tegn) · Status: Samme familie som SHA-256. Bruges sjældnere i forensiske værktøjer.
SHA3-256 · Længde: 256 bit (64 hex-tegn) · Status: Anden konstruktion end SHA-2. Endnu ikke udbredt i forensiske værktøjer.

MD5

Kollisionsangrebene mod MD5 blev offentliggjort i 2004 og er siden forbedret, så man i dag kan lave kollisioner med valgte præfikser, dvs. to dokumenter med forskelligt, meningsfuldt indhold og samme hashværdi. RFC 6151 beskriver, at kollisioner kan findes på en almindelig bærbar computer på meget kort tid, og fraråder MD5 til digitale signaturer. Samme RFC konstaterer, at det bedst kendte preimage-angreb stadig kræver en regnemængde i størrelsesordenen 2^123,4 operationer. Det ligger langt ud over det praktisk mulige.

MD5 er stadig udbredt i forensik, fordi mange ældre værktøjer, formater og referencesæt er bygget op om den. Den er hurtig, og den er velegnet til at opdage utilsigtede ændringer som læsefejl og beskadigede filer.

SHA-1

Den første offentlige SHA-1-kollision blev præsenteret i 2017 af forskere fra CWI Amsterdam og Google. Ifølge forskerne krævede den omkring ni trillioner (9 × 10^18) SHA-1-beregninger, altså en meget stor, men overkommelig regnemængde. I 2020 fulgte kollisioner med valgte præfikser, som gør angreb mod signaturer og certifikater mere anvendelige. NIST har meddelt, at SHA-1 skal udfases senest 31. december 2030 til fordel for SHA-2 og SHA-3. For integritetskontrol af en sikret kopi er der stadig intet kendt second preimage-angreb.

SHA-2-familien

SHA-256 tilhører SHA-2-familien, som er standardiseret i NIST FIPS 180-4 sammen med blandt andet SHA-384 og SHA-512. SHA-256 er i dag det naturlige valg: Den understøttes af alle udbredte styresystemer og forensiske værktøjer, og der er ingen kendte kollisioner. SHA-512 giver ikke en praktisk relevant ekstra sikkerhed for integritetskontrol af beviskopier, og den længere værdi er mere besværlig at gengive og sammenligne.

SHA-3

SHA-3 er standardiseret i NIST FIPS 202 fra 2015 og bygger på en helt anden konstruktion end SHA-2. Den er et godt supplement på længere sigt, men understøttelsen i forensiske værktøjer og indbyggede kommandoer er endnu begrænset. Vælges SHA-3, skal modparten kunne gentage beregningen med almindeligt tilgængelige værktøjer, ellers mister værdien noget af sin funktion.

Hvorfor en kollision ikke er en forfalsket kopi

Ved en kollision kontrollerer den, der fremstiller den, begge datasæt fra starten. Det kræver, at nogen før sikringen har fremstillet to versioner af en fil, der er konstrueret til at kollidere, typisk med særlige datablokke indlejret.

Når en IT-sagkyndig tager en kopi af en disk og beregner hashværdien, er dataene givet på forhånd. For at lave en anden disk med samme hashværdi kræves et second preimage-angreb. Det er ikke praktisk muligt for nogen af de tre klassiske algoritmer med den viden, der er offentligt kendt.

Hvor kollisioner faktisk betyder noget

Partens egne hashværdier: En part leverer selv filer, der er hashet af parten. Parten kunne i teorien have forberedt to versioner. Modtageren bør derfor selv beregne SHA-256 ved modtagelsen.
Kendte filer: Hashværdien bruges som identifikator i en database over kendte filer, hvor en konstrueret fil kan give et falsk match eller et falsk ikke-match. Se Hashlister og kendte filer.
Digitale signaturer: Signaturen er lavet over en MD5- eller SHA-1-hashværdi, og en konstrueret kollision kan i princippet flytte signaturen til et andet dokument. Se PDF-signaturer: teknisk validering.
Deduplikering: I store datasæt kan to konstruerede filer med samme MD5 blive behandlet som én. Det er sjældent relevant, men det er endnu en grund til at bruge SHA-256 som nøgle.

Hvad der hashes: fra disk til enkeltfil

Der er forskel på hashværdien af hele kopien og hashværdien af de enkelte filer. Mange misforståelser opstår, fordi det ikke fremgår, hvilket niveau en værdi hører til.

Fysisk medie · Hvad værdien dækker: Alle sektorer, også ufordelt plads · Typisk brug: Integritet af en fuld diskkopi
Partition eller volumen · Hvad værdien dækker: Ét logisk afsnit af disken · Typisk brug: Delvis sikring, krypterede volumener
Beholderfil (E01, AFF4, zip) · Hvad værdien dækker: Selve filen med komprimering og metadata · Typisk brug: Kontrol under overførsel og opbevaring
Enkeltfil · Hvad værdien dækker: Filens indhold, ikke navn eller tidsstempler · Typisk brug: Genkendelse af samme fil andre steder
Eksport eller udtræk · Hvad værdien dækker: Den konkrete pakke fra en telefon eller cloud · Typisk brug: Låser leverancen fra modtagelsen

Nogle konsekvenser:

Filnavn og tidsstempler indgår ikke i filens hashværdi, fordi de ligger i filsystemet og ikke i filens indhold. To filer med forskellige navne kan være identiske.
Ét ændret byte giver en helt anden hashværdi. Et Word-dokument, der er åbnet og gemt igen uden synlige ændringer, får typisk en ny værdi, fordi metadata og intern struktur ændres. At to filer har forskellig hashværdi, viser kun, at de ikke er bitidentiske.
Indhold i en beholder: Hashværdien af dataene i et image og hashværdien af selve E01-filerne er to forskellige ting. De vil aldrig være ens.
Telefoner og cloud: Et nyt udtræk fra samme telefon eller samme konto giver næsten altid en ny værdi, fordi kilden lever. Det forklares i Mobiludtræk og cloud-eksporter: hvorfor hashværdien ikke kan gentages.

E01-formatet gemmer traditionelt MD5 og eventuelt SHA-1 i selve filen. Vælges E01, bør SHA-256 beregnes særskilt, hvis værktøjet ikke selv gør det; se Forensiske diskformater.

Til at finde næsten ens filer bruges andre metoder, såkaldt fuzzy hashing som ssdeep eller TLSH. De giver et mål for lighed, ikke et bevis for identitet, og resultatet skal fortolkes med forsigtighed; se Fuzzy hashing. Ved mange filer samles værdierne i et manifest, så hver fil kan kontrolleres for sig: Hashmanifest for filsamlinger og produktioner.

Hashværdien gennem sagens forløb

En hashværdi har kun bevisværdi, hvis den kan følges fra sikringen til den kopi, der analyseres og fremlægges. Hvert led bør kunne vises i loggen.

Under sikringen: Værktøjet beregner hashværdien, mens data læses fra kilden. Ved fysiske medier kan kilden ofte også hashes separat via skrivebeskytter, så kilde og kopi kan sammenlignes direkte. Se Forensisk image trin for trin.
Verifikation: Den færdige kopi læses igen, og værdien beregnes på ny. Først når de to stemmer, er kopien verificeret.
Masterkopi og arbejdskopier: Hver ny generation hashes og sammenlignes med masterkopien, før der analyseres. Se Arbejdskopier og masterkopi.
Overførsel: Modtageren genberegner og kvitterer for, at værdien stemmer. Se Overførsel af beviskopier.
Opbevaring: Ved lang opbevaring kontrolleres værdien med jævne mellemrum, så forringede medier opdages i tide. Se Langtidsopbevaring af beviskopier.
Fremlæggelse: Den værdi, der står i rapporten, skal være den samme som i sikringsloggen.

Hvert trin registreres i chain of custody-loggen med tidspunkt, person, værktøj og resultat. En færdig skabelon findes i Skabelon: bevislog.

Beregning på de almindelige platforme

Alle udbredte styresystemer har indbyggede værktøjer til SHA-256. De er nyttige til kontrol, fordi en modpart kan gentage beregningen uden særlig software.

Windows · Indbygget værktøj: Get-FileHash i PowerShell · Bemærkning: Bruger SHA-256, hvis intet andet angives. Kan også MD5, SHA1, SHA384 og SHA512.
Windows · Indbygget værktøj: certutil -hashfile · Bemærkning: Ældre værktøj. Angiv altid algoritmen udtrykkeligt.
Linux · Indbygget værktøj: sha256sum · Bemærkning: Kan også kontrollere en liste med sha256sum -c.
macOS · Indbygget værktøj: shasum -a 256 · Bemærkning: Algoritmen vælges med -a.

Forensiske sikringsværktøjer beregner hashværdien undervejs, mens data læses. Notér altid, hvilket værktøj og hvilken version der er brugt, og om beregningen er foretaget på kopien, på originalen eller på en arbejdskopi. Kommandoerne og et eksempel på en hashlog er gennemgået i Hash af en fil: Get-FileHash, certutil og sha256sum.

Kontrol med to uafhængige værktøjer

Når en værdi er afgørende, kan den beregnes med to værktøjer fra forskellige leverandører eller med et forensisk værktøj og en indbygget kommando. Stemmer de, er risikoen for en værktøjsfejl lille, og kontrollen er let at gentage for andre. Det hænger sammen med den bredere disciplin i Verifikation af forensiske værktøjer.

Anbefalet praksis

Brug SHA-256 som primær algoritme ved nye sikringer.
Beregn gerne to algoritmer samtidig, fx MD5 og SHA-256. MD5 bevarer sammenlignelighed med ældre værktøjer og tidligere sikringer, og når SHA-256 indgår, er en samtidig kollision i begge algoritmer ikke en realistisk indvending.
Beregn hashværdien under sikringen, ikke kun bagefter, og verificér kopien ved at genberegne fra den færdige fil.
Dokumentér algoritme, værktøj, version og tidspunkt for hver hashberegning.
Genberegn ved hver overdragelse, så kæden af ansvar kan vises fra sikring til fremlæggelse.
Hash eksporter med det samme, når de modtages fra en cloudtjeneste eller et udtræksværktøj, før de pakkes ud eller behandles.
Gem hashloggen adskilt fra kopien, så en fejl på lagermediet ikke rammer begge.

Typiske fejlkilder

Forkert genstand: Hashværdien af en E01-segmentfil sammenlignes med hashværdien af de indeholdte data. De vil aldrig passe.
Forkortede værdier: Kun de første tegn gengives, så værdien ikke kan efterprøves.
Manglende algoritme: En værdi uden angivet algoritme er tvetydig, selvom længden giver et hint.
Tekstkodning: Hashværdier af tekst afhænger af tegnsæt og linjeskift. Hash altid de oprindelige filer, ikke en kopieret tekst.
Store og små bogstaver: Get-FileHash viser hex-tegn med store bogstaver, mens sha256sum bruger små. Værdierne er de samme, men en tegn for tegn-sammenligning i et regneark kan fejlagtigt melde forskel.
Kopiering fra PDF: Værdier kopieret fra en rapport kan få mellemrum, linjeskift eller ombrudte tegn med. Sammenlign maskinelt, ikke med øjet.
Levende kilde: En monteret disk eller en kørende server ændrer sig under læsningen, så en senere hash af kilden ikke stemmer. Det er forventeligt og skal forklares, ikke skjules.
Læsefejl: Defekte sektorer kan give forskellige værdier ved hver læsning. Værktøjets fejllog skal gemmes sammen med kopien.

Når værdierne ikke stemmer, gennemgås årsagerne systematisk i Når hashværdien ikke stemmer: årsager og håndtering.

Eksempler på brug

Diskkopi af en bærbar computer. Disken sikres via skrivebeskytter til et E01-image. Værktøjet beregner MD5 og SHA-256 under læsningen, og den færdige kopi verificeres. Værdierne skrives i loggen sammen med diskens serienummer. Når arbejdskopien senere oprettes, genberegnes SHA-256, og resultatet noteres som en ny hændelse.

Filsamling til modparten. Udvalgte dokumenter fra en filserver produceres som enkeltfiler. Der dannes et manifest med SHA-256 for hver fil, og manifestet selv hashes. Modtageren kan kontrollere hver fil og manifestet uden særlig software.

Filer leveret af en part. En part leverer en zip-fil med en hashværdi, som parten selv har beregnet. Modtageren beregner SHA-256 af zip-filen ved modtagelsen og noterer, at den oprindelige værdi stammer fra parten. Det dokumenterer tilstanden fra modtagelsen, men ikke, hvad der skete før.

Når indvendingen kommer

En modpart kan anføre, at MD5 er brudt, og at kopien derfor ikke kan bruges. Svaret er sagligt og teknisk: Indvendingen forudsætter, at nogen før sikringen har konstrueret to versioner af hele mediet, og det er ikke en realistisk situation for en disk, der er sikret af en uafhængig part. Er SHA-256 beregnet samtidig, falder indvendingen helt bort.

Er der kun beregnet MD5 i en ældre sikring, kan kopien stadig hashes med SHA-256 i dag. Det dokumenterer ikke tilstanden på sikringstidspunktet, men det låser kopien fra nu af og gør senere sammenligning stærkere. Skriv i rapporten, hvornår hver værdi er beregnet.

For ikke-teknikere hjælper det at skelne mellem at finde to nye filer med samme hashværdi og at lave en fil, der matcher en bestemt, allerede kendt værdi. Gode formuleringer findes i Teknisk forklaring i retten, og de spørgsmål, der typisk stilles til metoden, er samlet i Typiske tekniske spørgsmål til metoden.

Tjekliste

☐ SHA-256 er beregnet under sikringen, eventuelt sammen med MD5.
☐ Kopien er verificeret ved genberegning fra den færdige fil.
☐ Det fremgår, hvad der er hashet: medie, partition, beholderfil, enkeltfil eller eksport.
☐ Algoritme, værktøj, version og tidspunkt er noteret for hver beregning.
☐ Hashværdien er skrevet fuldt ud i log og rapport.
☐ Arbejdskopier er kontrolleret mod masterkopien før analyse.
☐ Hver overdragelse har en genberegnet og kvitteret værdi.
☐ Afvigelser og læsefejl er registreret og forklaret.

Hvad hashværdien kan og ikke kan bevise

En uændret hashværdi viser, at data er identiske med det, der blev hashet. Den viser ikke, at det var de rigtige data, der blev sikret, at sikringen var fuldstændig, eller hvad dataene betyder. Det skal dokumenteres med sikringslog, serienumre og kæden af ansvar. En hashværdi af en eksport siger heller intet om, hvad der lå i kilden før eksporten; den dækker kun den pakke, der faktisk blev modtaget.

I rapporten

Skriv hashværdien fuldt ud, angiv algoritmen, og beskriv præcist, hvad der er hashet: hele mediet, en partition, en beholderfil eller en enkelt fil. Angiv, hvornår værdien er beregnet og med hvilket værktøj, og skeln mellem værdier beregnet af den sagkyndige og værdier leveret af andre. Se også Rapportskrivning.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Hash af en fil: Get-FileHash, certutil og sha256sum · Tidslinjeanalyse: metode, kilder og faldgruber

→ Forensisk sikring · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Eller kontakt os på