Hver gang en fil lastes ned, en commit signeres eller et sertifikat verifiseres i Norden, gjør en hashfunksjon jobben i bakgrunnen. I over to tiår har SHA-256 vært selvsagte valget: det er standardisert av NIST, godkjent for FIPS 140-3 og bygget inn i nesten all moderne CPU-maskinvare. Men siden 2020 har en utfordrer samlet stadig mer oppmerksomhet blant utviklere som flytter enorme datamengder: BLAKE3.

Spørsmålet som stadig oftere dukker opp i norske og nordiske utviklermiljøer er enkelt: er BLAKE3 raskt nok, og sikkert nok, til å erstatte SHA-256 i produksjonssystemer? Denne sammenligningen går gjennom arkitektur, ytelsestall fra fire uavhengige kilder, sikkerhetsnivå, samsvarskrav, kostnad ved hashing i stor skala og en praktisk migrasjonsguide – slik at du kan ta en datadrevet beslutning for ditt eget system.

Bakgrunnen er en datamengde som bare vokser. Sikkerhetskopier måles i petabyte, CDN-er verifiserer innhold kontinuerlig, og bygg-systemer hasher tusenvis av filer for hver commit. Når datamengden skalerer raskere enn budsjettet, blir hashfunksjonens gjennomstrømning – hvor mange gigabyte per sekund den kan behandle per CPU-krone – en arkitekturbeslutning på linje med valg av database eller meldingskø, ikke bare et implementasjonsdetalj man setter og glemmer.

Hva er SHA-256?

SHA-256 er medlem av SHA-2-familien, designet av det amerikanske sikkerhetsbyrået NSA og publisert av NIST i 2001. Algoritmen ble først formalisert i FIPS 180-2, og lever i dag videre i den oppdaterte spesifikasjonen FIPS 180-4, som er den offisielle NIST-standarden for sikre hashalgoritmer. Navnet forteller det meste: algoritmen produserer et 256-bit «avtrykk» (digest) av vilkårlig lange inndata, og gjør det ved hjelp av en konstruksjon som kalles Merkle–Damgård.

SHA-256 er trolig den mest brukte kryptografiske hashfunksjonen i verden i dag. Den ligger i kjernen av Bitcoins proof-of-work, brukes i signaturalgoritmer for TLS-sertifikater som beskytter norske nettbanker og offentlige tjenester, og er en av byggeklossene i digitale signaturer flest steder. Vår egen gjennomgang av SHA-256 forklart: 256-bits avtrykk i praksis går nærmere inn på hvordan algoritmen fungerer internt.

Styrken til SHA-256 ligger ikke i eleganse, men i sporbarhet: algoritmen har vært offentlig gjennomlyst av kryptografer i over 20 år uten at noen har funnet en praktisk kollisjon eller preimage-svakhet mot fullrundeversjonen. Prisen for denne tilliten er at de moderne SIMD-registrene i CPU-er i stor grad forblir ubrukte, fordi SHA-256s indre struktur er iboende sekvensiell.

SHA-256 er dessuten bare ett medlem av en større familie. SHA-2-standarden omfatter også SHA-224, SHA-384 og SHA-512, som deler samme grunnkonstruksjon men bruker andre ordstørrelser og digest-lengder. SHA-256 har blitt normen for de fleste generelle formål fordi 256-bit tilbyr god margin mot bursdagsangrep uten unødig store hashverdier å lagre. Etterfølgeren i NIST-familien, SHA-3 (Keccak), bruker en helt annen svamp-konstruksjon (sponge) og ble standardisert som et supplement til, ikke en erstatning for, SHA-2 – nettopp for å gi et strukturelt alternativ dersom det noen gang skulle dukke opp en svakhet i Merkle–Damgård-familien.

Hva er BLAKE3?

BLAKE3 ble lansert i 2020 av et team bestående av Jack O’Connor, Jean-Philippe Aumasson, Samuel Neves og Zooko Wilcox-O’Hearn – flere av dem samme personer som sto bak forgjengerne BLAKE og BLAKE2, som igjen bygger videre på ChaCha-strømchifferet. Målet var tydelig fra dag én: bygge en hashfunksjon som er rask nok til å mette moderne SIMD- og flerkjerneprosessorer, uten å ofre sikkerhetsmarginen.

I stedet for én smal spesifikasjon samler det offisielle BLAKE3-repoet på GitHub flere funksjoner i ett verktøy: vanlig hashing, nøkkelbasert hashing (som kan erstatte HMAC), nøkkelutledning (KDF) og en utvidbar utdatamodus (XOF) som kan produsere avtrykk av vilkårlig lengde. Koden er dobbeltlisensiert under CC0-1.0 og Apache-2.0, og repoet har i skrivende stund passert 6.400 stjerner på GitHub – et tydelig tegn på at prosjektet har fått fotfeste blant utviklere som jobber med alt fra bygg-systemer til fildeling.

