SHA-1 vs SHA-256: Kollisjon for Under $10.000 [2026]

Git forbereder SHA-256 som standard hash-format i Git 3.0. NIST har satt en hard sluttdato for SHA-1: 31. desember 2030. Og for rundt 90.000 kroner kan en angriper i dag beregne en SHA-1-kollisjon hjemmefra med to forbrukergrafikkort. Likevel ligger SHA-1 fortsatt begravet i eldre firmware, interne verktøy og enkelte forretningskritiske systemer over hele Norden. Spørsmålet er ikke lenger om SHA-1 er usikker – det er avgjort. Spørsmålet er hvor fort organisasjonen din faktisk migrerer bort, og hva SHA-256 koster i bytte mot ytelsen du mister.

Denne sammenligningen går gjennom ytelsestall fra tre uavhengige benchmarker, kostnaden ved å knekke SHA-1 i 2026-priser, hvor langt Git-migrasjonen faktisk har kommet, og en konkret migreringsplan du kan følge i egen infrastruktur. Alle tall er hentet fra 2025–2026-kilder og navngitte referanser – ingen gjetning. Vi ser også på hvor SHA-1 fortsatt lever i produksjonssystemer, hva de store standardorganene faktisk krever, og hvilke feil som oftest saboterer et migreringsprosjekt underveis.

SHA-1 og SHA-256 i korte trekk

SHA-1 ble publisert av NSA i 1995 og standardisert av NIST samme år. Algoritmen produserer et 160-bit avtrykk og var i to tiår selve ryggraden i HTTPS-sertifikater, Git-commits og digitale signaturer. SHA-256, en del av SHA-2-familien fra 2001, produserer et 256-bit avtrykk og er i dag den mest brukte kryptografiske hashfunksjonen på internett, ifølge Qualys SSL Labs sin overvåkning av 150.000 populære nettsteder.

Forskjellen handler ikke bare om lengre tall. SHA-1 er kryptografisk knekt: forskere har vist praktiske kollisjonsangrep siden 2017, og kostnaden for å gjenta dem faller år for år. SHA-256 har derimot ingen kjente praktiske kollisjoner, og de teoretiske grensene ligger langt utenfor rekkevidde for enhver realistisk angriper – statlig eller kriminell. Samtidig er SHA-1 fortsatt raskere i ren programvare uten maskinvareakselerasjon, noe som forklarer hvorfor algoritmen henger igjen i enkelte ytelseskritiske nisjer.

Kort sagt: SHA-1 vinner på råhastighet i eldre programvare. SHA-256 vinner på alt som faktisk teller – sikkerhet, standardsamsvar og fremtidssikring. Resten av artikkelen viser tallene bak den påstanden.

Slik fungerer algoritmene under panseret

Begge algoritmene bygger på samme grunnkonstruksjon, kalt Merkle-Damgård. Input deles opp i blokker på 512 bit, og hver blokk kjøres gjennom en komprimeringsfunksjon sammen med resultatet fra forrige blokk. Slik kjeder algoritmen sammen hele meldingen til ett endelig avtrykk, uansett hvor lang den opprinnelige teksten er. Forskjellen mellom SHA-1 og SHA-256 ligger i detaljene inni denne komprimeringsfunksjonen.

SHA-1 bruker fem 32-bit tilstandsregistre og kjører 80 runder med enkle bitoperasjoner (rotasjon, XOR, modulær addisjon) for hver blokk. SHA-256 bruker åtte 32-bit tilstandsregistre, kjører 64 runder, men hver runde er mer kompleks og blander inn flere av registrene samtidig. Det er nettopp denne ekstra kompleksiteten – flere registre og mer intrikat bitblanding – som gjør SHA-256 tregere å beregne, men også vanskeligere å angripe matematisk. Kryptografer kaller dette “diffusjon”: jo raskere endringer i input sprer seg til hele utdataet, desto vanskeligere blir det å konstruere kollisjoner med kontrollert struktur.

SHA-1s svakhet ligger ikke i selve konstruksjonen – Merkle-Damgård-modellen brukes fortsatt i SHA-256 uten problemer – men i at 80-rundersfunksjonen ikke sprer bit-endringer godt nok til å hindre matematisk smarte forkortelser. Wang, Yin og Yu viste allerede i 2005 at man kunne finne kollisjoner raskere enn brute force ved å utnytte akkurat denne svakheten, og de påfølgende 15 årene med forskning finpusset teknikken til noe som i dag er billig nok til å kjøre på vanlig forbrukermaskinvare.

Teknisk spesifikasjonstabell: SHA-1 vs SHA-256

Tabellen under samler de tekniske kjernetallene som avgjør sikkerhet og ytelse for begge algoritmene.

