Norske utviklere som velger hashfunksjon i 2026 står ofte fast på samme spørsmål: skal man kjøre videre med SHA-256, den utskjelte men lynraske veteranen, eller bytte til SHA-3, NIST-standarden som skulle bli SHA-2s etterfølger men aldri helt tok av? Svaret er ikke opplagt. SHA-256 vinner de fleste hastighetstester med klar margin, mens SHA-3 bygger på en helt annen konstruksjon som løser problemer SHA-256 aldri har hatt. Denne artikkelen går gjennom begge algoritmene i detalj, med ferske benchmarker, arkitekturforskjeller og konkrete anbefalinger for når du bør velge hvilken.
Kort oppsummert: SHA-256 er 3-4 ganger raskere på moderne prosessorer takket være dedikert maskinvarestøtte, mens SHA-3 tilbyr en svampkonstruksjon (sponge) som er strukturelt mer fleksibel og ikke arver SHA-256s teoretiske svakhet mot lengdeutvidelsesangrep. Begge er godkjent av NIST, begge regnes som sikre i 2026, og valget kommer i praksis ned til bruksområde, ikke frykt.
Hva er SHA-256 og hvorfor dominerer den fortsatt
SHA-256 tilhører SHA-2-familien og er spesifisert i NIST FIPS 180-4, «Secure Hash Standard». Algoritmen bruker en Merkle-Damgård-konstruksjon: meldingen deles opp i 512-bits blokker, og hver blokk mates gjennom en komprimeringsfunksjon som oppdaterer en 256-bits intern tilstand. Etter 64 runder med bitvise operasjoner sitter man igjen med et 256-bits avtrykk. Denne konstruksjonen har vært kjernen i internettets sikkerhet siden midten av 2000-tallet, og den brukes fortsatt i nesten alt fra TLS-sertifikater til Bitcoin-mining.
Grunnen til at SHA-256 fortsatt vinner ytelsestester, er ikke at algoritmen i seg selv er raskere på papiret. Det er maskinvaren. Intel introduserte SHA Extensions i 2013, syv dedikerte SSE-baserte instruksjoner der tre er spesialbygget for SHA-256 (SHA256RNDS2, SHA256MSG1, SHA256MSG2). ARMv8-arkitekturen fikk tilsvarende støtte gjennom FEAT_SHA256, med instruksjoner som SHA256H og SHA256SU0. Disse instruksjonene lar prosessoren gjøre rundeberegninger i maskinvare i stedet for programvare, og resultatet er brutalt effektivt: moderne x86-64-prosessorer med SHA-NI når typisk 2-4 sykluser per byte.
Bitcoin er det mest kjente eksempelet på hvor sentral SHA-256 fortsatt er. Nettverket bruker dobbel SHA-256 (SHA-256(SHA-256(data))) i sin proof-of-work-mekanisme, der minere hasher 80-byte blokkhoder om og om igjen for å finne en verdi under et vanskelighetsmål. Transaksjons-ID-er og Merkle-trærne i Bitcoin bygger også på SHA-256, og det samme gjelder avledede kjeder som Bitcoin Cash. Utover kryptovaluta er SHA-256 fortsatt standardvalget for TLS-sertifikatkjeder, kodesignering og HMAC i de aller fleste produksjonssystemer.
Hva er SHA-3 og hvorfor NIST valgte en helt ny konstruksjon
SHA-3 er spesifisert i NIST FIPS 202, publisert 4. august 2015, og bygger på Keccak-algoritmen som vant NISTs hashfunksjonskonkurranse i 2012. Bakgrunnen var strategisk snarere enn akutt: etter at MD5 og SHA-1 falt for kollisjonsangrep, ønsket NIST en reserve-algoritme med en helt annen matematisk konstruksjon enn SHA-2, slik at et fremtidig strukturelt gjennombrudd mot Merkle-Damgård ikke ville true begge standardene samtidig.
SHA-3 bruker det som kalles en svampkonstruksjon (sponge construction). Den interne tilstanden er 1600 bit, organisert som en 5×5×64-bits matrise, og deles i to soner: en «rate» og en «capacity». Meldingsdata XOR-es inn i rate-delen, og en Keccak-f-permutasjon med 24 runder blandes inn mellom hver blokk. For SHA3-256 er rate satt til 1088 bit og capacity til 512 bit, noe som gir 128-bits kollisjonssikkerhet og 256-bits preimage-sikkerhet. Til slutt «klemmes» bitene ut av rate-delen for å produsere selve avtrykket.
FIPS 202 definerer fire faste hashfunksjoner (SHA3-224, SHA3-256, SHA3-384, SHA3-512) og to variable-lengde-funksjoner kalt XOF-er (extendable-output functions): SHAKE128 og SHAKE256. SHAKE-variantene lar deg generere et avtrykk av vilkårlig lengde, noe som er nyttig i nøkkelavledning og enkelte signaturskjemaer. Ethereum er det mest kjente eksempelet på utbredt bruk av Keccak-familien: Ethereum Yellow Paper spesifiserer Keccak-256 (en variant fra før NIST-standardiseringen, ikke identisk med SHA3-256) som hashfunksjon for tilstands- og transaksjons-Merkle-trær i EVM.
Ytelsesbenchmarker: hvor stor er hastighetsforskjellen egentlig
Tallene her varierer med prosessor, kompilator og inputstørrelse, men mønsteret er konsekvent på tvers av alle uavhengige kilder: SHA-256 er 3-4 ganger raskere enn SHA3-256 på moderne CPU-er, hovedsakelig fordi SHA-256 har dedikert maskinvarestøtte som SHA-3 mangler.
En 2025-analyse fra sikkerhetsforsker Sylvain Kerkour, kjørt på en AMD EPYC 4245P (Zen 5), viser SHA-256 på cirka 822 MB/s mot SHA3-256s 246 MB/s for 64-byte input, en forskjell på rundt 3,3x. Gapet holder seg gjennom hele skalaen: ved 1 KB input når SHA-256 rundt 2123 MB/s mot SHA3-256s 620 MB/s, og ved 1 MB flater begge ut på henholdsvis rundt 2373 MB/s og 686 MB/s, altså en forskjell på 3,4-3,5x.
Et uavhengig 2026-benchmark på AMD EPYC 9R14 og AWS Graviton 4 finner samme mønster. På EPYC 9R14 måler SHA-256 860 MB/s ved 64 byte, 1719 MB/s ved 1 KB og 1772 MB/s ved 10 MB, mens SHA3-256 kun når rundt 459 MB/s ved 1 KB og 509 MB/s ved 10 MB, en forskjell på cirka 3,7x. På AWS Graviton 4 (ARM) er bildet identisk: SHA-256 leverer 1716-1744 MB/s mot SHA3-256s 455-510 MB/s.
Tredje kilde er Wikipedias SHA-3-ytelsestabell, som bygger på OpenSSL AVX-implementasjoner fra eBACS/SUPERCOP-prosjektet. Den viser at SHA3-256 kan nå omtrent 6,4 sykluser per byte med AVX-512VL og 7,8 sykluser per byte med AVX2 på en Skylake-prosessor. Til sammenligning ligger SHA-256 med dedikert SHA-NI-maskinvare på 2-4 sykluser per byte, mens SHA-256 uten SHA-NI (kun AVX2) også havner rundt 7-8 sykluser per byte, altså omtrent likt med SHA-3 når ingen av dem har maskinvareakselerasjon.
Det siste poenget er viktig og blir ofte oversett: forskjellen skyldes primært at SHA-256 har dedikerte prosessorinstruksjoner (SHA-NI på Intel/AMD, FEAT_SHA256 på ARM), mens det per 2025-2026 ikke finnes tilsvarende utbredte CPU-instruksjoner for Keccak/SHA-3. SHA-3 må klare seg med generisk SIMD (AVX2/AVX-512), og det er derfor programvareimplementasjoner av SHA-3 fortsatt taper mot maskinvareakselerert SHA-256 på nesten alle vanlige servere og bærbare PC-er.
| Inputstørrelse | SHA-256 (MB/s) | SHA3-256 (MB/s) | Forskjell | Kilde |
|---|---|---|---|---|
| 64 byte (Zen 5, EPYC 4245P) | 822 | 246 | 3,3x | Kerkour 2025 |
| 1 KB (Zen 5, EPYC 4245P) | 2 123 | 620 | 3,4x | Kerkour 2025 |
| 1 MB (Zen 5, EPYC 4245P) | 2 373 | 686 | 3,5x | Kerkour 2025 |
| 64 byte (AMD EPYC 9R14) | 860 | n/a | – | 2026-benchmark |
| 1 KB (AMD EPYC 9R14) | 1 719 | 459 | 3,7x | 2026-benchmark |
| 10 MB (AMD EPYC 9R14) | 1 772 | 509 | 3,5x | 2026-benchmark |
| 1 KB (AWS Graviton 4, ARM) | 1 716 | 455 | 3,8x | 2026-benchmark |
| 10 MB (AWS Graviton 4, ARM) | 1 744 | 510 | 3,4x | 2026-benchmark |
Verdt å nevne: OpenSSL-teamet fortsetter å optimalisere begge algoritmene. En sammenligning mellom OpenSSL 3.0.2 og OpenSSL 3.3 viser at SHA-256-gjennomstrømning økte fra rundt 15 000 til 16 500 MB/s (en forbedring på 10 %) på testplattformen, mens SHA3-512 gikk fra rundt 6500 til 7300 MB/s (12,3 % forbedring). Poenget er at optimaliseringsarbeidet ikke lukker gapet, det holder tritt på begge sider.
Arkitekturforskjeller: Merkle-Damgård mot svampkonstruksjon
Den viktigste forskjellen mellom SHA-256 og SHA-3 er ikke hastighet, det er hvordan de er bygget opp innvendig. SHA-256 følger Merkle-Damgård-paradigmet: en fast intern tilstand oppdateres blokk for blokk, og selve tilstanden ved slutten av prosessen er avtrykket. Dette er en velprøvd og godt forstått konstruksjon, men den har en kjent strukturell egenskap: gitt H(M) kan en angriper som kjenner lengden på M, i mange tilfeller regne ut H(M || padding || ekstra) uten å kjenne selve M. Dette kalles et lengdeutvidelsesangrep (length-extension attack).
I praksis er dette sjelden et problem fordi standardpraksisen er å bruke HMAC eller riktig domeneseparasjon rundt hashfunksjonen, noe NISTs SP 800-107 Revisjon 1 eksplisitt anbefaler. Men det er en ekstra ting utviklere må huske på og som har skapt reelle sårbarheter i naive implementasjoner, blant annet i eldre API-signeringsordninger som brukte rå SHA-256(hemmelig_nøkkel || melding) uten HMAC.
SHA-3s svampkonstruksjon unngår denne svakheten helt. Fordi output hentes fra rate-delen av en tilstand som fortsatt har en skjult capacity-del, kan man ikke gjøre samme type utvidelse uten å kjenne hele den interne tilstanden. Konstruksjonen støtter også innebygd domeneseparasjon gjennom ulike paddingsuffikser, «01» for SHA3-varianter og «1111» for SHAKE, noe som gjør det strukturelt enklere å bygge sikre protokoller oppå algoritmen uten ekstra HMAC-lag.
Spesifikasjonstabell: SHA-256 mot SHA-3-familien
| Egenskap | SHA-256 | SHA3-256 |
|---|---|---|
| NIST-standard | FIPS 180-4 | FIPS 202 |
| Publisert | 2015 (revisjon av opprinnelig 2002) | 4. august 2015 |
| Konstruksjon | Merkle-Damgård | Sponge (svamp) |
| Intern tilstand | 256 bit | 1600 bit |
| Blokkstørrelse / rate | 512 bit | 1088 bit |
| Antall runder | 64 | 24 |
| Output-størrelse | 256 bit (fast) | 256 bit (fast), variabel med SHAKE |
| Kollisjonssikkerhet | 128 bit | 128 bit |
| Lengdeutvidelsesangrep | Sårbar uten HMAC | Ikke sårbar på samme måte |
| Maskinvareakselerasjon | Intel SHA-NI, ARM FEAT_SHA256 | Ingen dedikert, kun generisk SIMD |
| Typisk hastighet (server-CPU) | 1700-2400 MB/s | 450-700 MB/s |
| Sykluser per byte (uten SHA-NI) | 7-12 cpb | 6,4-8,6 cpb |
| Hovedbruk i praksis | TLS, Bitcoin, HMAC, kodesignering | Ethereum (Keccak-variant), enkelte PQC-byggeklosser |
Sikkerhetsnivå og motstand mot angrep
Begge algoritmene regnes som fullt sikre i 2026, og NIST har eksplisitt godkjent begge til bruk i føderale amerikanske systemer gjennom en oppdatert anvendelsesklausul: hashfunksjoner fra enten FIPS 180-4 (SHA-2) eller FIPS 202 (SHA-3) kan brukes når en sikker hashfunksjon kreves for beskyttelse av sensitiv, ugradert informasjon. Ingen praktisk kollisjons- eller preimage-svakhet er kjent mot verken SHA-256 eller SHA3-256 per august 2026.
Forskjellen ligger i risikoprofilen, ikke i dagens sikkerhet. SHA-256 og SHA-3 deler ingen matematisk struktur, så et fremtidig kryptoanalytisk gjennombrudd mot den ene ville trolig ikke true den andre samtidig. Dette var eksplisitt en del av NISTs begrunnelse for å standardisere en helt ny konstruksjon etter at både MD5 og SHA-1 falt. NISTs SP 800-107 Revisjon 1 gir konkrete retningslinjer for sikkerhetsstyrke og bruksområder for begge familiene, inkludert digitale signaturer, HMAC og nøkkelavledningsfunksjoner (KDF-er).
Historien til SHA-1 er et nyttig sammenligningspunkt. Google og CWI Amsterdam demonstrerte en praktisk kollisjon mot SHA-1 i februar 2017 gjennom det såkalte SHAttered-angrepet, noe som endelig fikk bransjen til å fase ut algoritmen fra sertifikater og Git-signaturer. SHA-256 har vist ingen tilsvarende strukturell svakhet i de 20-25 årene den har vært i bred bruk, og det samme gjelder SHA-3 siden standardiseringen i 2015. Begge algoritmene har vært utsatt for omfattende kryptoanalyse fra akademiske miljøer verden over uten at noen har funnet en praktisk vei til kollisjon, noe som er den beste tilliten en hashfunksjon kan opparbeide seg over tid.
Kvanteresistens: hva skjer med SHA-256 og SHA-3 når kvantedatamaskiner modnes
En vanlig misforståelse er at post-kvante kryptografi bare handler om RSA og elliptisk kurve-kryptografi. Hashfunksjoner er også påvirket, men på en helt annen måte. Shors algoritme, som knekker RSA og ECC effektivt på en tilstrekkelig stor kvantedatamaskin, har ingen tilsvarende effekt på SHA-256 eller SHA-3. Det som derimot påvirker begge, er Grovers algoritme, som i teorien halverer den effektive sikkerhetsstyrken til en hashfunksjon ved brute force-søk (preimage-angrep).
Konkret betyr det at SHA-256, som har 256-bits preimage-sikkerhet klassisk, faller til rundt 128-bits sikkerhet mot en kvanteangriper med Grovers algoritme. Det samme gjelder SHA3-256. Siden 128-bit fortsatt regnes som tilstrekkelig sikkerhetsnivå for de fleste formål, betyr det at ingen av algoritmene trenger å byttes ut på grunn av kvantetrusselen alene, i motsetning til RSA og ECC som er fullstendig knekt av Shors algoritme og må erstattes med ML-KEM og ML-DSA. Dette er en viktig nyanse: hash-svekkelse fra Grover er gradvis og forutsigbar, mens Shors angrep på asymmetrisk kryptografi er kategorisk. NIST har derfor ikke satt noen migreringsfrist for SHA-256 eller SHA-3 knyttet til kvantedatamaskiner, i motsetning til den eksplisitte 2025-fristen CNSA 2.0 satte for ML-KEM i TLS-nøkkelutveksling.
For virksomheter som allerede planlegger en bredere overgang til kvantesikker kryptografi, som beskrevet i vår gjennomgang av ML-KEM mot RSA, er det verdt å merke seg at valget mellom SHA-256 og SHA-3 kan gjøres uavhengig av den kvanteforberedende arkitekturen. Begge hashfunksjonene kan fritt kombineres med enten klassiske eller post-kvante signatur- og nøkkelutvekslingsalgoritmer.
Passordhashing: hvorfor verken SHA-256 eller SHA-3 er riktig verktøy
Et vanlig og farlig feilgrep er å bruke SHA-256 eller SHA3-256 direkte til å hashe passord. Begge algoritmene er designet for å være raske, noe som er ønskelig for filintegritet og digitale signaturer, men katastrofalt for passordlagring. Med en moderne GPU kan en angriper teste flere milliarder SHA-256-hasher i sekundet mot en stjålet database, noe som gjør brute force-gjetting av svake passord triviell selv med saltede hasher.
Riktig verktøy for passordhashing er algoritmer som er bevisst trege og minnekrevende, som Argon2 (vinneren av Password Hashing Competition i 2015) eller scrypt. Disse er designet for å gjøre parallell GPU/ASIC-basert gjetting dyrt, i motsetning til SHA-256 og SHA-3 som er optimalisert for maksimal hastighet. Hvis systemet ditt i dag hasher passord direkte med SHA-256 eller SHA3-256, uten en passordspesifikk KDF (key derivation function) som Argon2, scrypt eller PBKDF2 med høyt iterasjonstall, bør dette prioriteres høyere enn selve SHA-256-mot-SHA-3-valget. Se vår egen gjennomgang av scrypt-passordhashing i Node.js for en praktisk implementasjon.
Det er verdt å presisere at SHA-256 og SHA-3 fortsatt spiller en rolle i passordsikkerhet, bare ikke som selve hashfunksjonen for lagring. Begge brukes ofte internt i konstruksjonen av KDF-er (PBKDF2 kan for eksempel konfigureres med SHA-256 eller SHA3-256 som underliggende hash), og HMAC-SHA256 brukes fortsatt mye i sesjonstoken og passord-reset-lenker.
Regulatoriske anbefalinger for Norge og Norden
Nasjonal sikkerhetsmyndighet (NSM) og de øvrige nordiske sikkerhetsmyndighetene følger i praksis NISTs og ENISAs anbefalinger for godkjente hashfunksjoner, ettersom Norge ikke opererer med en egen, uavhengig kryptografistandard for kommersiell bruk. Det betyr at både SHA-256 og SHA-3 regnes som godkjente valg for offentlige og private virksomheter i Norge, Sverige, Danmark og Finland, så lenge de brukes i tråd med NISTs veiledning (SP 800-107 Revisjon 1) og kombineres riktig med HMAC eller signaturskjemaer der det er relevant.
For virksomheter som er underlagt NIS2-direktivet, som trådte i kraft for norske virksomheter gjennom den nye digitalsikkerhetsloven, er kravet ikke knyttet til en spesifikk hashalgoritme, men til at kryptografiske kontroller er dokumenterte, risikovurderte og oppdaterte i tråd med anerkjente standarder. SHA-256 tilfredsstiller dette kravet i de aller fleste tilfeller på grunn av sin brede internasjonale aksept, mens SHA-3 kan være et sterkere valg der revisorer eller kunder spesifikt etterspør algoritme-diversitet som en del av en dypere forsvarsstrategi (defense in depth).
Datatilsynet stiller ikke krav til spesifikk hashalgoritme i sin veiledning om kryptering, men forventer at virksomheter kan begrunne valget sitt og holde det oppdatert i tråd med anerkjent praksis. I praksis betyr dette at dokumentasjon av hvorfor SHA-256 eller SHA-3 er valgt, og en plan for å følge med på fremtidige NIST-oppdateringer, teller mer i en revisjon enn selve algoritmevalget.
Bruksområder: hvem bruker faktisk hva
SHA-256 er fortsatt langt mer utbredt i produksjon, og det gjenspeiler seg i hvilke store systemer som bygger på den:
- Bitcoin og Bitcoin-derivater (Bitcoin Cash, Bitcoin SV) bruker dobbel SHA-256 i proof-of-work siden lanseringen i 2009. Minere hasher blokkhoder om og om igjen for å finne en verdi under vanskelighetsmålet.
- TLS-sertifikatkjeder og PKI baserer seg nesten utelukkende på SHA-2-familien for signaturer, ettersom SP 800-107 og NISTs veiledning historisk har fokusert på SHA-2 som standardvalg.
- HMAC-implementasjoner i API-autentisering og webhooks bruker typisk HMAC-SHA256 fordi ytelsen er god og biblioteksstøtten universell.
- Kodesignering og programvaredistribusjon (pakkeforvaltere, container-registre) bruker SHA-256 som kontrollsum-standard.
- Git er i ferd med å tilby SHA-256 som alternativ til det utdaterte SHA-1 for objektintegritet, uten at SHA-3 er vurdert som erstatning.
SHA-3/Keccak-familien har et snevrere, men fortsatt viktig fotfeste:
- Ethereum bruker Keccak-256, en pre-standardiseringsvariant av Keccak, til Merkle-trær, adressegenerering og en rekke EVM-operasjoner. Merk at dette teknisk sett ikke er identisk med NISTs SHA3-256, ettersom paddingreglene endret seg i siste fase av standardiseringen.
- Nyere protokoller som ønsker domeneseparasjon uten HMAC, for eksempel enkelte signaturskjemaer og nøkkelavledningsrutiner, velger SHA-3 eller SHAKE på grunn av svampkonstruksjonens fleksibilitet.
- Enkelte etterkvante kryptografi-byggeklosser bruker SHAKE128/SHAKE256 som del av interne konstruksjoner, siden variabel output-lengde er nyttig der.
- Systemer med krav om algoritme-diversitet, typisk i høyrisikomiljøer som ønsker en reserve dersom SHA-2 en dag skulle svekkes strukturelt.
Prisbilde: hva koster hashvalget i praksis
Hverken SHA-256 eller SHA-3 koster penger i lisens, begge er åpne standarder implementert i alle store kryptografibiblioteker (OpenSSL, BoringSSL, libsodium, Node.js crypto). Den reelle kostnaden ligger i infrastruktur og driftstid, spesielt for systemer som hasher store datamengder kontinuerlig.
| Kostnadsfaktor | SHA-256 | SHA-3 |
|---|---|---|
| Lisenskostnad | Ingen (åpen standard) | Ingen (åpen standard) |
| CPU-tid per GB hashet (server-CPU) | Lavere, ~0,4-0,6 sek/GB | Høyere, ~1,5-2,2 sek/GB |
| Behov for spesialisert maskinvare | Nei, SHA-NI er standard i moderne CPU-er | Nei, men ingen akselerasjon å hente heller |
| Skykostnad ved høyt volum (relativ) | Basislinje | Cirka 3-4x høyere CPU-forbruk ved samme datamengde |
| Biblioteksmodenhet | Svært høy, 20+ år i produksjon | Høy, men færre optimaliserte implementasjoner |
For de aller fleste norske virksomheter er ikke CPU-kostnaden ved hashing i seg selv en betydelig driftsutgift, hashing utgjør typisk en brøkdel av total CPU-last sammenlignet med kryptering, TLS-terminering og databasearbeid. Men for tjenester som hasher enorme datamengder kontinuerlig, for eksempel integritetskontroll av store filarkiv eller blokkjede-noder som verifiserer millioner av transaksjoner, kan 3-4x forskjellen i gjennomstrømning bety reelt merforbruk av virtuelle maskiner i sky.
Fem praktiske eksempler fra virkeligheten
Eksempel 1: Bitcoin-mining. Bitcoin-nettverket kjører dobbel SHA-256 milliarder av ganger i sekundet på tvers av ASIC-maskinvare bygget spesifikt for algoritmen. Dette er trolig den mest ekstreme demonstrasjonen av hvor viktig maskinvareoptimalisering er, spesialiserte SHA-256-ASIC-er er så mye raskere enn generell CPU/GPU at ingen annen hashfunksjon ville vært praktisk mulig å bytte til uten å bygge et helt nytt maskinvareøkosystem.
Eksempel 2: Ethereum og Keccak-256. Ethereums Merkle Patricia Trie, som holder styr på hele kontotilstanden til nettverket, bygger på Keccak-256 for hver node i treet. Beregningen RootHash = Keccak-256(Hash01 || Hash23) illustrerer hvordan sponge-konstruksjonen brukes rekursivt til å bygge sikre datastrukturer, noe som ville vært mer komplisert med en ren Merkle-Damgård-hash på grunn av lengdeutvidelsesrisiko i naive implementasjoner.
Eksempel 3: TLS-sertifikater i norske offentlige tjenester. ID-porten, Altinn og de fleste norske banktjenester signerer sertifikatkjedene sine med SHA-256-baserte signaturalgoritmer (typisk RSA-SHA256 eller ECDSA-SHA256), i tråd med bransjestandarden som CA/Browser Forum krever av alle offentlig tillitsforankrede sertifikater.
Eksempel 4: Git sin overgang bort fra SHA-1. Etter at Google og CWI Amsterdam demonstrerte en praktisk SHA-1-kollisjon i 2017 (kjent som SHAttered-angrepet), begynte Git-prosjektet arbeidet med å tilby SHA-256 som alternativ objektformat. SHA-3 ble aldri seriøst vurdert som erstatning, hovedsakelig fordi SHA-256 allerede hadde moden verktøystøtte og bedre ytelse for versjonskontrollens hashbehov.
Eksempel 5: Filintegritet i store arkiv. Organisasjoner som håndterer petabyte-skala datalagring, for eksempel forskningsarkiver og medieselskaper, bruker ofte SHA-256 for kontrollsummer nettopp på grunn av 3-4x hastighetsfordelen. Ved verifisering av titusenvis av filer daglig utgjør denne forskjellen målbar driftstid, og valget faller nesten alltid på SHA-256 med mindre det finnes et spesifikt krav om SHA-3s strukturelle egenskaper.
Migreringsguide: slik bytter du fra SHA-256 til SHA-3 (eller omvendt)
De færreste systemer bør faktisk migrere, siden begge algoritmene er sikre i 2026. Men dersom du har et konkret behov, for eksempel domeneseparasjon uten HMAC-lag, eller kompatibilitet med en Ethereum-basert protokoll, følg denne rekkefølgen:
- Kartlegg alle steder hashfunksjonen brukes. Se etter direkte kall til hashbiblioteker, men også indirekte bruk gjennom signaturalgoritmer, HMAC-nøkler og databaseindekser som lagrer hashverdier.
- Sjekk biblioteksstøtte. De fleste moderne språk støtter begge ut av boksen: Node.js crypto-modulen støtter «sha3-256» siden OpenSSL 1.1.1, Python har hashlib.sha3_256() innebygd siden 3.6, og Go har golang.org/x/crypto/sha3.
- Test ytelsespåvirkningen med reelle data. Kjør
openssl speed -evp sha256ogopenssl speed -evp sha3-256på produksjonslignende maskinvare før du forplikter deg, siden 3-4x-forskjellen kan bety reell kapasitetsendring. - Planlegg for dobbel skriving ved lagrede hashverdier. Hvis du hasher passord, filintegritet eller signaturer som allerede er lagret, må du regne ut nye hasher parallelt med gamle i en overgangsperiode, siden hashverdier ikke kan konverteres mellom algoritmer.
- Oppdater API-kontrakter og dokumentasjon. Eksterne integrasjoner som validerer signaturer eller sjekksummer må varsles om algoritmebyttet i god tid, spesielt for offentlige API-er med tredjepartsforbrukere.
- Rull ut gradvis med feature-flagg. Ikke bytt hashfunksjon i hele systemet samtidig, la nye data bruke den nye algoritmen mens gamle data verifiseres mot den opprinnelige, inntil migreringen er fullført.
- Overvåk CPU-forbruk etter utrulling. Dersom du bytter fra SHA-256 til SHA-3, forvent økt CPU-last proporsjonalt med hashvolumet, spesielt på systemer uten AVX-512-støtte.
Slik reproduserer du benchmarkene selv
Tallene i denne artikkelen er hentet fra tredjepartsbenchmarker, men det tar under fem minutter å verifisere dem på egen maskinvare. OpenSSL følger med de fleste Linux-distribusjoner og macOS, og kommandoen openssl speed er den mest brukte metoden for å måle bibliotekgjennomstrømning på tvers av algoritmer.
# Test SHA-256 alene
openssl speed -evp sha256
# Test SHA3-256 alene
openssl speed -evp sha3-256
# Sammenlign flere algoritmer i én kjøring
openssl speed sha256 sha3-256 sha3-512
# Sjekk om prosessoren din faktisk bruker SHA-NI
openssl speed -elapsed -evp sha256 2>&1 | grep -i "sha-ni\|aes-ni"Resultatene rapporteres i bytes per sekund for ulike blokkstørrelser (16, 64, 256, 1024, 8192, 16384 byte), og du vil typisk se det samme mønsteret som i tabellene over: SHA-256 leder tydelig fra og med de minste blokkstørrelsene, og forspranget holder seg stabilt gjennom hele skalaen på maskinvare med SHA-NI aktivert. På eldre prosessorer uten SHA-NI, eller på ARM-brikker uten FEAT_SHA256, vil forskjellen være merkbart mindre, siden begge algoritmer da er henvist til generisk SIMD-akselerasjon.
For et mer presist bilde på syklusnivå, bruker forskningsmiljøet ofte eBACS/SUPERCOP-rammeverket utviklet av Daniel J. Bernstein og Tanja Lange, som måler cycles per byte (cpb) med kontrollert metodikk på tvers av implementasjoner og prosessorarkitekturer. Dette er kilden bak flere av Wikipedias oppgitte cpb-tall for SHA-3, og gir et mer maskinvarenøytralt sammenligningsgrunnlag enn rå MB/s-tall, som kan påvirkes sterkt av klokkefrekvens og minnebåndbredde på testmaskinen.
Vanlige implementasjonsfeil å unngå
Uavhengig av hvilken algoritme du velger, dukker de samme feilene opp gang på gang i kodegjennomganger:
- Hashing av hemmeligheter uten HMAC. Å kalle SHA-256(hemmelighet || data) direkte, i stedet for HMAC-SHA256(hemmelighet, data), åpner for lengdeutvidelsesangrep. Bruk alltid HMAC eller et signaturbibliotek som håndterer dette korrekt.
- Å blande opp Keccak-256 og SHA3-256. Dette er trolig den vanligste feilen blant utviklere som kommer fra Ethereum-utvikling til generell backend-utvikling. De to gir ulike avtrykk for identisk input på grunn av ulik padding, og biblioteker som web3.js/ethers.js bruker Keccak-256, ikke NISTs offisielle SHA3-256.
- Bruk av rå hashfunksjon til passord. Som nevnt over: SHA-256 og SHA-3 er for raske til trygg passordlagring. Bruk Argon2id, scrypt eller bcrypt.
- Manglende konstant-tid-sammenligning ved verifisering. Når du sammenligner et beregnet avtrykk mot et lagret avtrykk (for eksempel ved HMAC-verifisering av webhooks), bruk en konstant-tid-sammenligningsfunksjon (som crypto.timingSafeEqual i Node.js) for å unngå timing-angrep, i stedet for standard strengsammenligning.
- Å anta at «nyere er alltid bedre». SHA-3 er nyere enn SHA-256, men det betyr ikke automatisk at det er riktig valg. Ytelseskravene i produksjonssystemet ditt bør styre valget minst like mye som publiseringsdato.
Kodeeksempel: SHA-256 og SHA-3 i Node.js
Begge algoritmene er tilgjengelige gjennom Node.js sin innebygde crypto-modul, som bygger på OpenSSL under panseret:
const crypto = require('crypto');
const data = 'Norsk kryptografitest 2026';
const sha256Hash = crypto.createHash('sha256').update(data).digest('hex');
console.log('SHA-256:', sha256Hash);
const sha3Hash = crypto.createHash('sha3-256').update(data).digest('hex');
console.log('SHA3-256:', sha3Hash);
// Enkel ytelsessammenligning
function benchmark(algo, iterations = 100000) {
const start = process.hrtime.bigint();
for (let i = 0; i < iterations; i++) {
crypto.createHash(algo).update(data).digest('hex');
}
const end = process.hrtime.bigint();
return Number(end - start) / 1e6;
}
console.log('SHA-256 tid (ms):', benchmark('sha256'));
console.log('SHA3-256 tid (ms):', benchmark('sha3-256'));Biblioteksstøtte på tvers av programmeringsspråk
Et undervurdert kriterium når man velger hashfunksjon, er hvor moden og godt testet biblioteksstøtten faktisk er i det språket og rammeverket du bruker. SHA-256 har universell støtte overalt, mens SHA-3 varierer noe mer i modenhet på tvers av økosystemer:
| Språk / plattform | SHA-256-støtte | SHA-3-støtte |
|---|---|---|
| Node.js | Innebygd i crypto-modulen | Innebygd siden OpenSSL 1.1.1 (sha3-256) |
| Python | hashlib.sha256() innebygd | hashlib.sha3_256() innebygd siden 3.6 |
| Go | crypto/sha256 i standardbiblioteket | golang.org/x/crypto/sha3 (utvidelsespakke) |
| Java | MessageDigest.getInstance("SHA-256") | MessageDigest.getInstance("SHA3-256") siden Java 9 |
| Rust | sha2-crate (svært utbredt) | sha3-crate (mindre utbredt, men aktivt vedlikeholdt) |
| PHP | hash('sha256', $data) innebygd | hash('sha3-256', $data) innebygd siden PHP 7.1 |
| .NET / C# | System.Security.Cryptography.SHA256 | Krever tredjepartsbibliotek i .NET-versjoner uten innebygd støtte |
Mønsteret er tydelig: SHA-256 er så godt som alltid innebygd og krever ingen ekstra avhengigheter, mens SHA-3 i enkelte økosystemer (spesielt eldre .NET-versjoner og Go) krever et tredjepartsbibliotek eller en utvidelsespakke. Dette er isolert sett en liten praktisk hindring, men det er en reell faktor når man vurderer vedlikeholdsbyrde og forsyningskjede-risiko (supply chain), siden hver ekstra avhengighet er noe som må holdes oppdatert og sikkerhetsvurderes.
Fordeler og ulemper: SHA-256
Fordeler: Maskinvareakselerert på nesten alle moderne CPU-er (SHA-NI, FEAT_SHA256), 3-4x raskere enn SHA3-256 i praksis, moden og universelt understøttet biblioteksøkosystem, standardvalg i TLS/PKI som gir maksimal kompatibilitet, 20+ år med produksjonsherding uten kjente praktiske svakheter.
Ulemper: Merkle-Damgård-konstruksjonen er strukturelt sårbar for lengdeutvidelsesangrep uten HMAC, deler grunnleggende matematisk arv med SHA-1 (som falt i 2017), og gir ingen algoritme-diversitet dersom et fremtidig strukturelt angrep mot SHA-familien skulle dukke opp.
Fordeler og ulemper: SHA-3
Fordeler: Svampkonstruksjonen unngår lengdeutvidelsesproblemet strukturelt, gir innebygd domeneseparasjon uten ekstra HMAC-lag, tilbyr fleksible XOF-varianter (SHAKE128/256) med variabel output-lengde, og representerer en matematisk uavhengig reserve i tilfelle SHA-2 svekkes.
Ulemper: 3-4x tregere enn SHA-256 på moderne maskinvare på grunn av manglende dedikert prosessorstøtte, mindre utbredt i eksisterende protokoller og verktøy, høyere CPU-kostnad ved hashing i stor skala, og fortsatt et mindretallsvalg i produksjonssystemer utenfor Ethereum-økosystemet.
Fem anbefalinger etter bruksområde
- Generell webapplikasjon, API-autentisering, TLS. Velg SHA-256. Maskinvarestøtten og universell kompatibilitet veier langt tyngre enn de teoretiske fordelene ved SHA-3 for dette bruksområdet, og HMAC-SHA256 løser lengdeutvidelsesproblemet fullt ut.
- Integrasjon mot Ethereum eller EVM-kompatible kjeder. Bruk Keccak-256 (ikke NISTs SHA3-256, merk paddingforskjellen) fordi det er det protokollen faktisk forventer.
- Systemer med høyt hashvolum og begrenset CPU-budsjett. Velg SHA-256, spesielt på servere med SHA-NI, ettersom 3-4x ytelsesforskjellen har direkte skykostnadskonsekvens ved stor skala.
- Nye protokoller som trenger variabel output-lengde eller innebygd domeneseparasjon. Vurder SHA-3/SHAKE, siden svampkonstruksjonen løser disse behovene mer elegant enn å bygge egne konvensjoner oppå SHA-256.
- Høyrisikomiljøer som ønsker kryptografisk diversitet. Vurder å kjøre begge parallelt (for eksempel SHA-256 for hovedsystemet og SHA3-256 som uavhengig integritetskontroll), slik at et fremtidig strukturelt angrep mot én familie ikke kompromitterer hele sikkerhetsmodellen samtidig.
Verdikt: hvilken bør du velge i 2026
Data peker i én klar retning for de fleste norske utviklere: SHA-256 vinner på ytelse med 3-4x margin, dokumentert på tvers av minst tre uavhengige 2025-2026-benchmarker (Kerkour, EPYC 9R14/Graviton 4-testen, og OpenSSL/Wikipedia-tallene). For alt fra TLS-terminering til API-signering og filintegritet i stor skala, er SHA-256 det pragmatiske valget, forutsatt at du bruker HMAC eller riktig domeneseparasjon rundt den for å unngå lengdeutvidelsesrisiko.
SHA-3 fortjener likevel plassen sin. Den er ikke tregere fordi den er dårligere designet, den er tregere fordi prosessorprodusentene aldri bygde dedikert maskinvarestøtte for Keccak slik de gjorde for SHA-256. Strukturelt er svampkonstruksjonen et reelt fremskritt, og for protokoller som Ethereum, eller for organisasjoner som bevisst ønsker algoritme-diversitet som forsikring mot fremtidig kryptoanalyse, er SHA-3 riktig valg uavhengig av ytelsestallene. NISTs offisielle posisjon, at begge er godkjent og sikre gjennom SP 800-107 Revisjon 1, understreker at dette ikke er et spørsmål om trygt versus utrygt. Det er et spørsmål om hva systemet ditt faktisk trenger.
For de fleste norske team er den praktiske konklusjonen enkel: start med SHA-256 med mindre du har en konkret, navngitt grunn til å velge noe annet. Sett HMAC rundt den der hemmeligheter er involvert, hold deg til Argon2 eller scrypt for passord, og revurder valget kun hvis du integrerer mot et system som allerede krever Keccak-256 eller SHA3-256 spesifikt. Dokumenter beslutningen kort i sikkerhetsarkitekturen din, både SHA-256 og SHA-3 er gode nok svar i 2026, men revisorer og fremtidige kolleger vil sette pris på å vite hvorfor du landet der du landet.
Ofte stilte spørsmål
Er SHA-3 sikrere enn SHA-256?
Nei, ikke i praksis. Begge tilbyr 128-bits kollisjonssikkerhet og er godkjent av NIST for produksjonsbruk i 2026. SHA-3 har en strukturell fordel mot lengdeutvidelsesangrep, men SHA-256 løser det samme problemet med HMAC. Ingen praktisk kollisjon er kjent mot noen av dem.
Hvorfor er SHA-256 fortsatt raskere når SHA-3 er nyere?
Fordi Intel og ARM bygde dedikerte prosessorinstruksjoner (SHA-NI, FEAT_SHA256) for SHA-256, mens tilsvarende maskinvareakselerasjon for SHA-3/Keccak ikke er utbredt per 2026. Uten maskinvarestøtte er de to algoritmene mye jevnere i ytelse.
Bruker Bitcoin SHA-3?
Nei. Bitcoin bruker dobbel SHA-256 i proof-of-work-mekanismen sin, og har gjort det siden lanseringen i 2009. SHA-3 spiller ingen rolle i Bitcoins konsensusmekanisme.
Bruker Ethereum SHA-3?
Ethereum bruker Keccak-256, som er en pre-standardiseringsvariant av Keccak-algoritmen som senere ble til SHA-3. Keccak-256 er teknisk sett ikke identisk med NISTs SHA3-256, fordi paddingreglene endret seg i den siste fasen av NIST-standardiseringen.
Kan jeg bruke SHA-3 og SHA-256 samtidig i samme system?
Ja, og for høyrisikomiljøer kan det være en fornuftig strategi. Å kjøre begge parallelt for kritisk integritetskontroll gir kryptografisk diversitet: et fremtidig strukturelt angrep mot den ene familien vil ikke automatisk kompromittere den andre.
Er SHA3-256 det samme som Keccak-256?
Nei, de er nært beslektet men ikke identiske. Keccak-256, som Ethereum bruker, er basert på den opprinnelige Keccak-innsendingen til NIST-konkurransen. NISTs endelige FIPS 202-standard endret paddingreglene noe før publisering i 2015, så SHA3-256 og Keccak-256 gir ulike hashverdier for samme input.
Hvilken bør jeg velge for et nytt prosjekt i 2026?
Velg SHA-256 med HMAC for de aller fleste generelle bruksområder, siden ytelsen og verktøystøtten er overlegen. Velg SHA-3 spesifikt hvis du integrerer mot en protokoll som allerede krever det (som Ethereum), eller hvis du bevisst ønsker svampkonstruksjonens strukturelle egenskaper.
Støtter Node.js og Python SHA-3 ut av boksen?
Ja. Node.js sin innebygde crypto-modul støtter «sha3-256» siden OpenSSL 1.1.1 ble bakt inn, og Python har hashlib.sha3_256() innebygd siden versjon 3.6. Ingen tredjepartsbiblioteker er nødvendig for grunnleggende bruk i noen av språkene.
Er lengdeutvidelsesangrep en reell trussel i 2026?
Bare for naive implementasjoner som hasher hemmelig_nøkkel || melding direkte uten HMAC. Bransjestandarden er å bruke HMAC-SHA256 nettopp for å nøytralisere denne svakheten, og de fleste moderne rammeverk gjør dette automatisk. Risikoen er derfor lav i praksis, men fortsatt reell for hjemmesnekrede autentiseringsløsninger.
Påvirker kvantedatamaskiner SHA-256 og SHA-3 likt?
I hovedsak ja. Grovers algoritme halverer den effektive sikkerhetsstyrken til begge algoritmene mot brute force-preimage-angrep, men siden begge starter med rikelig sikkerhetsmargin (256-bit klassisk, 128-bit mot Grover), er ingen av dem akutt truet av kvantedatamaskiner slik RSA og elliptisk kurve-kryptografi er via Shors algoritme.
Bør jeg bruke SHA-256 eller SHA-3 til passordhashing?
Ingen av dem. Begge er designet for hastighet, som gjør dem uegnet til passordlagring fordi angripere kan brute force-gjette raskt med GPU-akselerasjon. Bruk Argon2id, scrypt eller bcrypt, som er bevisst trege og minnekrevende for å gjøre gjetting dyrt.
Hvor kan jeg lese de offisielle NIST-standardene?
SHA-256 er spesifisert i NIST FIPS 180-4, og SHA-3 er spesifisert i NIST FIPS 202. Begge dokumentene er fritt tilgjengelige fra NISTs publikasjonsdatabase.
Relaterte artikler
- BLAKE3 vs SHA-256: Opptil 12x Raskere [2026]
- SHA-256 forklart: 256-bits avtrykk i praksis
- Ed25519 vs RSA: 33x raskere signaturer, 128-bit sikkerhet [2026]
- ML-KEM vs RSA: 65% av trafikken er kvantesikker [2026]
- HTTPS og TLS 1.3 i Node.js: 12 steg [2026]
- ECDSA Digitale Signaturer i Node.js: 12 Steg, 30 Min [2026]
Se også kategorisiden for kryptografi for flere dypdykk i hashfunksjoner, signaturalgoritmer og etterkvant kryptografi.
Kilder: Wikipedia, SHA-3, Intel SHA Extensions, NIST SP 800-107 Rev. 1, eBACS/SUPERCOP-benchmarker, Keccak Team om FIPS 202.