De fire modusene er verdt å forstå hver for seg, fordi de erstatter verktøy man tradisjonelt måtte hente fra flere forskjellige biblioteker. Hash er standardmodusen for integritetssjekk og innholdsadressering. Keyed hash tar imot en 256-bit nøkkel og gir deg meldingsautentisering uten en separat HMAC-konstruksjon. Derive key bruker en kontekststreng til å utlede nye nøkler fra et mastermateriale, altså samme oppgave som KDF-er som HKDF løser for SHA-256. XOF, den utvidbare utdatamodusen, lar deg trekke ut så mange byte du trenger fra samme interne tilstand – praktisk for strømkryptering eller når du trenger lengre avtrykk enn 256 bit uten å bytte algoritme.

Det som skiller BLAKE3 mest fra forgjengerne, er ikke selve komprimeringsfunksjonen – den er en videreutvikling av BLAKE2s design – men den ytre strukturen. Der SHA-256 tvinger data gjennom én lang, sekvensiell kjede, deler BLAKE3 input opp i uavhengige biter som kan hashes parallelt og deretter kombineres i et binært tre. Det er denne endringen som gir de store ytelsesgevinstene vi går gjennom lenger ned.

Teknisk arkitektur: Merkle–Damgård mot trestruktur

SHA-256 bruker en klassisk Merkle–Damgård-konstruksjon: meldingen deles i 512-bit blokker som behandles én etter én, der hver blokk avhenger av resultatet fra forrige blokk. Hver blokk gjennomgår 64 runder med bitvise operasjoner på 32-bit ord. Denne sekvensielle avhengigheten er selve grunnen til at SHA-256 aldri kan bruke mer enn én prosessorkjerne til å hashe én sammenhengende datastrøm, uansett hvor mange kjerner maskinen har til rådighet.

BLAKE3 løser dette annerledes. Data deles opp i biter (chunks) på 1024 byte hver, som igjen består av seksten indre 64-byte blokker. Hver chunk hashes uavhengig av alle de andre, og resultatene kombineres deretter parvis oppover i et binært tre – ofte omtalt som en «Bao-trestruktur» etter det tilhørende strømmeprotokoll-prosjektet – til man sitter igjen med én rot-hash. For små meldinger under 1024 byte faller BLAKE3 tilbake til å hashe én eneste chunk, så det påløper ingen unødig treoverhead for typiske små verdier som API-nøkler eller korte identifikatorer. Komprimeringsfunksjonen selv bruker bare 7 runder mot SHA-256s 64, men det er ikke en sikkerhetssvekkelse: hver BLAKE3-runde oppnår fullstendig diffusjon på tvers av hele den interne tilstanden, mens SHA-256 trenger mange flere, svakere runder for å oppnå tilsvarende blanding.

Enkelttråd: rå hastighet per kjerne

Selv på én enkelt CPU-kjerne, uten noen som helst flertråding, er BLAKE3 raskere enn SHA-256. Grunnen er at BLAKE3s indre operasjoner – 32-bit XOR, addisjon og rotasjon – pakker seg naturlig inn i brede SIMD-registre som AVX2 og AVX-512, slik at fire parallelle BLAKE3-tilstander kan behandles i ett og samme 256-bit register. SHA-256s addisjon-med-overføring-operasjoner lar seg derimot vanskelig SIMD-optimalisere på samme måte, og er i stedet avhengig av dedikerte maskinvareinstruksjoner (SHA Extensions) for å hente ut lignende ytelse.

Flertråd: hvor BLAKE3 trekker fra

Forskjellen blir dramatisk når flere kjerner kommer inn i bildet. Fordi BLAKE3s trestruktur lar uavhengige grener av treet hashes på forskjellige kjerner samtidig, skalerer ytelsen nær lineært med antall tilgjengelige kjerner for én enkelt, stor fil. SHA-256 har ingen slik mekanisme innebygget i selve algoritmen – skal du hashe én sammenhengende fil raskere med SHA-256, må du enten dele filen manuelt i biter selv, eller akseptere at hastigheten er låst til én kjernes gjennomstrømning.

Spesifikasjoner side om side

Tabellen under oppsummerer de tekniske spesifikasjonene til begge algoritmene, hentet fra offisiell dokumentasjon, NIST-standarden og BLAKE3-teamets egen spesifikasjon.

EgenskapBLAKE3SHA-256
Utgivelsesår20202001 (FIPS 180-2), FIPS 180-4 i dag
Designet avJack O’Connor, Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O’HearnNSA, publisert av NIST
Digest-størrelse (standard)256 bit256 bit
Utvidbar utdata (XOF)JaNei
KonstruksjonTre-struktur med parallelle chunksMerkle–Damgård (sekvensiell)
Antall komprimeringsrunder764
Kollisjonsresistens~128 bit~128 bit
Preimage-resistens~256 bit~256 bit
Sårbar for lengde-utvidelsesangrepNeiJa, ved naiv bruk uten HMAC
LisensCC0-1.0 / Apache-2.0Åpen NIST-spesifikasjon, fri implementasjon
FIPS 140-3-godkjentNeiJa
MaskinvareakselerasjonSIMD: AVX2, AVX-512, NEONDedikerte instruksjoner: Intel SHA Extensions, ARMv8 Crypto Extensions
Multitråd-skalering (én fil)Nær lineær med antall kjernerIngen – låst til én kjernes hastighet
GitHub-stjerner (offisielt repo)6.400+Ikke aktuelt – NIST-spesifikasjon, ikke ett enkelt bibliotek