Egenskap	SHA-1	SHA-256
Avtrykkstørrelse	160 bit (20 byte)	256 bit (32 byte)
Kollisjonsresistens (teoretisk)	~80-bit	~128-bit
Kollisjonsresistens (praktisk, 2026)	Brutt – kollisjon for under $10.000	Ingen kjent praktisk angrep
Antall runder	80	64
Blokkstørrelse	512 bit	512 bit
Standardiseringsår	1995 (NIST FIPS 180-1)	2001 (NIST FIPS 180-2)
NIST-status (2026)	Forbudt for signaturer/sertifikater, utfases helt innen 31. des 2030	Godkjent, anbefalt minimum
Hastighet, Skylake (sykler/byte)	~3,5	~7,6
Gjennomstrømning, store blokker (Go-benchmark)	~1.123 MB/s	~623 MB/s
Maskinvareakselerasjon	Intel SHA Extensions (delvis)	Intel SHA Extensions, ARMv8 Crypto
Brukt i TLS-sertifikater fra offentlige CA-er	Nei, forbudt siden januar 2016	Ja, standard i dag
Git standard object-format	Ja (fortsatt, per august 2026)	Støttet siden Git 2.29, blir standard i Git 3.0

Legg merke til det ene tallet som overrasker mange utviklere: SHA-1 er faktisk raskere enn SHA-256 i ren programvare. Det er nettopp derfor algoritmen henger igjen enkelte steder – ikke fordi noen tror den er trygg, men fordi ingen har tatt seg tid til å bytte den ut.

Ytelsesbenchmark: hvor mye raskere er SHA-1 egentlig?

Tre uavhengige kilder gir et konsistent bilde: SHA-1 er mellom 1,5 og 2 ganger raskere enn SHA-256 uten maskinvareakselerasjon, men gapet krymper kraftig når CPU-en har innebygd SHA-støtte.

Keccak-teamets offisielle ytelsestabell for Intel-mikroarkitekturer viser følgende sykler-per-byte-tall for lange meldinger, målt uten SHA-utvidelser:

CPU-mikroarkitektur	SHA-1 (sykler/byte)	SHA-256 (sykler/byte)	SHA-1-fordel
Skylake-X	3,50	7,64	2,2x raskere
Skylake	3,48	7,59	2,2x raskere
Haswell	4,15	9,27	2,2x raskere
Sandy Bridge	4,92	11,45	2,3x raskere

Kilde: Keccak Team, offisielle programvarebenchmarker. Et 2025-benchmark i Go, publisert på Vitalvas-bloggen i oktober 2025, bekrefter mønsteret i praksis: på 128 kilobyte datablokker målte forfatteren 1.123,53 MB/s for SHA-1 mot 623,15 MB/s for SHA-256 – en fordel på cirka 1,8x for SHA-1. På små 128-byte-blokker snudde bildet seg noe, med SHA-1 på 420,77 MB/s mot SHA-256 på 310,17 MB/s.

Et tredje datapunkt, fra hashlib-biblioteket på GitHub, viser et enda større gap i en spesifikk implementasjon: SHA-1 målt til 1,16 Gbps mot SHA-256 sine 88,39 Mbps – over ti ganger raskere. Spennet mellom disse tre kildene (1,8x til over 10x) illustrerer et viktig poeng: den faktiske ytelsesforskjellen avhenger enormt av implementasjon, CPU-generasjon og om maskinvareakselerasjon er aktiv. Med Intel SHA Extensions eller ARMv8 Crypto-instruksjoner krymper gapet betydelig, og på moderne servere med maskinvarestøtte er forskjellen ofte under 20 prosent i praktiske arbeidsmengder.

Konklusjonen for de fleste team: ytelsesforskjellen er reell, men den er sjelden stor nok til å veie opp for sikkerhetsrisikoen. Et system som hasher noen tusen forespørsler i sekundet mister ikke merkbar ytelse ved å bytte til SHA-256 – forskjellen blir først synlig i ekstreme volummiljøer som blokkjede-mining eller storskala deduplisering.

På ARM-baserte servere og Apple Silicon-brikker endrer bildet seg ytterligere. ARMv8s Cryptography Extensions gir dedikerte instruksjoner for SHA-256, men ikke like moden akselerasjon for SHA-1 i alle implementasjoner, noe som i praksis kan snu ytelsesfordelen til SHA-256s favør på nyere ARM-maskinvare. Dette er stikk motsatt av situasjonen på eldre x86-servere uten SHA-utvidelser, og understreker at “SHA-1 er raskere” ikke er en universell sannhet – det er en betinget sannhet som avhenger av hvilken prosessorgenerasjon og instruksjonssett koden faktisk kjører på. Team som planlegger migrering bør måle på egen produksjonsmaskinvare fremfor å stole blindt på generiske benchmarktall, siden gapet kan variere fra nesten ingenting til over 2x avhengig av plattform.

Sikkerhetsstatus: hvorfor SHA-1 regnes som knekt

SHA-1s fall fra gratis til billig kollisjon er en av de best dokumenterte historiene i moderne kryptografi. I februar 2017 publiserte Google og forskningsinstituttet CWI Amsterdam SHAttered – det første praktiske kollisjonsangrepet, der to forskjellige PDF-filer fikk identisk SHA-1-avtrykk. Angrepet kostet den gang rundt 110.000 dollar i skyberegningskraft, ifølge tidlige offentlige estimater.

Prisen har stupt siden. Forskningsprosjektet SHA-1 is a Shambles viste i 2020 at et fullstendig “chosen-prefix”-kollisjonsangrep – den farligste varianten, som lar en angriper konstruere to filer med valgfritt innhold som deler samme hash – kunne gjennomføres for rundt 45.000 dollar i leid GPU-kraft, ned fra 75.000 dollar i det opprinnelige forsøket. Forskerne bak prosjektet spådde den gang at kostnaden ville falle under 10.000 dollar innen 2025.