Legg merke til at kollisjons- og preimage-resistensen er identisk på papiret: begge algoritmene har 256-bit utdata som standard, og følger derfor samme matematiske «bursdagsgrense» på omtrent 128 bit for kollisjonsresistens. Forskjellen mellom de to ligger ikke i den teoretiske sikkerhetsmarginen, men i modenhet, standardstatus og ytelseskarakteristikk.

Det er også verdt å merke seg at «GitHub-stjerner» i tabellen ikke er et sikkerhetsmål, men et grovt mål på utvikleroppmerksomhet – SHA-256 har ingen tilsvarende metrikk fordi det er en spesifikasjon som er implementert på nytt i titalls forskjellige biblioteker og programmeringsspråk, ikke ett enkelt referanseprosjekt. Når du sammenligner reell adopsjon, gir det derfor mer mening å se på hvor mange språk og rammeverk som har innebygd støtte: SHA-256 er del av standardbiblioteket i praktisk talt alle moderne språk, mens BLAKE3 typisk krever et eksternt bibliotek eller crate, om enn offisielt vedlikeholdt.

Ytelsestester: Hva sier benchmarkene?

Påstander om «x ganger raskere» er lette å skrive og vanskelige å stole på uten kilder. Vi har derfor samlet tall fra fire uavhengige kilder: BLAKE3-teamets egen spesifikasjon, en akademisk studie, en ytelsesdiskusjon fra Python-prosjektets feilsporing, og en uavhengig 2025-benchmark publisert av DevToolsPro. Alle peker i samme retning, selv om den eksakte faktoren varierer med maskinvare og tråd-antall.

Kilde og testoppsettSHA-256BLAKE3
BLAKE3-teamets spesifikasjon – Intel Cascade Lake-SP, 1 trådBasislinje12x raskere
BLAKE3-teamets spesifikasjon – ARM1176, 1 trådBasislinje1,3x raskere
Akademisk studie (arXiv 2407.08284) – 1 tråd0,8 GB/s1,4 GB/s
Samme studie – 16 tråder3,2 GB/s21,3 GB/s
Python-prosjektets ytelsestest – OpenSSL mot AVX-5121.816 MB/s8.754 MB/s
DevToolsPro-benchmark – AMD Ryzen 9 7950X, maskinvareakselerert mot AVX-5122,8–3,2 GB/s8,4–12 GB/s
DevToolsPro-benchmark – 16 kjerner, én fil3,0 GB/s (skalerer ikke)92 GB/s

Kilder: BLAKE3-teamets offisielle spesifikasjon, Python-prosjektets ytelsesdiskusjon (bpo-39298) og DevToolsPros 2025-benchmark av SHA-256-alternativer, testet på AMD Ryzen 9 7950X med OpenSSL 3.2 og Rusts sha2-crate.

Mønsteret er konsistent: enkelttråds-forskjellen ligger typisk mellom 1,75x og 4,8x avhengig av instruksjonssett, mens den virkelig store forskjellen kommer med flere kjerner. Når SHA-256 er låst til én kjernes gjennomstrømning uansett maskinvare, mens BLAKE3s tre-struktur skalerer nær lineært, ender man opp med opptil 11 ganger forskjell i rå gjennomstrømning på en 16-kjerners maskin i DevToolsPros målinger – og enda mer på prosessorer uten dedikert SHA-akselerasjon, som mange ARM- og RISC-V-brikker.

Legg merke til at spredningen mellom kildene – fra 1,75x til 12x på enkelttråd – ikke betyr at tallene motsier hverandre. Forskjellen skyldes testmetodikk: hvilken CPU-generasjon som er brukt, om kompilatoren fikk lov til å bruke AVX-512 eller ble begrenset til eldre SSE-instruksjoner, hvor stor inndataen var, og om testen målte kald oppstart eller gjennomstrømning på store, sammenhengende datamengder. Det gjennomgående mønsteret holder likevel på tvers av alle fire kilder: BLAKE3 taper aldri en eneste målt sammenligning mot SHA-256, uansett maskinvare eller metodikk.

Sikkerhetsnivå og kryptoanalyse

Ytelse betyr lite hvis sikkerheten ikke holder mål. Her er nyansen viktig: ingen offentlig kjent metode bryter fullrundeversjonen av verken SHA-256 eller BLAKE3 i 2026. Begge regnes som kryptografisk sikre for sitt tiltenkte bruksområde, og publiserte angrep har konsekvent vært begrenset til kunstig reduserte rundeversjoner av algoritmene – ikke de faktiske standardene som brukes i produksjon.

Forskjellen som faktisk betyr noe i praksis, handler om konstruksjon, ikke rundetall. SHA-256s Merkle–Damgård-oppbygning gjør den sårbar for såkalte lengde-utvidelsesangrep dersom den brukes naivt – for eksempel som SHA-256(hemmelig_nøkkel || melding) for å lage en meldingsautentiseringskode. En angriper kan da regne ut en gyldig hash for en utvidet melding uten å kjenne selve nøkkelen. Løsningen er å bruke HMAC-SHA-256 i stedet for rå SHA-256 til slike formål – noe de fleste moderne biblioteker allerede tvinger deg til. BLAKE3s tre-baserte konstruksjon er ikke sårbar for det samme angrepsmønsteret, og har i tillegg en innebygd nøkkelbasert modus som gjør en egen HMAC-konstruksjon unødvendig.

Når det gjelder kvantedatamaskiner, står de to likt. Grovers algoritme gir i teorien en kvadratisk hastighetsøkning mot preimage-søk, noe som halverer den effektive sikkerhetsmarginen for begge – fra 256 bit til rundt 128 bit under et hypotetisk stort kvanteangrep. Det gjelder uansett hvilken av de to algoritmene man velger, og er ikke et argument for å foretrekke den ene fremfor den andre.

Den ene reelle asymmetrien er alder og gransking. SHA-256 har vært offentlig tilgjengelig og aktivt angrepet av kryptografer i over to tiår uten praktisk gjennombrudd. BLAKE3 er yngre, med færre år med uavhengig kryptoanalyse bak seg, selv om komprimeringsfunksjonen arver mye av sikkerhetsanalysen fra BLAKE2, som selv har vært gjennom omfattende ekstern gransking siden 2012.

Dette arveforholdet er faktisk et av BLAKE3-teamets sterkeste argumenter: fordi komprimeringsfunksjonen viderefører design fra BLAKE2, som igjen viderefører design fra finalisten ChaCha20 i SHA-3-konkurransen, står ikke BLAKE3 helt uten sikkerhetshistorikk – den arver en linje av kryptoanalyse som strekker seg over mer enn et tiår, selv om selve BLAKE3-spesifikasjonen er yngre. Det er likevel en vesensforskjell mellom «arvet analyse av en beslektet konstruksjon» og «direkte analyse av den eksakte algoritmen som kjører i produksjon», og den forskjellen er nettopp hvorfor konservative miljøer fortsatt foretrekker SHA-256 der valget er vanskelig å reversere i etterkant.

FIPS-godkjenning og samsvarskrav

For mange norske og nordiske virksomheter er sikkerhetsnivå kun halve historien – det andre halve er formelt samsvar. SHA-256 inngår i SHA-2-familien som er godkjent under NISTs offisielle prosjekt for hashfunksjoner, og brukes i kryptografiske moduler som er FIPS 140-3-validert. BLAKE3 er, per i dag, ikke en NIST-godkjent algoritme og finnes ikke i noen FIPS 140-3-validert modul.

I praksis betyr dette at offentlig sektor, finans og helsevirksomheter i Norge – som ofte er bundet av krav som speiler amerikanske FIPS-standarder gjennom internasjonale rammeverk, i tillegg til EU-regelverk som NIS2 og GDPR – som hovedregel må holde seg til SHA-256, SHA-384, SHA-512 eller SHA-3 der en revisor eller tilsynsmyndighet skal godkjenne den kryptografiske løsningen. Det er ikke fordi BLAKE3 er mindre sikkert i teknisk forstand, men fordi det ennå ikke er evaluert og sertifisert gjennom de formelle prosessene disse standardene krever.

Utenfor de compliance-tunge sektorene – interne systemer, bygg-verktøy, innholdsadressering, fildeling mellom tjenester du selv kontrollerer – er FIPS-status ofte irrelevant, og da åpner ytelsesfordelen til BLAKE3 seg opp uten noen reell ulempe.

Selve FIPS 140-3-prosessen er verdt å kjenne til før man avfeier den som byråkrati: en kryptografisk modul må gjennom NISTs Cryptographic Module Validation Program (CMVP), der uavhengige, akkrediterte laboratorier tester implementasjonen mot en detaljert sikkerhetsspesifikasjon før modulen får et gyldig sertifikat. Prosessen tar typisk måneder, koster betydelige summer, og må gjentas når implementasjonen endres vesentlig. Det er nettopp denne tunge, formelle prosessen som gjør at nye algoritmer som BLAKE3 sjelden blir FIPS-validert raskt, uavhengig av hvor solid den underliggende matematikken er – godkjenningen henger etter den tekniske sikkerheten, ikke omvendt.

Kostnad ved hashing i stor skala

Verken BLAKE3 eller SHA-256 koster noe å bruke – begge er gratis, åpne implementasjoner uten lisensavgifter. Den reelle «prisen» ligger i noe annet: hvor mye CPU-tid som må kjøpes i skyen for å hashe en gitt datamengde. Vi har regnet ut et konkret eksempel basert på AWS-instansen c7g.large (2 vCPU, Graviton3, listepris 0,073 dollar/time) og gjennomstrømningstallene fra benchmark-tabellen over. Metodikken er enkel: total vCPU-tid = datamengde delt på gjennomstrømning per kjerne, multiplisert med timeprisen per vCPU.

ScenarioSHA-256BLAKE3Besparelse med BLAKE3
Referansepris (AWS c7g.large, on-demand)$0,073/time$0,073/timeSamme instans
Gjennomstrømning uten maskinvareakselerasjon0,8 GB/s8,4 GB/s10,5x
Beregnet vCPU-kostnad per hashet petabyte (programvare)~$12,63~$1,20~90%
Beregnet vCPU-kostnad per hashet petabyte (maskinvareakselerert)~$3,37~$1,20~64%
Tid for å hashe 1 TB på 16 kjerner parallelt~21 minutter (skalerer ikke)~11 sekunder~114x raskere