Den spådommen har allerede slått til. En analyse publisert i januar 2025 på Drand-bloggen regnet på hva et “chosen-prefix”-angrep ville koste med to Nvidia RTX 5090-kort kjøpt til vanlig butikkpris (1.999 dollar per kort). Konklusjonen: rundt 413 dagers kontinuerlig kjøring, med en samlet kostnad inkludert strøm på under 10.000 dollar – fullt gjennomførbart for en hobbyist med tålmodighet, og trivielt for en velfinansiert angriper eller statlig aktør med tilgang til større GPU-klynger.

Til sammenligning: SHA-256s 128-bit kollisjonsresistens innebærer at et brute force-angrep krever i størrelsesorden 2^128 operasjoner. Det tallet er ikke bare stort – det er astronomisk utenfor rekkevidde for all beregningskraft som finnes på jorden i overskuelig fremtid, kvantedatamaskiner inkludert (Grovers algoritme halverer eksponenten, men lander fortsatt på et urealistisk høyt sikkerhetsnivå for hash-kollisjoner).

Det er også verdt å skille mellom de to typene angrep som ofte blandes sammen i denne diskusjonen. Et identisk-prefiks-angrep krever at angriperen kontrollerer begge dokumentene fra starten av, mens et chosen-prefix-angrep lar angriperen ta to helt forskjellige, allerede eksisterende dokumenter (for eksempel to ulike sertifikater eller kontrakter) og konstruere tillegg som gjør at de kolliderer. Det er sistnevnte variant – den langt farligere av de to, fordi den gir angriperen reell fleksibilitet til å forfalske noe som ser legitimt ut – som nå koster under 10.000 dollar. Denne distinksjonen er grunnen til at sikkerhetsmiljøet snakket om SHA-1 som “svekket” i årene 2005–2017, men “knekt” etter at chosen-prefix-varianten ble demonstrert praktisk gjennomførbar.

Milepæl	År	Detaljer
Teoretisk svakhet publisert	2005	Wang, Yin og Yu viser angrep raskere enn brute force
SHAttered-kollisjonen	2017	Google/CWI, to PDF-filer, ~$110.000 i skykostnad
SHA-1 is a Shambles	2020	Chosen-prefix-kollisjon for ~$45.000
RTX 5090-analyse	2025	Chosen-prefix-kollisjon estimert til under $10.000
NIST full utfasing	31. des. 2030	SHA-1 forbudt i alle applikasjoner med kryptografisk beskyttelse

Standardenes dom: NIST, CA/Browser Forum og PCI DSS

Ingen seriøs standardiseringsorganisasjon anbefaler lenger SHA-1 til nye systemer. NIST publiserte i desember 2022 en formell kunngjøring om at etatene skal fase ut SHA-1 for all kryptografisk beskyttelse innen 31. desember 2030, med klar anbefaling om å bytte nå heller enn å vente til fristen.

“We recommend that anyone relying on SHA-1 for security migrate to SHA-2 or SHA-3 as soon as possible.”
Chris Celi, NIST-forsker, i NISTs kunngjøring om pensjonering av SHA-1

NISTs offisielle policyside for hashfunksjoner er enda tydeligere i formuleringen:

“NIST recommends that federal agencies transition away from SHA-1 for all applications as soon as possible.”
NIST, NIST Policy on Hash Functions

Samme side spesifiserer også hva etatene skal bruke i stedet:

“Federal agencies should use SHA-2 or SHA-3 as an alternative to SHA-1.”
NIST, NIST Policy on Hash Functions

Og i selve overgangskunngjøringen fra 2022 gjentar NIST tidslinjen med presisjon:

“NIST will transition away from the use of SHA-1 for applying cryptographic protection to all applications by December 31, 2030.”
NIST, NIST Transitioning Away From SHA-1 for All Apps

Bransjen selv er enda mer utålmodig enn NIST. Åpen kildekode-prosjektet Sequoia-PGP oppsummerte situasjonen slik i et blogginnlegg om “SHA-1-dagen”:

“As of 2020, attacks against SHA-1 are as practical as against MD5; as such, it is recommended to remove SHA-1 from products as soon as possible and use instead SHA-256 or SHA-3.”
Sequoia-PGP-prosjektet, “Happy SHA-1 Day”

Bransjeorganet CA/Browser Forum handlet allerede i 2016: nye SHA-1-signerte TLS-sertifikater ble effektivt forbudt fra offentlige sertifikatutstedere fra januar det året. Chrome 56 og Firefox 51 sluttet å stole på SHA-1-sertifikater fra tidlig 2017, noe som i praksis avsluttet SHA-1s rolle i offentlig HTTPS-trafikk. PCI DSS 4.0 krever “sterk kryptografi” for betalingssystemer, en formulering bransjen tolker som et de facto-forbud mot SHA-1 i nye sertifikater og signaturer, selv om standarden ikke nevner algoritmen ved navn i hvert enkelt krav.