Tallene i tabellen er redaksjonelt beregnet av Shattered.io ut fra offentlig publiserte gjennomstrømningstall og AWS’ listepriser – de er ikke hentet fra en offisiell kostnadsrapport, og bør behandles som et illustrerende overslag, ikke et eksakt regnestykke for din egen arbeidsmengde. Det viktigste funnet er likevel tydelig: kostnadsfordelen til BLAKE3 er størst nettopp der SHA-256 ikke har maskinvarestøtte – altså på eldre servere, rimelige skyinstanser og mange ARM- og RISC-V-baserte enheter. Har du full tilgang til SHA-NI-instruksjoner, krymper gapet til en fortsatt merkbar, men mindre dramatisk, forskjell.

Beregningen holder seg bevisst til én skyleverandør og én instanstype for å gi et konsistent sammenligningsgrunnlag, men mekanismen er generell: enhver arbeidsmengde som fakturerer per vCPU-time – enten det er AWS, Azure, Google Cloud eller en europeisk skyleverandør med driftssted i Norden – vil se samme relative besparelse, siden forholdet mellom gjennomstrømningstallene er det som driver kostnadsforskjellen, ikke selve dollarbeløpet. For team som hasher kontinuerlig, for eksempel en norsk CDN-tjeneste eller en skybasert backup-leverandør som verifiserer integriteten til kundedata døgnet rundt, kan selv en besparelse på 60–90 % av hashing-relatert CPU-tid utgjøre et merkbart utslag på den månedlige skyregningen ved høyt volum.

Reelle eksempler: Hvem bruker hva?

Teoretiske sammenligninger blir mer konkrete når man ser hvor algoritmene faktisk brukes i produksjon. Vi har bevisst holdt oss til eksempler som lar seg verifisere direkte mot offisiell dokumentasjon eller kildekode, i stedet for løse påstander om hvem som «visstnok» bruker hva – flere ofte siterte adopsjonspåstander for BLAKE3, blant annet enkelte sikkerhetskopieringsverktøy, lot seg ikke bekrefte i disse verktøyenes egne endringslogger da vi sjekket, og er derfor utelatt.

  • Bitcoin (SHA-256): Hele proof-of-work-mekanismen bygger på dobbel SHA-256-hashing (SHA-256d) av blokk-headere. Skiftet vekk fra SHA-256 her er praktisk talt utenkelig, siden hele nettverkets konsensusregler er bygget rundt algoritmen.
  • TLS-sertifikater (SHA-256): Signaturalgoritmene som beskytter HTTPS-forbindelsen til norske banker, det offentlige og nettbutikker, bruker i all hovedsak SHA-256 som en del av signatur-hashen i X.509-sertifikater.
  • Gits pågående SHA-256-overgang: Git bygger historisk på SHA-1, men prosjektet valgte SHA-256 som etterfølger allerede i 2018. Ifølge Gits offisielle dokumentasjon om overgangen er SHA-256-repositorier fortsatt eksperimentelle, og prosjektet fraråder eksplisitt bruk på offentlig tilgjengelige servere inntil protokollstøtten er ferdigstilt.
  • Iroh og innholdsadressering (BLAKE3): Prosjektet iroh bruker BLAKE3 gjennom komponenten iroh-blobs til innholdsadressert dataoverføring som skal skalere fra kilobyte til terabyte – et direkte eksempel på hvordan tre-strukturen utnyttes for store, verifiserte filoverføringer.
  • b3sum som sjekksumverktøy (BLAKE3): Det offisielle kommandolinjeverktøyet b3sum, distribuert sammen med BLAKE3-referanseimplementasjonen, fungerer som en direkte erstatning for sha256sum og er blant annet pakketert for Ubuntu – nyttig for integritetssjekk av store nedlastinger og sikkerhetskopier.
  • Passordhashing (verken SHA-256 eller BLAKE3): Et viktig unntak: ingen av algoritmene bør brukes direkte til å lagre passord. Begge er designet for å være raske, som er nøyaktig egenskapen du ikke vil ha når en angriper prøver å gjette passord offline. Til det formålet er Argon2, bcrypt eller scrypt riktig verktøy, fordi de er bevisst designet for å være trege og minnekrevende.
  • Digitale signaturer (SHA-256): Når et dokument eller en programvarepakke signeres digitalt, hashes innholdet først – typisk med SHA-256 – før selve signaturalgoritmen (RSA, ECDSA eller Ed25519) opererer på den korte hashverdien i stedet for hele dokumentet. Vår gjennomgang av Ed25519 vs RSA ser nærmere på hvordan denne kombinasjonen fungerer i praksis.

Når bør du velge BLAKE3? Fem bruksområder

Basert på arkitekturforskjellene og ytelsestallene over, peker valget seg ofte ut naturlig avhengig av hva du faktisk bygger.

  1. Sikkerhetskopiering og deduplisering av store filmengder: Når du skal hashe titalls eller hundretalls terabyte for å oppdage duplikater eller endringer, gir BLAKE3s flerkjerne-skalering en reell tidsbesparelse som vokser proporsjonalt med datamengden.
  2. Bygg-systemer og CI/CD-fingeravtrykk: Når du kontrollerer både produsent og konsument av hashene – for eksempel cache-nøkler i et internt bygg-system – finnes det ingen interoperabilitetsgrunn til å holde på SHA-256, og hastigheten kutter direkte ventetid i pipelinen.
  3. ARM-, RISC-V- og innebygde enheter uten kryptoutvidelser: På maskinvare som mangler SHA Extensions eller ARMv8 Crypto Extensions, som mange billige enkeltkortdatamaskiner og eldre AWS Graviton-generasjoner, er BLAKE3s programvarebaserte SIMD-ytelse betydelig foran SHA-256 i ren programvare.
  4. Innholdsadressert lagring og fildelingsprotokoller: Systemer som identifiserer data ved hashen deres i stedet for et filnavn, drar nytte av BLAKE3s innebygde trestruktur, som gjør det mulig å verifisere delvise nedlastinger uten å hashe hele filen på nytt.
  5. Interne API-er med høyt volum: Har du kontroll på begge endepunkter og hasher store mengder forespørsler eller meldinger internt (for eksempel deduplisering i en meldingskø), gir BLAKE3s lave rundetall per byte lavere CPU-forbruk per forespørsel.
  6. Multipart-opplasting og strømmeverifisering: Fordi BLAKE3s trestruktur lar deg verifisere enkeltbiter av en fil uten å hashe hele filen på nytt, egner den seg godt til opplastingstjenester som verifiserer data i biter mens de strømmes, i stedet for å vente til hele filen er mottatt.

Motsatt bør du holde deg til SHA-256 når du har eksterne API-kontrakter som forventer SHA-256, når regulatoriske krav om FIPS 140-3 gjelder, når du jobber med blokkjede-protokoller med hashen hardkodet inn i konsensusreglene, eller når du rett og slett vil ha den lengste mulige historikken med offentlig kryptoanalyse bak avgjørelsen.

Migrasjonsguide: Fra SHA-256 til BLAKE3

Å bytte hashalgoritme i et system som allerede er i produksjon krever planlegging – hashverdier lagres ofte i databaser, filnavn og API-kontrakter som ikke tåler en brå endring. Her er en praktisk, trinnvis tilnærming.

  1. Kartlegg hvor hashen brukes. Identifiser hver database-kolonne, hvert filnavn og hver API-respons som inneholder en SHA-256-verdi, samt hvem som konsumerer den – interne systemer, eksterne partnere eller sluttbrukere. Ikke undervurder denne fasen: de fleste feilslåtte migrasjoner skyldes en glemt konsument, ikke en teknisk feil i selve algoritmen.
  2. Sjekk lengdeantakelser. Begge algoritmene produserer 256-bit (64 tegn i hex) som standard, så faste kolonnebredder trenger normalt ingen endring – men verifiser dette eksplisitt i skjemaet ditt før du går videre, spesielt hvis eldre kode har hardkodet antakelser om at verdien alltid kommer fra SHA-256.
  3. Kjør en dobbelthash-periode. Beregn både SHA-256 og BLAKE3 parallelt i en overgangsfase, slik at eksisterende verifiseringslogikk fortsatt fungerer mens nye klienter gradvis tas i bruk. Denne fasen bør vare lenge nok til at du kan overvåke feilrater i produksjon før du fjerner den gamle stien.
  4. Oppdater biblioteker og avhengigheter. Legg til BLAKE3-biblioteket for språket ditt (offisielle bindinger finnes for Rust, C, Python og flere andre språk via det offisielle GitHub-repoet), og lås versjonen eksplisitt i avhengighetsfilen slik at ikke en fremtidig oppdatering endrer oppførsel uventet.
  5. Verifiser samsvarskrav på nytt. Bekreft med sikkerhets- eller complianceansvarlig at ingen FIPS 140-3- eller sektorspesifikke krav blokkerer overgangen, før den rulles ut i produksjon. Dette steget bør gjøres tidlig, ikke som en etterpåklokskap rett før lansering.
  6. Mål den faktiske ytelsesgevinsten. Sammenlign CPU-forbruk og svartid før og etter overgangen i et produksjonslignende miljø. Synteter benchmarker fra denne artikkelen gir en pekepinn, men den eneste tallrekken som betyr noe for budsjettet ditt, er den du måler på din egen arbeidsmengde.
  7. Fullfør overgangen og fjern dobbelthashing. Når alle konsumenter er oppdatert og overvåkingen viser stabil drift over tid, kan SHA-256-beregningen fjernes – behold gjerne en midlertidig fallback-sti i tilfelle eldre klienter dukker opp uventet.

Et enkelt eksempel på hvordan dobbelthash-perioden kan se ut i Python, ved bruk av standardbiblioteket hashlib for SHA-256 og pakken blake3 for BLAKE3:

import hashlib
from blake3 import blake3

def dobbelthash(data: bytes) -> dict:
    return {
        "sha256": hashlib.sha256(data).hexdigest(),
        "blake3": blake3(data).hexdigest(),
    }

def verifiser_mot_gammel_hash(data: bytes, lagret_sha256: str) -> bool:
    return hashlib.sha256(data).hexdigest() == lagret_sha256

På kommandolinjen tilsvarer overgangen ganske enkelt å kjøre begge verktøyene side om side inntil du er trygg på at alle nedstrøms systemer takler den nye verdien:

sha256sum backup.tar.gz
b3sum backup.tar.gz

Fordeler og ulemper

Ingen av algoritmene er universelt «best» – valget avhenger av hvilke av disse egenskapene som veier tyngst i akkurat ditt system. Oppsummeringen under samler funnene fra hele sammenligningen i en rask referanse du kan bruke i en arkitekturdiskusjon eller et teknisk beslutningsdokument.

BLAKE3 – fordeler:

  • Opptil 12x raskere enn SHA-256 på enkelttråd, og enda mer med flere kjerner, ifølge BLAKE3-teamets egne tall
  • Skalerer nær lineært med antall CPU-kjerner for store filer
  • Innebygd nøkkelbasert modus og XOF gjør separate HMAC- og KDF-konstruksjoner unødvendige
  • Rask i ren programvare selv uten dedikert kryptomaskinvare
  • Ikke sårbar for lengde-utvidelsesangrep

BLAKE3 – ulemper:

  • Ikke FIPS 140-3-godkjent, og dermed uegnet der formelt samsvar kreves
  • Vesentlig kortere historikk med uavhengig kryptoanalyse enn SHA-256
  • Mindre universell støtte i eldre systemer, protokoller og eksterne API-er

SHA-256 – fordeler:

  • FIPS 140-3-godkjent og akseptert i praktisk talt alle compliance-rammeverk
  • Over 20 år med offentlig kryptoanalyse uten praktisk brudd på fullrundeversjonen
  • Universell støtte – innebygd i nesten alle språk, biblioteker og protokoller
  • Dedikert maskinvareakselerasjon (SHA Extensions) på de fleste moderne x86- og ARM-brikker

SHA-256 – ulemper:

  • Kan ikke parallellisere hashingen av én enkelt datastrøm, uansett antall kjerner
  • Betydelig tregere i ren programvare uten maskinvareakselerasjon
  • Sårbar for lengde-utvidelsesangrep ved naiv bruk uten HMAC

Satt på spissen: velger du BLAKE3, kjøper du ytelse og moderne design mot en fortsatt kort sikkerhetshistorikk og manglende sertifisering. Velger du SHA-256, kjøper du to tiår med tillit og universell kompatibilitet mot en algoritme som aldri kommer til å bli vesentlig raskere enn den er i dag.

Norge og Norden: GDPR, NIS2 og praktiske hensyn

For norske og nordiske utviklingsteam kommer valget av hashfunksjon sjelden isolert – det henger sammen med et regelverk som stadig strammes til. NIS2-direktivet er i ferd med å utvide kravene til risikostyring og teknisk sikkerhet for et bredere sett av virksomheter i Norge, og GDPR artikkel 32 krever «passende tekniske og organisatoriske tiltak» for å beskytte persondata, uten å liste opp spesifikke algoritmer.

GDPR og kravet til dokumenterte tekniske tiltak

Verken GDPR eller norsk personopplysningslov spesifiserer eksplisitt hvilken hashalgoritme som skal brukes til hva. I praksis betyr det at ansvaret for å begrunne valget faller på virksomheten selv. For offentlig sektor, finans og andre regulerte bransjer i Norge er SHA-256 ofte det tryggeste standardvalget nettopp fordi det er FIPS-godkjent og lett å dokumentere overfor revisor eller tilsyn. For interne, høyytelses systemer uten eksterne compliance-krav – for eksempel en norsk skybasert backup-tjeneste som kun hasher data internt mellom egne servere – er BLAKE3s ytelsesfortrinn ofte verdt å utnytte, så lenge valget er dokumentert som en bevisst arkitekturbeslutning og ikke en tilfeldighet.

Den praktiske anbefalingen for nordiske team er derfor todelt: bruk SHA-256 som forvalg i alt som krysser en compliance-grense, og vurder BLAKE3 spesifikt der ytelse er en målt flaskehals i interne systemer dere selv kontrollerer fullt ut.

Datalagring og databehandlingssted spiller også inn i vurderingen. Flere nordiske skyleverandører og datasentre markedsfører seg nettopp på lokal databehandling og forutsigbar jurisdiksjon under EU/EØS-regelverk. Uansett hvor dataene fysisk ligger, endrer ikke det kravet om at den kryptografiske metoden skal være egnet og dokumentert – men det er en praktisk fordel at spørsmålet om hashalgoritme kan behandles isolert fra den ofte mer kompliserte diskusjonen om hvor selve dataene lagres. Et team som allerede har løst datalagringsspørsmålet med en nordisk eller europeisk skyleverandør, bør likevel gå gjennom hashvalget som en egen, eksplisitt beslutning – ikke anta at det følger automatisk med valget av leverandør.

Konklusjon: Den datadrevne dommen

Tallene fra fire uavhengige kilder peker samstemt i én retning på ren ytelse: BLAKE3 er mellom 1,3x og 12x raskere enn SHA-256 på én kjerne, avhengig av maskinvare og instruksjonssett, og opptil rundt 11x raskere enn SHA-256s faste gjennomstrømning når flere kjerner brukes til å hashe én stor fil. Den beregnede kostnadsfordelen i skyen følger samme mønster: opptil 90 % lavere vCPU-kostnad ved hashing i stor skala uten maskinvareakselerasjon, og fortsatt rundt 64 % lavere selv med SHA-NI tilgjengelig.