For norske og nordiske virksomheter kommer presset også fra en annen kant: NIS2-direktivet, som er innført i norsk rett gjennom digitalsikkerhetsloven, pålegger omfattede virksomheter å bruke “anerkjente” kryptografiske metoder og dokumentere risikovurderinger for kryptografivalg. En sikkerhetsrevisjon som avdekker aktiv bruk av SHA-1 til signaturer eller sertifikater vil typisk bli flagget som et avvik i en NIS2- eller ISO 27001-revisjon, uavhengig av om algoritmen faktisk har blitt utnyttet i praksis. Konsekvensen er at compliance-risikoen ofte materialiserer seg lenge før noen reell sikkerhetshendelse inntreffer – revisor bryr seg om hva standardene sier, ikke om angrepet faktisk har skjedd hos akkurat din organisasjon ennå.

Git og SHA-256: hvor langt har migrasjonen egentlig kommet?

Git er kanskje det tydeligste eksempelet på hvor tregt en dypt forankret SHA-1-avhengighet lar seg bytte ut, selv når hele bransjen er enig i at det haster. Støtte for SHA-256 som objektformat ble lagt til allerede i Git 2.29 (oktober 2020), og med Git 2.42.0-rc1 i juli 2023 sluttet prosjektet å kalle funksjonen “eksperimentell”.

Likevel er SHA-1 fortsatt standardvalget i alle Git-installasjoner per august 2026. Med Git 2.46 (tredje kvartal 2024) ble dokumentasjonen oppdatert for å bekrefte at Git 3.0 vil bruke SHA-256 som standard objektformat – men ingen har publisert en konkret utgivelsesdato for selve Git 3.0, og prosjektet understreker at SHA-1-støtten ikke fjernes, bare nedgraderes fra standard til alternativ.

Det virkelig store hinderet ligger ikke i Git-kjernen, men i økosystemet rundt. Verken GitHub eller GitLab tilbyr per tidlig 2026 SHA-256-repositorier som en standardfunksjon i brukergrensesnittet sitt. Community-tråder etterspør funksjonen, men ingen av de store vertsleverandørene har lansert en “bytt om”-knapp. Git-dokumentasjonens egen side om hash-overgangen er eksplisitt på dette punktet: en SHA-256-repo kan ikke snakke direkte med en SHA-1-repo uten spesiell konvertering, og verktøy som forventer 40-tegns SHA-1-hash for commits vil feile eller oppføre seg uforutsigbart mot en SHA-256-repo.

Praktisk konsekvens for norske og nordiske utviklingsteam: du kan eksperimentere med SHA-256-repositorier lokalt allerede i dag, men å sette det i produksjon mot GitHub eller GitLab er foreløpig ikke et reelt alternativ. Følg med på Git 3.0-utgivelsen, men ikke bygg migreringsplanen din rundt en dato ingen har bekreftet ennå.

Priser: hva koster det å bruke SHA-256 versus SHA-1?

Hverken SHA-1 eller SHA-256 koster noe i seg selv – begge er åpne, patentfrie algoritmer implementert i standardbiblioteker for praktisk talt alle programmeringsspråk. Den reelle kostnaden ligger i beregningsressursene algoritmene forbruker ved skalering, og i migreringsarbeidet ved bytte. Tabellen under viser omtrentlige skykostnader for å hashe store datamengder på vanlig virtuell maskinvare, basert på gjennomstrømningstallene fra benchmark-seksjonen over.

Ressurs / tjeneste	SHA-1	SHA-256	Merknad
Lisenskostnad	$0	$0	Begge er åpne NIST-standarder, ingen royalty
Relativ CPU-kostnad ved høyt volum (mrk. 1,8x gjennomstrømningsgap)	Basislinje	~40–80 % høyere CPU-tid per hash	Gjelder ren programvareimplementasjon uten SHA-NI
Kostnad for angriper å knekke (chosen-prefix-kollisjon, 2026)	< $10.000	Praktisk talt uendelig	Basert på RTX 5090-analysen fra januar 2025
Migreringskostnad (typisk mellomstort Git-repo)	N/A	Estimert 2–5 utviklerdager for verktøystøtte og re-signering	Avhenger av antall integrasjoner mot commit-hash-strenger
TLS-sertifikat med SHA-256-signatur	Ikke tilgjengelig (forbudt siden 2016)	Inkludert i standard CA-priser hos Let’s Encrypt (gratis) til DigiCert (fra ~$150/år)	Prisforskjellen skyldes CA-tillit, ikke algoritmevalg
Cloud HSM-timepris som støtter begge (AWS CloudHSM)	~$1,60/time	~$1,60/time	Ingen prisforskjell mellom algoritmer i samme HSM-instans

Det viktigste tallet i tabellen er ikke i kroner og øre – det er raden om angriperkostnad. Når det koster mindre å knekke en algoritme enn det koster å drifte den infrastrukturen den er ment å beskytte, er regnestykket allerede avgjort.

Hvor lever SHA-1 fortsatt i 2026?

Til tross for et tiår med advarsler dukker SHA-1 stadig opp i revisjoner og sikkerhetsgjennomganger. Fem konkrete eksempler illustrerer hvor algoritmen fortsatt gjemmer seg:

Eldre nettverksutstyr og ruterfastvare. Mange rutere og IoT-enheter fra før 2018 bruker fortsatt SHA-1 til firmwareverifisering fordi bootloaderen aldri ble oppdatert, og et bytte krever ny maskinvarerevisjon.
Git-repositorier i produksjon. Som beskrevet over er SHA-1 fortsatt standard objektformat i praktisk talt alle Git-installasjoner, inkludert GitHub og GitLab, per august 2026.
Interne lisens- og aktiveringssystemer. En del eldre programvarelisensiering og DRM-løsninger bruker SHA-1-baserte tokens fordi å endre formatet ville bryte bakoverkompatibilitet med utstedte lisensnøkler.
Eldre TLS-implementasjoner i lukkede industrielle systemer. SCADA- og OT-miljøer i energisektoren skifter ofte protokollstabel sjeldnere enn hvert tiår, og enkelte eldre PLS-er (programmerbare logiske styringer) kommuniserer fortsatt med SHA-1-baserte integritetssjekker.
Interne CI/CD-skript som antar 40-tegns commit-hash. Skript og integrasjoner bygget rundt Gits SHA-1-format bryter dersom repoet konverteres til SHA-256 uten at hele verktøykjeden oppdateres samtidig – en viktig grunn til at migrasjonen går tregt selv der viljen finnes.

Fellesnevneren er ikke uvitenhet – det er treghet i systemer der et bytte krever koordinert arbeid på tvers av mange avhengigheter, ikke bare én kodelinje.

Virkelige eksempler: SHA-1 i praksis i 2026

Teori og standarddokumenter forteller bare halve historien. Slik ser SHA-1-avhengigheten faktisk ut hos reelle plattformer og organisasjoner i dag:

Git-økosystemet (GitHub, GitLab, Bitbucket). Samtlige tre store hostingtjenester bruker fortsatt SHA-1 som standard objektformat for commits og tre-objekter per august 2026, selv om Git-kjernen selv har støttet SHA-256 siden versjon 2.29. Dette er trolig verdens mest brukte gjenværende SHA-1-installasjon målt i antall daglige operasjoner.
Android APK-signering (eldre pakker). Googles Android-plattform gikk over til å kreve SHA-256-baserte signaturskjemaer (APK Signature Scheme v2 og nyere) for nye apper for flere år siden, men eldre, allerede publiserte APK-er med SHA-1-baserte v1-signaturer fortsetter å installeres og kjøre på enheter som ikke har blitt tvunget til å oppgradere signaturkjeden.
Debian og andre Linux-distribusjoner. Pakkehåndteringssystemer har historisk brukt SHA-1 til å verifisere pakkeintegritet i tillegg til sterkere algoritmer. De fleste store distribusjoner har lagt til SHA-256-verifisering som primær mekanisme, men eldre repositorier og speil kan fortsatt eksponere SHA-1-sjekksummer for bakoverkompatibilitet med gamle klienter.
TLS-sertifikatkjeder i lukkede bedriftsnettverk. Mens offentlige CA-er forbød SHA-1 i 2016, opererer mange interne bedrifts-PKI-er (Public Key Infrastructure) fortsatt med selvsignerte rot- og mellomsertifikater signert med SHA-1, fordi ingen ekstern part håndhever forbudet innad i et lukket nettverk. Dette dukker jevnlig opp som funn i penetrasjonstester og sikkerhetsrevisjoner hos nordiske virksomheter.
Blokkjede- og kryptovalutaprosjekter fra før 2015. Enkelte eldre altcoin-prosjekter og Merkle-tre-implementasjoner bygget før SHA-1s svakheter ble allment kjent, bruker fortsatt algoritmen i sin konsensusmekanisme. Å bytte hashfunksjon i en levende blokkjede krever en hard fork, noe som gjør migrering betydelig mer politisk og teknisk komplisert enn i et vanlig softwareprosjekt.

Det gjennomgående mønsteret i alle fem eksemplene er det samme: SHA-1 forsvinner sjelden fordi noen aktivt forsvarer bruken av den. Den blir liggende fordi et bytte krever koordinert arbeid på tvers av flere parter samtidig – utviklere, plattformeiere og sluttbrukere – og ingen enkelt aktør har mandat eller insentiv til å tvinge frem overgangen alene.

Bruksområder: når passer hva

Selv om anbefalingen nesten alltid peker mot SHA-256 eller nyere, er det verdt å skille mellom situasjoner der valget er opplagt og situasjoner som krever en mer nyansert vurdering.

Bruk SHA-256 (eller nyere) når

Nye TLS-sertifikater og HTTPS-tjenester. Alle offentlige CA-er krever SHA-256 eller sterkere allerede – det finnes ikke noe reelt valg her.
Digitale signaturer og juridisk bindende dokumenter. Enhver bruk der en kollisjon kan brukes til svindel (kontrakter, sertifikater, kodesignering) krever kollisjonsresistens SHA-1 ikke lenger har.
Nye Git-repositorier uten eksterne integrasjoner. Interne, isolerte repoer uten avhengighet til GitHub/GitLab-hosting kan eksperimentere med SHA-256-objektformat allerede nå.
Passordhashing og autentiseringstokens. Bruk uansett aldri rå SHA-1 eller SHA-256 til passord – se egen anbefaling om Argon2 lenger ned.
Blokkjede- og smart-kontraktsystemer. Nye protokoller bør bruke SHA-256 eller nyere; det er allerede standarden i Bitcoin og de fleste moderne kjeder.

SHA-1 kan aksepteres midlertidig når

Ikke-sikkerhetskritisk integritetssjekk. Å oppdage tilfeldig datakorrupsjon (ikke ondsinnet manipulasjon) krever ikke kollisjonsresistens – her holder selv CRC32 i mange tilfeller.
Verifisering av eldre, allerede utstedte data. Å lese og validere historiske SHA-1-baserte poster (uten å utstede nye) utgjør lav risiko så lenge ingen nye signaturer genereres.
Eldre Git-historikk du ikke kan skrive om. Å konvertere års med commit-historikk har reell kostnad; mange team velger å la eldre historikk stå urørt mens nye commits flyttes til bedre praksis der det er mulig.

I alle tilfeller over gjelder ett prinsipp: SHA-1 skal aldri brukes til å generere nye sikkerhetskritiske signaturer eller sertifikater i 2026. Aksept av eksisterende SHA-1-bruk er noe annet enn å velge SHA-1 for et nytt system.

Migreringsguide: fra SHA-1 til SHA-256 i praksis

En strukturert migrering reduserer risikoen for at overgangen selv skaper nye sårbarheter. Erfaringen fra organisasjoner som allerede har gjennomført dette viser at rekkefølgen betyr mer enn hastigheten – å bytte det mest synlige først (som TLS-sertifikater) uten å kartlegge de skjulte avhengighetene (som interne API-signaturer) skaper ofte en falsk trygghetsfølelse der ledelsen tror jobben er ferdig lenge før den faktisk er det. Følg denne rekkefølgen:

Kartlegg alle steder SHA-1 brukes. Søk gjennom kodebasen etter sha1, SHA1 og biblioteksimporter som hashlib.sha1, crypto.createHash('sha1') eller tilsvarende. Ikke glem CI/CD-konfigurasjon, sertifikatlagre og tredjepartsavhengigheter.
Prioriter etter risiko, ikke etter enkelhet. Digitale signaturer og sertifikatutstedelse går først. Interne loggsjekksummer kan vente.
Bytt TLS-sertifikater til SHA-256-signatur. De fleste CA-er, inkludert Let’s Encrypt, utsteder kun SHA-256-signerte sertifikater i dag – sjekk at ingen eldre sertifikatkjeder fortsatt henger igjen med SHA-1 i mellomliggende sertifikater.
Oppdater kodesignering og pakkesignatursystemer. Verktøy som Authenticode, RPM-signering og APK-signering støtter SHA-256; sørg for at byggpipelinen faktisk bruker det som standard, ikke bare at det er mulig.
Test SHA-256 Git-objektformat isolert. Opprett et testrepo med git init --object-format=sha256 og verifiser at interne verktøykjeder (byggsystemer, linter, hook-skript) håndterer 64-tegns hash i stedet for 40-tegns før du vurderer produksjonsbruk.
Hold GitHub/GitLab-repoer på SHA-1 inntil videre. Siden ingen stor vertsleverandør støtter SHA-256-repoer i produksjon per august 2026, er full migrering av hostede repositorier ikke realistisk ennå – invester heller i å forberede interne verktøy.
Bytt passordhashing til Argon2 eller bcrypt, ikke SHA-256 alene. Rå SHA-256 er for rask til passordhashing og gjør brute force-angrep enklere; bruk en dedikert passord-hash-funksjon.
Verifiser med automatiserte skanninger. Kjør verktøy som gitleaks, trufflehog eller interne SAST-verktøy konfigurert til å flagge SHA-1-bruk i nye commits, slik at regresjon oppdages tidlig.
Dokumenter unntak eksplisitt. Der SHA-1 fortsatt må brukes midlertidig (se forrige seksjon), skriv ned hvorfor og sett en konkret revurderingsdato – ikke la unntaket bli permanent stille.
Sett en intern sluttdato godt før NISTs 2030-frist. Vent ikke til siste liten; bygg inn margin for uforutsette avhengigheter som dukker opp underveis.

Et konkret kodeeksempel på hvordan du sjekker hash-type i Node.js før migrering, for å unngå at gammel kode stille fortsetter å bruke SHA-1:

const crypto = require('crypto');

// Unngå dette i ny kode:
// const hash = crypto.createHash('sha1').update(data).digest('hex');

// Bruk i stedet:
function sikkerHash(data) {
  return crypto.createHash('sha256').update(data).digest('hex');
}