Men ytelse er ikke hele historien. SHA-256 vinner utvetydig på formelt samsvar (FIPS 140-3), på lengden av sin offentlige sikkerhetshistorikk, og på ren utbredelse i eksisterende protokoller og API-kontrakter. BLAKE3 vinner like utvetydig på rå hastighet, flerkjerneskalering og enkelhet i design.

Den datadrevne dommen er derfor ikke «den ene vinner alltid», men en klar beslutningsregel: velg SHA-256 når compliance, interoperabilitet eller maksimal kryptoanalytisk historikk er avgjørende, og velg BLAKE3 når du kontrollerer hele systemet selv og ytelse er en målt, reell flaskehals. For de fleste nye interne systemer bygget fra bunnen av i 2026, uten eksterne compliance-krav, er BLAKE3 i økende grad det tekniske foretrukne valget – men SHA-256 kommer ikke til å forsvinne fra kritisk infrastruktur med det første.

Det mest edruelige rådet er kanskje dette: la ikke ytelsestallene alene styre beslutningen. En 3–12x fartsforbedring er irrelevant hvis hashingen aldri var en flaskehals i utgangspunktet, og et FIPS-krav du overser i dag kan bli en dyr ombygging senere. Mål din egen arbeidsmengde, sjekk dine egne compliance-forpliktelser, og bruk tallene i denne artikkelen som utgangspunkt for den samtalen – ikke som en fasit du kan kopiere direkte inn i arkitekturen din.

Ofte stilte spørsmål

Hvor mye raskere er BLAKE3 enn SHA-256?
Avhengig av kilde og maskinvare er BLAKE3 mellom 1,3x og 12x raskere enn SHA-256 på én kjerne, og opptil rundt 11x raskere enn SHA-256s faste gjennomstrømning ved bruk av 16 kjerner på én fil, ifølge BLAKE3-teamets spesifikasjon og uavhengige 2025-benchmarker.

Er BLAKE3 like sikkert som SHA-256?
På papiret har begge samme teoretiske sikkerhetsnivå: cirka 128-bit kollisjonsresistens og 256-bit preimage-resistens ved 256-bit utdata. Ingen fullrundeversjon av noen av dem er offentlig kjent brutt. Forskjellen ligger i modenhet – SHA-256 har over 20 års offentlig kryptoanalyse, mens BLAKE3 har rundt fem-seks år.

Er BLAKE3 godkjent av NIST eller FIPS?
Nei. BLAKE3 er ikke en NIST-standardisert algoritme og finnes ikke i noen FIPS 140-3-validert kryptografisk modul. SHA-256 er FIPS-godkjent gjennom SHA-2-familien.

Bør jeg bytte fra SHA-256 til BLAKE3?
Det kommer an på systemet. Bytt hvis du kontrollerer både produsent og konsument av hashene, ytelse er en reell, målt flaskehals, og du ikke har FIPS- eller andre regulatoriske krav. Behold SHA-256 hvis du har eksterne kontrakter, blokkjede-interoperabilitet eller compliance-krav som forutsetter en NIST-godkjent algoritme.

Kan BLAKE3 brukes til passordhashing?
Nei – og det samme gjelder rå SHA-256. Begge er designet for å være raske, som gjør dem uegnet til passordlagring fordi det gjør brute force-angrep enklere for en angriper. Bruk i stedet Argon2, bcrypt eller scrypt, som er bevisst trege og minnekrevende.

Hva skjer med SHA-256 og BLAKE3 når kvantedatamaskiner blir kraftigere?
Begge påvirkes likt av Grovers algoritme, som i teorien halverer den effektive sikkerhetsmarginen mot preimage-søk. For en 256-bit hash betyr det en teoretisk reduksjon til rundt 128-bit sikkerhet under et stort kvanteangrep – identisk for begge algoritmer, og ikke et argument for å velge den ene fremfor den andre.

Støtter Git BLAKE3 eller SHA-256?
Git bruker historisk SHA-1, men prosjektet vedtok i 2018 å gå over til SHA-256 som etterfølger. Ifølge Gits offisielle dokumentasjon er SHA-256-repositorier fortsatt eksperimentelle og frarådes på offentlige servere. BLAKE3 er ikke en del av Gits offisielle hash-overgang.

Hvilken hashfunksjon bør nye prosjekter velge i 2026?
For interne systemer uten eksterne compliance-krav er BLAKE3 ofte det tekniske førstevalget i nye prosjekter, takket være ytelse og enkel API. For alt som krysser en compliance-grense, kommuniserer med eksterne parter eller må dokumenteres overfor et tilsyn, er SHA-256 fortsatt det tryggeste standardvalget i 2026.

Hvor lang tid tar det å migrere fra SHA-256 til BLAKE3?
Det avhenger av hvor mange steder hashen er lagret og konsumert. Et lite, internt system med få konsumenter kan migreres på dager, mens et system med mange eksterne integrasjoner bør regne med en dobbelthash-periode på flere uker eller måneder for å fange opp glemte konsumenter før den gamle hash-stien fjernes helt.

Relatert dekning