// Enkel lint-sjekk for å fange gjenværende sha1-kall i kodebasen
function advarOmSha1(kildekode) {
  if (/createHash\(['"]sha1['"]\)/.test(kildekode)) {
    console.warn('Advarsel: sha1 funnet, bytt til sha256 eller nyere.');
  }
}

Vanlige feil ved SHA-1-migrering

De fleste migreringsprosjekter feiler ikke fordi teamet ikke forstår hvorfor SHA-1 må bort, men fordi selve gjennomføringen støter på praktiske feller. Her er de vanligste:

Å anta at “vi bruker HTTPS” betyr at SHA-1 er borte. TLS-sertifikatet kan være SHA-256-signert mens applikasjonskoden bak fortsatt bruker crypto.createHash('sha1') til interne integritetssjekker, API-signaturer eller cache-nøkler. De to problemene må kartlegges og løses hver for seg.
Å blande sammen hashing og kryptering. SHA-1 og SHA-256 er hashfunksjoner, ikke krypteringsalgoritmer – de kan ikke “dekrypteres”. Forveksling av dette fører ofte til feil trusselmodellering, der team bekymrer seg for datakonfidensialitet når det egentlige problemet er integritet og forfalskning.
Å bytte til SHA-256 for passordhashing og tro jobben er gjort. Som nevnt tidligere er rå SHA-256 fortsatt for rask for passord. Mange migreringsprosjekter krysser av “SHA-1 fjernet” uten å innse at det nye valget (rå SHA-256 uten salt og strekking) også er utilstrekkelig mot moderne brute force-maskinvare.
Å glemme tredjepartsavhengigheter. Interne systemer kan være oppdatert, mens et gammelt SDK, en betalingsintegrasjon eller et overvåkningsverktøy fra en leverandør fortsatt genererer eller forventer SHA-1-baserte identifikatorer under panseret. Krev dokumentasjon fra leverandører om hvilken hashalgoritme de faktisk bruker.
Å konvertere Git-historikk uten å varsle hele teamet. Endring av objektformat eller omskriving av historikk med verktøy som git filter-repo endrer samtlige commit-hash i repoet. Uten koordinert varsling mister utviklere lokale grener, åpne pull requests kan bli foreldreløse, og CI/CD-systemer som cacher basert på commit-hash må tømmes.
Å behandle migrering som et engangsprosjekt. Uten en fortløpende skanning i CI-pipelinen sniker SHA-1 seg ofte tilbake gjennom kopiert kode, gamle eksempler fra dokumentasjon eller nye utviklere som ikke kjenner historikken. Bygg inn en automatisk sjekk, ikke bare en engangsopprydding.

Et realistisk migreringsprosjekt for en mellomstor organisasjon tar sjelden mer enn noen få uker ren arbeidstid – men det strekker seg ofte over flere måneder i kalendertid fordi det krever koordinering mellom sikkerhet, utvikling og drift. Planlegg deretter, og sett av tid til den koordineringen fremfor å undervurdere den tekniske jobben alene.

Fordeler og ulemper

En rask oppsummering av avveiningene mellom de to algoritmene, samlet fra tallene over.

SHA-1

Fordel: Opptil 2x raskere enn SHA-256 i ren programvare uten maskinvareakselerasjon
Fordel: Bredt støttet i eldre systemer og verktøy uten ekstra avhengigheter
Fordel: Fortsatt Gits standard objektformat, så ingen kompatibilitetsproblemer med eksisterende hosting
Ulempe: Kryptografisk knekt siden 2017, praktisk kollisjon for under $10.000 i 2026
Ulempe: Forbudt av alle store standarder for nye sertifikater og signaturer
Ulempe: NIST krever full utfasing innen 31. desember 2030
Ulempe: Skaper compliance-risiko i revisjoner mot PCI DSS, ISO 27001 og NIS2

SHA-256

Fordel: Ingen kjent praktisk kollisjon, 128-bit sikkerhetsmarginal
Fordel: Standard og påkrevd av alle offentlige CA-er, NIST og de fleste compliance-rammeverk
Fordel: Bred maskinvareakselerasjon (Intel SHA-NI, ARMv8 Crypto) lukker mye av ytelsesgapet
Fordel: Fremtidsrettet valg som ikke krever ny migrering med det første
Ulempe: 40–80 % lavere gjennomstrømning enn SHA-1 i ren programvare uten maskinvarestøtte
Ulempe: Ikke ennå standard objektformat i Git-hosting hos GitHub/GitLab
Ulempe: Migrering fra SHA-1-baserte systemer krever koordinert verktøyarbeid

Dommen: hvilken bør du velge?

Dataene peker i én retning. SHA-1s ytelsesfordel – reell, men i praksis 1,8 til 2,2 ganger på moderne CPU-er – veier ikke opp for at en angriper i 2026 kan konstruere en kollisjon for mindre enn kostnaden av en ny bærbar PC. SHA-256 er standarden alle offentlige CA-er, NIST og PCI DSS allerede krever, og maskinvareakselerasjon på moderne prosessorer lukker mesteparten av ytelsesgapet i praktiske arbeidsmengder.

Unntaket er smalt: rene integritetssjekker mot tilfeldig datakorrupsjon, ikke ondsinnet manipulasjon, kan fortsatt leve med SHA-1 en stund til – men selv der er kostnaden ved å bytte lav nok til at det sjelden er verdt risikoen å vente. Git-økosystemets trege SHA-256-migrasjon viser at selv når hele bransjen er enig i konklusjonen, tar det år å faktisk gjennomføre byttet i praksis. Ikke la din organisasjon være blant dem som fortsatt venter når NISTs 2030-frist nærmer seg.

Verdikt: SHA-256 er riktig valg for praktisk talt alle nye systemer i 2026. Behold SHA-1 kun der det er dokumentert lavrisiko og midlertidig, med en konkret dato for når det fjernes.

Dette er også et regnestykke som endrer seg med tiden, ikke et engangsvalg. Kostnaden ved å knekke SHA-1 har falt fra 110.000 dollar i 2017 til under 10.000 dollar i 2025, en nedgang på over 90 prosent på åtte år, drevet av billigere GPU-kraft og bedre angrepsalgoritmer. Det finnes ingen grunn til å tro at trenden snur. Motsatt har SHA-256 blitt raskere å kjøre i takt med at flere prosessorgenerasjoner har fått dedikert maskinvareakselerasjon, noe som gjør at “ytelsesstraffen” ved å velge riktig algoritme krymper for hvert år som går. Med andre ord: argumentene for å beholde SHA-1 blir svakere samtidig som argumentene for å bytte blir sterkere – en kombinasjon som sjelden gir grunn til å utsette beslutningen ytterligere.

Ofte stilte spørsmål

Er SHA-1 fortsatt trygt å bruke i 2026?

Nei, ikke til noe sikkerhetskritisk formål. SHA-1 er kryptografisk knekt siden SHAttered-angrepet i 2017, og en chosen-prefix-kollisjon koster i dag under 10.000 dollar å gjennomføre. Bruk SHA-256 eller nyere til alt som involverer signaturer, sertifikater eller integritetsbeskyttelse mot ondsinnede aktører.

Hvorfor bruker Git fortsatt SHA-1?

Git la til eksperimentell SHA-256-støtte i versjon 2.29 (2020) og fjernet eksperimentell-merkelappen i 2.42 (2023), men SHA-1 forblir standard fordi verken GitHub eller GitLab tilbyr SHA-256-repositorier i produksjon ennå. Git 3.0, som skal gjøre SHA-256 til standard, har ingen bekreftet utgivelsesdato per august 2026.

Hvor mye raskere er SHA-1 enn SHA-256 i praksis?

Mellom 1,8 og 2,2 ganger raskere i ren programvare uten maskinvareakselerasjon, ifølge Keccak-teamets offisielle benchmarker og et uavhengig Go-benchmark fra oktober 2025. Med moderne CPU-er som støtter SHA-utvidelser krymper forskjellen betydelig.

Hva er forskjellen mellom en kollisjon og et preimage-angrep?

En kollisjon betyr å finne to forskjellige input som gir samme hash-verdi – det er det SHA-1 er sårbart for. Et preimage-angrep betyr å finne et input som gir en spesifikk, forhåndsbestemt hash-verdi, noe som er langt vanskeligere og fortsatt ikke praktisk mulig mot verken SHA-1 eller SHA-256.

Bør jeg bruke SHA-256 til å hashe passord?

Nei. Verken SHA-1 eller rå SHA-256 er egnet til passordhashing fordi de er designet for å være raske – en egenskap som gjør brute force-angrep enklere for en angriper. Bruk en dedikert passord-hash-funksjon som Argon2 eller bcrypt, som bevisst er trege og minnekrevende.

Når fjerner NIST støtten for SHA-1 helt?

NIST har satt 31. desember 2030 som fristen for å fase ut SHA-1 fullstendig fra all kryptografisk beskyttelse i føderale systemer i USA. Bransjepraksis har allerede beveget seg raskere enn denne fristen på de fleste områder, spesielt for TLS-sertifikater og digitale signaturer.

Kan jeg konvertere et eksisterende Git-repo til SHA-256 i dag?

Teknisk sett ja, med Gits innebygde konverteringsverktøy, men det anbefales ikke for repoer hostet på GitHub eller GitLab siden disse plattformene ikke støtter SHA-256-objektformat i produksjon per august 2026. Konvertering fungerer best for isolerte, interne repositorier uten ekstern hosting-avhengighet.

Er SHA-3 et bedre valg enn både SHA-1 og SHA-256?

SHA-3 bruker en helt annen intern konstruksjon (Keccak-svampfunksjon) enn SHA-2-familien og gir god forsvarsdybde mot fremtidige angrep på SHA-2-strukturen, men er generelt tregere enn SHA-256 i ren programvare. For de fleste nye systemer i 2026 er SHA-256 fortsatt et fullgodt og bredere støttet valg; SHA-3 er mest aktuelt der man ønsker algoritmisk mangfold av strategiske grunner.

Truer kvantedatamaskiner SHA-256 på samme måte som SHA-1?

Ikke i overskuelig fremtid. Grovers algoritme, den mest relevante kvantealgoritmen mot hashfunksjoner, halverer effektivt sikkerhetsnivået – SHA-256s 128-bit kollisjonsresistens ville i teorien falle til rundt 64-bit mot en tilstrekkelig stor, feilkorrigert kvantedatamaskin. Det er fortsatt et sikkerhetsnivå som krever enorme ressurser å angripe, og ingen eksisterende kvantedatamaskin er i nærheten av den skalaen. SHA-1s problem er derimot klassiske, matematiske svakheter som lar seg utnytte på vanlige GPU-er i dag, helt uavhengig av kvanteteknologi.