Norske bedrifter som flytter backup, filsystemer og CI/CD-pipeliner til skyen støter stadig oftere på et valg utviklere ikke tenkte mye på for ti år siden: hvilken hashfunksjon skal sjekke at dataene faktisk er intakte. BLAKE3 vs BLAKE2 er blitt et konkret spørsmål for team som bygger alt fra kompilator-cacher til backup-verktøy, fordi de to algoritmene svarer forskjellig på tre ting som koster penger i praksis: hastighet, standardstatus og oppførsel på korte meldinger. Denne gjennomgangen bruker ferske benchmarks fra flere uavhengige kilder, en fullstendig spesifikasjonstabell og et regnestykke på faktisk skykostnad, slik at du kan velge riktig algoritme for din arbeidsmengde i 2026.

Spørsmålet er mer enn akademisk. Norske aktører innen skylagring, backup-tjenester og finans håndterer stadig større datamengder etter hvert som AI-arbeidslaster og loggvolumer vokser, og valget mellom BLAKE2 og BLAKE3 påvirker både CPU-regningen i skyen og hvilke compliance-krav systemet kan møte. Vi går gjennom design, ytelse, sikkerhet, standardstatus, kostnad og konkrete migreringssteg, med kildehenvisninger til hvert eneste tall.

Hva er BLAKE2 og BLAKE3

BLAKE2 kom i 2012 som en direkte etterfølger til BLAKE, en av finalistene i NISTs SHA-3-konkurranse. Algoritmen ble formalisert som RFC 7693 i november 2015, en informasjonell IETF-standard skrevet av Markku-Juhani O. Saarinen, og finnes i to hovedvarianter: BLAKE2b (optimalisert for 64-bits prosessorer, opptil 64 byte digest) og BLAKE2s (optimalisert for 8- til 32-bits systemer, opptil 32 byte digest). Konstruksjonen er sekvensiell og bygger på en HAIFA-lignende komprimeringsfunksjon, samme grunnidé som forgjengeren BLAKE.

BLAKE3 kom i januar 2020 fra et team bestående av blant andre Jack O’Connor, Jean-Philippe Aumasson, Samuel Neves og Zooko Wilcox-O’Hearn (kjent fra Zcash). I stedet for å videreutvikle BLAKE2s sekvensielle design, bygget teamet BLAKE3 rundt et Merkle-tre. Det gjør algoritmen naturlig parallelliserbar på tvers av kjerner og SIMD-bredde, noe BLAKE2 aldri var designet for. BLAKE3 har kun én variant, gir 256-bits digest som standard, men kan utvides til en vilkårlig lengde via XOF-modus (extendable output function). Algoritmen er per 2026 fortsatt kun beskrevet i et IETF-utkast (draft-aumasson-blake3-00, publisert juli 2024) og har ikke blitt en ferdig RFC, i motsetning til BLAKE2.

Begge algoritmene er gratis å bruke uten lisenskostnad. Den offisielle referansekoden for BLAKE2 er tilgjengelig under CC0, OpenSSL-lisensen og Apache 2.0, mens det offisielle BLAKE3-repoet på GitHub er lagt ut under CC0 1.0 med Apache 2.0 (inkludert en variant med LLVM-unntak) som alternativ. Det er altså ingen lisenskostnad som skiller de to, forskjellen ligger i ytelse, modenhet og standardstatus, noe vi går gjennom i detalj lenger ned. Vi har tidligere sett nærmere på beslektede sammenligninger som BLAKE3 mot SHA-256 og BLAKE3 mot SHA-3, men BLAKE3 vs BLAKE2 er et annet spørsmål: her konkurrerer BLAKE3 mot sin egen forgjenger, ikke mot en NIST-standard.

Navnevalget er også litt misvisende for nykommere. Mange antar at BLAKE3 rett og slett er versjon tre av samme algoritme, men i praksis er det en helt ny konstruksjon som deler filosofi, ikke kildekode, med forgjengeren. Zooko Wilcox-O’Hearns involvering er ikke tilfeldig: Zcash-prosjektet trengte en hashfunksjon som kunne skaleres effektivt i krevende beregningsmiljøer, og designmålene fra den verdenen (parallellisering, forutsigbar ytelse, enkel verifisering av delvise data) preger BLAKE3 tydelig. BLAKE2 ble på sin side designet med et bredere mål: å være en rask, sikker og enkel erstatning for MD5 og SHA-1 i alt fra filintegritet til nøkkelutledning, uten å kreve spesiell maskinvare.

Spesifikasjonstabell: BLAKE2b, BLAKE2s og BLAKE3

Tabellen under samler de tekniske spesifikasjonene side om side. Legg spesielt merke til raden om konstruksjon: det er hovedgrunnen til at BLAKE3 skalerer så mye bedre på moderne maskinvare med mange kjerner og bred SIMD-støtte.

EgenskapBLAKE2bBLAKE2sBLAKE3
Utgivelsesår201220122020
Standardisert iRFC 7693 (2015)RFC 7693 (2015)IETF-utkast (juli 2024, ikke ferdig RFC)
Standard digest-størrelse64 byte (512 bit)32 byte (256 bit)32 byte (256 bit)
Maks digest-størrelse64 byte32 byteUbegrenset (XOF-modus)
Intern ordstørrelse64 bit32 bit32 bit
KonstruksjonSekvensiell (HAIFA-lignende)Sekvensiell (HAIFA-lignende)Merkle-tre, 1024-byte blokker
Rundeantall per komprimering12107
Naturlig parallelliseringNeiNeiJa (tre-struktur og SIMD)
Multitråd-skaleringIkke innebygdIkke innebygdInnebygd via tre-traversering
Nøkkelt hashing (MAC)Ja, innebygdJa, innebygdJa, innebygd (keyed mode)
Strømming/inkrementell verifiseringBegrensetBegrensetJa, via Bao-protokollen
Typisk maskinvaremål64-bits servere/desktop32-bits/innbygde systemerModerne x86-64 med AVX2/AVX-512, ARM med NEON
Lisens (offisiell kode)CC0 / OpenSSL / Apache 2.0CC0 / OpenSSL / Apache 2.0CC0 1.0 / Apache 2.0
NIST/FIPS-status (2026)Ikke FIPS-godkjentIkke FIPS-godkjentIkke FIPS-godkjent, tidligst vurdert 2028

Den lave rundeantallet i BLAKE3 (7 mot 10-12 i BLAKE2) er ikke et sikkerhetskompromiss alene, det er kompensert av at Merkle-tre-strukturen gir et større angrepsflate-utfordring for en angriper: hver blokk hashes uavhengig før resultatene kombineres opp gjennom treet. Sikkerhetsmarginen diskuteres nærmere i eget avsnitt lenger ned.

Bibliotekstøtte og økosystem

Modenhet handler ikke bare om standardstatus, den handler også om hvor lett algoritmen er å bruke fra det programmeringsspråket teamet ditt faktisk skriver. Her har BLAKE2 et klart forsprang fordi den har eksistert lenger. Python har hatt blake2b og blake2s innebygd i standardbiblioteket hashlib siden versjon 3.6, uten behov for eksterne pakker. Go-økosystemet har en offisiell implementasjon i golang.org/x/crypto/blake2b, og OpenSSL har støttet BLAKE2b siden versjon 1.1.0, noe som gjør algoritmen tilgjengelig fra kommandolinjen på nesten enhver Linux-server uten ekstra installasjon.

BLAKE3 krever i de fleste tilfeller et eksternt bibliotek, siden algoritmen er for ny til å ha blitt tatt inn i standardbibliotekene til Python, Go eller OpenSSL. Det offisielle Rust-crate og C-biblioteket dekker de fleste bruksområder, og det finnes offisielle og velvedlikeholdte bindinger for Python (via pip), Node.js og WebAssembly, samt en rekke tredjeparts-porteringer til andre språk. For team som allerede har en moderne byggepipeline med pakkehåndtering (cargo, pip, npm), er dette sjelden et reelt hinder, men for eldre systemer der man er avhengig av det som ligger i OS-pakkebrønnen fra før, kan mangelen på innebygd støtte bety ekstra arbeid med avhengighetshåndtering og sikkerhetsoppdateringer av en tredjepartskomponent.

Ytelsesbenchmarks: hva sier tallene fra flere kilder

Ingen enkelt benchmark forteller hele historien, fordi resultatet avhenger sterkt av meldingsstørrelse, prosessorarkitektur og hvilke SIMD-instruksjoner som er tilgjengelige. Vi har derfor samlet tall fra seks uavhengige målinger publisert mellom 2020 og 2026.

KildeMaskinvare/oppsettResultatFaktor
kdave.github.io (Btrfs-mikrobenchmark)4 KiB blokker, AVX2, 10 mill. iterasjonerBLAKE3: 11 126 sykluser/iterasjon. BLAKE2b: 12 700 sykluser/iterasjon~13-14 % raskere
cryptopp-modern.comAVX2-instruksjoner, 8 parallelle chunksBLAKE3: ~2 600 MiB/s mot BLAKE2b SSE4.1-basislinje3,15x raskere
cryptopp-modern.comAVX-512, 16 parallelle chunksBLAKE3: ~4 500 MiB/s mot samme basislinje5,5x raskere
BLAKE3-designpapiretIntel Cascade Lake-SP, enkelttrådToppgjennomstrømning mot BLAKE2b4x raskere (8x mot SHA-512, 12x mot SHA-256)
IETF-utkastet (juli 2024)16 KiB meldinger, enkelttrådBLAKE3 mot BLAKE2, samme betingelser~5x raskere (over 20x med flere tråder på store data)
kerkour.comAMD EPYC 4245P (Zen 5), 1 MB inputBLAKE3: 13 196 MB/s. SHA-256: 2 373 MB/s. SHA3-256: 686 MB/s5,6x raskere enn SHA-256
Hacker News-mikrobenchmark (2024)Kort melding, ukjent CPUBLAKE2s: 231 ns/iterasjon. BLAKE3: 355 ns/iterasjonBLAKE2s vant her

Hvilken SIMD-bredde prosessoren din faktisk støtter, avgjør mye av dette bildet. Eldre serverprosessorer og mange budsjett-instanser i skyen mangler AVX-512, og faller da tilbake til AVX2 eller SSE4.1, der BLAKE3s forsprang krymper fra 5,5x til 3,15x eller 2,2x ifølge cryptopp-modern-tallene. ARM-baserte instanser, som AWS Graviton, bruker NEON-instruksjoner i stedet for AVX, og forspranget der ligger nærmere BLAKE3-designpapirets ARM1176-tall enn de Intel/AMD-spesifikke resultatene. Sjekk derfor alltid hvilken prosessorarkitektur og instruksjonssett produksjonsmiljøet ditt faktisk kjører på før du legger generelle benchmark-tall til grunn for en migreringsbeslutning.

Mønsteret er konsistent på tvers av kildene: jo større datamengden er, og jo bredere SIMD-instruksjonene er, desto større er BLAKE3s forsprang. På Btrfs-testens 4 KiB-blokker er gevinsten beskjeden (13-14 %), mens den vokser til 3-5x på 1 MB-data og videre til over 20x på store filer med flere tråder tilgjengelig, ifølge IETF-utkastet. Samtidig viser Hacker News-mikrobenchmarken fra 2024 et motsatt resultat på svært korte meldinger, noe vi dekker i neste avsnitt.

Kerkour-benchmarken på AMD EPYC 4245P (Zen 5) er spesielt nyttig fordi den viser hvordan gjennomstrømningen endrer seg med meldingsstørrelsen for samme algoritme på samme maskinvare, ikke bare et enkelt toppresultat. BLAKE3 leverer 505 MB/s ved 64-byte input, hopper til 952 MB/s ved 1 kB, og når 10 994 MB/s allerede ved 16 kB før den flater ut på 12 752 MB/s ved 64 kB og 13 196 MB/s ved 1 MB. Denne kurven bekrefter tre-strukturens natur: ytelsen stiger brått når meldingen blir stor nok til å fylle flere parallelle chunks, men gir liten gevinst under den terskelen. Det er nettopp dette som forklarer hvorfor BLAKE2s fortsatt kan konkurrere, og noen ganger vinne, på svært korte meldinger.

Når BLAKE2 faktisk vinner: korte meldinger

Det mest overraskende funnet i research til denne artikkelen er ikke at BLAKE3 er raskere, det er at BLAKE3 taper på svært korte inndata. En 2025-analyse fra utvikleren bak jszym.com testet hashing av enkeltord på under 1 kB og fant at BLAKE3 ble slått av omtrent halvparten av de testede hashfunksjonene, inkludert BLAKE2s. Konklusjonen i den artikkelen var direkte: for den spesifikke arbeidsmengden (hashing av korte engelske ord) var BLAKE2s det bedre valget.

Årsaken ligger i selve designet. BLAKE3s Merkle-tre-struktur og 1024-byte chunk-størrelse gir enorm gevinst når data kan deles opp og prosesseres parallelt, men den samme strukturen tilfører litt overhead når meldingen er kortere enn én chunk. BLAKE2s, med sin enklere sekvensielle konstruksjon og 32-bits optimalisering, har ingen slik oppstartskostnad. En 2025 masteroppgave fra Universitetet i Turku som testet MAC-ytelse (keyed hashing) på en x86-bærbar PC, fant riktignok at BLAKE3 nådde 2,5 millioner MAC-operasjoner i sekundet (640 ns per operasjon) mot BLAKE2s’ 2,0 millioner (800 ns), og at BLAKE3 viste lav følsomhet for meldingsstørrelse, ned til sin egen 64-byte blokkstørrelse. De to funnene motsier ikke hverandre, de viser bare at “kort melding” betyr ulike ting i ulike tester: MAC-testen brukte 64-byte blokker der BLAKE3 fortsatt vant, mens jszym-testen brukte enda kortere ord der BLAKE2s tok ledelsen.

For utviklere er praksisregelen enkel: hvis arbeidsmengden består av mange små, uavhengige meldinger (tokens, korte identifikatorer, enkeltord i et leksikon), test begge algoritmer på faktisk data før du bestemmer deg. Anta ikke automatisk at BLAKE3 vinner bare fordi navnet er nyere.

Sikkerhet og kollisjonsmotstand

Begge algoritmene er designet for 128-bits sikkerhet mot kollisjonsangrep (fødselsdagsgrense) med 256-bits digest, og ingen praktiske kollisjons- eller preimage-angrep er publisert mot verken BLAKE2 eller BLAKE3 per 2026. BLAKE2 har hatt over ti år med offentlig kryptanalyse siden RFC 7693 kom i 2015, inkludert grundig gjennomgang under selve SHA-3-konkurransen der forgjengeren BLAKE var finalist. Det gir algoritmen en lang merittliste uten alvorlige funn.

BLAKE3 er nyere, og den offentlige kryptanalysen har naturlig nok hatt kortere tid på seg. Designteamet argumenterer for at den reduserte rundeantallet (7 mot BLAKE2s 10-12) er trygt fordi treet-strukturen endrer angrepsmodellen: en angriper må bryte komprimeringsfunksjonen for hver blokk uavhengig, og selve tre-kombinasjonen legger til et lag beskyttelse som BLAKE2s sekvensielle kjede ikke har. Ingen offentliggjorte svakheter har rokket ved denne påstanden så langt, men det er verdt å merke seg at BLAKE3 ennå ikke har gjennomgått en formell NIST-standardiseringsprosess med den tilhørende flerårige offentlige kryptanalysen som SHA-3 fikk. Det er nettopp dette som ligger bak neste avsnitts diskusjon om standardstatus.

Et praktisk poeng som ofte glemmes: sikkerhetsnivå og standardgodkjenning er to forskjellige ting. En algoritme kan være kryptografisk sterk uten å være formelt godkjent av et standardiseringsorgan, og motsatt kan en godkjent algoritme fortsatt bli svekket av implementasjonsfeil. For BLAKE2 og BLAKE3 handler valget derfor sjelden om hvilken som er “tryggest” i ren matematisk forstand, siden begge har solide sikkerhetsmarginer, men om hvilken standardstatus systemet ditt faktisk krever.

Standardisering: RFC mot utkast, og hvorfor FIPS-status betyr noe for norske virksomheter

Dette er trolig den viktigste forskjellen for virksomheter i regulerte bransjer. BLAKE2 er publisert som RFC 7693, en informasjonell IETF-standard fra november 2015. BLAKE3 finnes foreløpig kun som et IETF-utkast, draft-aumasson-blake3-00, publisert i juli 2024, og har ikke blitt løftet til en ferdig RFC. Ingen av algoritmene er godkjent av NIST som en offisiell FIPS-hashfunksjon. De offisielle FIPS-godkjente hashstandardene forblir SHA-2 (FIPS 180-4) og SHA-3/Keccak (FIPS 202), som vi har sammenlignet i detalj i SHA-256 mot SHA-3.

For BLAKE3 spesifikt har rapporter i 2026 pekt på at NIST tidligst vil vurdere algoritmen for FIPS 140-3-validering i 2028, noe som i praksis betyr at verken BLAKE2 eller BLAKE3 er et lovlig alternativ i systemer som må følge PCI-DSS, NIS2-direktivet eller norske krav til offentlig sektor der SHA-2/SHA-3 er et eksplisitt krav. Dette er en direkte relevant begrensning for norske banker, offentlige etater og andre virksomheter underlagt Digitaliseringsdirektoratets og Nkoms sikkerhetskrav: BLAKE2 og BLAKE3 kan brukes internt for integritetssjekk og deduplisering, men bør ikke erstatte SHA-256 eller SHA-3 der compliance krever en FIPS-godkjent algoritme.

Praktisk konsekvens for et norsk utviklerteam: skill mellom “compliance-hash” og “intern integritets-hash” i arkitekturen fra dag én. En bank kan trygt bruke BLAKE3 til å generere cache-nøkler i en intern CI-pipeline eller til å deduplisere loggdata i et internt datavarehus, samtidig som all kryptografisk signering og revisjonsspor som er underlagt NIS2 eller Finanstilsynets krav fortsatt bruker SHA-256 eller SHA-3. Å blande de to rollene i samme kodesti er den vanligste feilen team gjør når de innfører en ny, rask hashfunksjon uten å sjekke hvor den kryptografiske grensen for compliance faktisk går.

Kostnad i skala: hva koster hashing faktisk i skyen

Verken BLAKE2 eller BLAKE3 koster noe i lisensavgift, begge er tilgjengelige under CC0/Apache 2.0. Den reelle kostnaden ligger i regnekraften du betaler for i skyen når du hasher store datamengder, for eksempel i en backup-tjeneste eller et deduplisering-lag. Ved å bruke de sourcede gjennomstrømningstallene fra cryptopp-modern.com (BLAKE2b SSE4.1-basislinje på ~820 MiB/s, BLAKE3 AVX2 på 2 600 MiB/s og BLAKE3 AVX-512 på 4 500 MiB/s) kan vi beregne faktisk instanskostnad på en AWS c7i.2xlarge (8 vCPU) i eu-north-1 (Stockholm), som per 2026 koster 0,3822 USD/time på on-demand.

ScenarioBLAKE2b (SSE4.1, ~820 MiB/s)BLAKE3 AVX2 (2 600 MiB/s)BLAKE3 AVX-512 (4 500 MiB/s)
Tid per TiB hashet~21,3 minutter~6,7 minutter~3,9 minutter
Instanskostnad per TiB (c7i.2xlarge, eu-north-1)~$0,14~$0,04~$0,02
Tid ved 100 TiB/dag~35,5 timer~11,2 timer~6,5 timer
Beregnet månedskostnad ved 100 TiB/dag~$407~$128~$74
Lisenskostnad$0 (CC0/Apache 2.0)$0 (CC0/Apache 2.0)$0 (CC0/Apache 2.0)

Tallene er beregnet ut fra de sourcede gjennomstrømningstallene og offentlig AWS-prising, ikke hentet direkte fra en enkelt kilde. De illustrerer likevel poenget godt: for en backup-tjeneste eller et storage-selskap som hasher hundrevis av terabyte daglig, kan bytte fra BLAKE2b til BLAKE3 med AVX-512-støtte redusere regnekraftbehovet for selve hashingen med rundt 80 %. For mindre arbeidsmengder, som å verifisere enkeltfiler eller korte API-nøkler, er forskjellen i praksis usynlig for sluttbrukeren, og valget bør heller styres av standardstatus og økosystemstøtte enn av rå ytelse.

Regnestykket over forutsetter x86-64-maskinvare med AVX2/AVX-512, men mange norske edge- og IoT-installasjoner kjører fortsatt på ARM. Ifølge BLAKE3-designpapiret er forspranget mindre på svakere maskinvare: på en 32-bits ARM1176-kjerne er BLAKE3 kun 1,3x raskere enn SHA-256 og 3x raskere enn BLAKE2b/SHA-512, en tydelig lavere faktor enn de 4-5,5x man ser på moderne serverbrikker med bred SIMD-støtte. For team som driver sensorer, industri-PLS-er eller annen innbygd maskinvare i Norge, betyr det at gevinsten ved å bytte til BLAKE3 er mindre dramatisk, og at BLAKE2s’ lavere minnefotavtrykk fortsatt kan være avgjørende på svært begrenset maskinvare.

Fem virkelige eksempler på bruk

Benchmarks og spesifikasjonstabeller forteller bare halve historien. Det som til slutt avgjør om en hashfunksjon er moden nok til å stole på, er om den allerede kjører i produksjon i systemer der en feil eller ytelsesregresjon ville blitt oppdaget raskt. Under følger fem konkrete, navngitte eksempler på hvor BLAKE2 og BLAKE3 faktisk brukes i dag, hentet fra offisiell dokumentasjon og åpne diskusjoner i de respektive prosjektene.

1. WireGuard-VPN bruker BLAKE2s i selve håndtrykket

WireGuards offisielle protokollbeskrivelse lister BLAKE2s som en av kjerneprimitivene, brukt til å hashe håndtrykk-transkripsjonen, generere MAC-verdier for cookie/DoS-mekanismen (mac1/mac2), og som underliggende hash i HMAC for nøkkelutledning via HKDF. Protokollidentifikatoren Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s viser dette eksplisitt. Dette er et av de mest utbredte eksemplene på BLAKE2 i produksjon, siden WireGuard i dag er innebygd i Linux-kjernen og brukes av store VPN-leverandører. Valget falt på BLAKE2s nettopp fordi håndtrykk-meldinger er korte, akkurat den typen arbeidsmengde der BLAKE2 historisk har hatt et fortrinn, og designerne av protokollen prioriterte lav og forutsigbar latens over rå gjennomstrømning på store datamengder.

2. Argon2 bygger sin komprimeringsfunksjon på BLAKE2b

RFC 9106, spesifikasjonen for passordhashfunksjonen Argon2, definerer eksplisitt BLAKE2b som den variable-lengde hashfunksjonen H, og selve komprimeringsfunksjonen G i Argon2 er bygget på BLAKE2bs interne rundefunksjon. Med andre ord: hver gang et nettsted bruker Argon2id til å hashe passord, kjører BLAKE2b under panseret. Vi har dekket dette temaet grundigere i Argon2 mot bcrypt og PBKDF2.

3. Btrfs-filsystemet støtter BLAKE2b og evaluerer BLAKE3

Linux-filsystemet Btrfs har støttet BLAKE2b som sjekksum-algoritme siden kjerne 5.5. Vedlikeholderen bak filsystemet publiserte i 2026 en mikrobenchmark som sammenlignet BLAKE2b og BLAKE3 direkte på 4 KiB-blokker, nøyaktig den blokkstørrelsen Btrfs bruker internt, for å vurdere om BLAKE3 bør bli et fremtidig sjekksum-alternativ.

4. Kompilator-cachen ccache diskuterer å bytte til BLAKE3

En åpen GitHub-diskusjon i ccache-prosjektet, “Replace BLAKE2 with BLAKE3?”, har vært aktiv siden 2020 og blir fortsatt oppdatert gjennom 2025 med nye benchmarks. Ccache bruker en hashfunksjon til å generere cache-nøkler for kompilerte objektfiler, og siden dette skjer på hver eneste kompilering i en CI-pipeline, gir selv en liten hastighetsgevinst per fil en målbar effekt på total byggetid i store kodebaser.

5. b3sum og filintegritet i store datasett

Det offisielle BLAKE3-teamet distribuerer kommandolinjeverktøyet b3sum, med ferdigbygde binærfiler for Linux, Windows og macOS, spesifikt designet for rask filintegritetssjekk. Verktøyet brukes i praksis av utviklere som må verifisere store datasett, arkiver eller nedlastede filer raskere enn det tradisjonelle sha256sum tillater, uten å måtte skrive egen SIMD-optimalisert kode. For team som allerede skripter opp CI-jobber med sha256sum eller md5sum, er overgangen til b3sum i stor grad et rent bytte av kommandonavn, siden output-formatet følger samme konvensjon med hash etterfulgt av filnavn.

Slik tester du selv: kommandoer og verktøy

Generelle benchmarks er et godt utgangspunkt, men den eneste måten å vite sikkert hvilken algoritme som passer din arbeidsmengde, er å teste på egen maskinvare og egne datastørrelser. Begge algoritmer kan testes direkte fra kommandolinjen uten å skrive kode. OpenSSL har en innebygd speed-kommando som måler gjennomstrømning for flere hashfunksjoner samtidig, inkludert blake2b512, og gir tall for ulike blokkstørrelser i én operasjon. Det offisielle b3sum-verktøyet har på sin side et innebygd flagg for å måle egen gjennomstrømning på lokal maskinvare.

# Mål BLAKE2b-gjennomstrømning med OpenSSL på ulike blokkstørrelser
openssl speed -evp blake2b512

# Mål BLAKE3-gjennomstrømning med offisielt b3sum-verktøy
b3sum --benchmark

# Sammenlign faktisk tid på en representativ fil fra din egen arbeidsmengde
time sha256sum stordatafil.bin
time b3sum stordatafil.bin
time openssl dgst -blake2b512 stordatafil.bin

Kjør disse testene på representative filstørrelser fra din egen arbeidsmengde, ikke bare på én stor testfil. Som vist i avsnittet om korte meldinger, kan resultatet snu fullstendig avhengig av om du hasher 64-byte identifikatorer eller 100 MB-arkiver. Test også på den faktiske instanstypen du planlegger å kjøre i produksjon, siden AVX-512-støtte varierer mellom skyleverandørenes instanstyper, og en benchmark kjørt på en bærbar PC med annen SIMD-bredde kan gi et misvisende bilde av ytelsen i skyen.

Hva ekspertene og kildene sier

“On Intel Cascade Lake-SP, peak single-threaded throughput is 4× that of BLAKE2b, 8× that of SHA-512, and 12× that of SHA-256, and it can scale further using multiple threads.”

BLAKE3-forfatterne, kryptografiforskere bak designpapiret (kilde)

Dette tallet, 4x raskere enn BLAKE2b på enkelttråd, stemmer godt overens med de uavhengige cryptopp-modern-benchmarkene lenger opp i artikkelen, og er trolig den mest siterte enkeltmålingen i BLAKE3-diskusjonen siden algoritmen ble lansert i 2020.

“BLAKE3’s authors published a benchmark on an Intel Cascade Lake-SP 8275CL processor showing it to be 5x faster than BLAKE2 and 15x faster than SHA3-256.”

InfoQ, teknologinyhetspublikasjon (kilde)

InfoQs dekning fra lanseringen i januar 2020 satte tonen for hvordan BLAKE3 ble mottatt i utviklermiljøet: som en algoritme med imponerende rå ytelse, men uten den samme institusjonelle tyngden som SHA-3 hadde etter NIST-konkurransen.

“Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2.”

BLAKE3-teamet, offisiell GitHub-README (kilde)

Denne påstanden fra selve prosjektsiden er nødvendigvis partisk, men underbygges likevel av de uavhengige benchmarkene fra kdave.github.io, cryptopp-modern.com og kerkour.com som er gjennomgått tidligere i artikkelen. Det er verdt å legge merke til at ingen av de tre sitatene kommer fra en nøytral tredjepart uten tilknytning til BLAKE3-prosjektet, siden både designpapiret og GitHub-READMEen er skrevet av teamet selv. InfoQs dekning er den nærmeste vi kommer en uavhengig kilde blant de tre, men den bygger i praksis på de samme opprinnelige benchmark-tallene fra forfatterne. Dette er normalt for et relativt nytt kryptografisk prosjekt, og det er nettopp derfor de uavhengige mikrobenchmarkene fra Btrfs-vedlikeholderen og masteroppgaven fra Universitetet i Turku er så verdifulle: de bekrefter det samme grunnleggende bildet fra kilder uten økonomisk eller faglig interesse i utfallet.

Bruksområder: når bør du velge hva

Basert på benchmarkene, kostnadsregnestykket og de virkelige eksemplene over kan vi sette opp en praktisk sjekkliste. Den er ikke absolutt, men den dekker de vanligste beslutningspunktene norske utviklerteam møter når de skal velge hashfunksjon for et nytt system i 2026.

  • Backup og deduplisering med store datamengder: BLAKE3 er riktig valg. Kostnadstabellen over viser en reduksjon i regnekraftbehov på opptil 80 % ved AVX-512-støtte sammenlignet med BLAKE2b.
  • VPN- og håndtrykk-protokoller med korte, hyppige meldinger: BLAKE2s er godt utprøvd her, med WireGuard som referanseimplementasjon, og har ingen tre-struktur-overhead på korte data.
  • Passordhashing og nøkkelutledning: Bruk Argon2id, ikke BLAKE2 eller BLAKE3 direkte. Argon2 bruker allerede BLAKE2b internt og er selv designet og herdet mot GPU/ASIC-angrep på en måte rene hashfunksjoner ikke er.
  • CI/CD og kompilator-cacher: BLAKE3 gir målbar gevinst i store kodebaser med mange filer per bygg, slik ccache-diskusjonen illustrerer.
  • Regulerte sektorer (bank, offentlig sektor, kritisk infrastruktur i Norge): Verken BLAKE2 eller BLAKE3 er FIPS-godkjent. Bruk SHA-256 eller SHA-3 der compliance krever det, og reserver BLAKE-familien til interne, ikke-regulerte systemer.
  • Innbygde systemer med begrenset minne (IoT, mikrokontrollere): BLAKE2s’ 32-bits optimalisering og lave minnebehov gjør den fortsatt konkurransedyktig mot BLAKE3 på denne maskinvareklassen.
  • Filsystem-sjekksummer: Følg med på Btrfs-utviklingen. BLAKE2b er allerede støttet siden kjerne 5.5, og BLAKE3 evalueres aktivt som neste steg basert på 2026-benchmarkene.

Migreringsguide: fra BLAKE2 til BLAKE3

Hvis du har konkludert med at BLAKE3 passer arbeidsmengden din, er selve overgangen relativt rett frem fordi begge algoritmene støtter nøkkelt hashing (MAC) og har offisielle biblioteker for de fleste språk. Legg merke til at dette ikke er en drop-in-erstatning på binærnivå: digest-verdiene er ulike, så du må regne om alle lagrede sjekksummer. Planlegg migreringen som et flerukers prosjekt for store datasett, ikke en enkelt utrulling, siden re-hashing av eksisterende data er den mest tidkrevende delen, ikke selve kodeendringen.

  1. Kartlegg hvor BLAKE2b/BLAKE2s brukes i kodebasen, inkludert sjekksum-felt i databaser og filformater.
  2. Installer offisiell BLAKE3-binding for språket ditt (Rust-crate, Python-pakke via pip, eller C-biblioteket direkte).
  3. Skriv en kompatibilitetsperiode der begge hashverdier lagres parallelt, slik at eldre klienter fortsatt kan verifisere data under overgangen.
  4. Bytt ut lesekallene først, slik at systemet kan verifisere mot begge hashtyper.
  5. Migrer skrivekallene til å generere BLAKE3-digest for nye data.
  6. Kjør en full re-hashing-jobb i bakgrunnen for eksisterende data, gjerne med AVX2/AVX-512-optimalisert kjøring for å holde kostnaden nede, som vist i kostnadstabellen over.
  7. Fjern BLAKE2-kompatibilitetslaget når re-hashingen er fullført og verifisert.
// Eksempel: hash en fil med offisiell b3sum (kommandolinje)
b3sum stordatafil.bin

// Eksempel: hash med BLAKE2b via OpenSSL for sammenligning
openssl dgst -blake2b512 stordatafil.bin

// Eksempel: keyed hashing (MAC) med BLAKE3 i Rust
let mut hasher = blake3::Hasher::new_keyed(&key);
hasher.update(data);
let mac = hasher.finalize();

Behold alltid testvektorer fra referanseimplementasjonene under migreringen. Både BLAKE2- og BLAKE3-prosjektene publiserer offisielle testvektorer, og disse bør inngå i CI-pipelinen din for å fange opp implementasjonsfeil før de når produksjon.

Fordeler og ulemper

Oppsummert under er styrkene og svakhetene til hver algoritme slik de fremkommer av benchmarkene, standardstatusen og de virkelige eksemplene gjennomgått over. Bruk denne listen som en rask sjekk før du velger, men gå tilbake til de relevante avsnittene for tallgrunnlaget bak hvert punkt.

BLAKE2

  • Fordel: Formell IETF-standard (RFC 7693) siden 2015, med over ti års offentlig kryptanalyse.
  • Fordel: Bedre ytelse enn BLAKE3 på svært korte meldinger i flere tester.
  • Fordel: Bygget inn i kritisk infrastruktur som WireGuard og Argon2.
  • Ulempe: Sekvensiell konstruksjon skalerer ikke naturlig med flere kjerner.
  • Ulempe: Vesentlig tregere enn BLAKE3 på store datamengder, opptil 5x i flere benchmarks.
  • Ulempe: Ikke FIPS-godkjent, samme begrensning som BLAKE3.

BLAKE3

  • Fordel: Betydelig raskere på store og mellomstore datamengder, opptil 5,5x mot BLAKE2b med AVX-512.
  • Fordel: Naturlig parallelliserbar via Merkle-tre-struktur, skalerer med kjerneantall.
  • Fordel: Fleksibel XOF-modus gir ubegrenset digest-lengde.
  • Ulempe: Fortsatt kun IETF-utkast, ikke ferdig RFC per 2026.
  • Ulempe: Kan tape mot BLAKE2s på svært korte enkeltmeldinger.
  • Ulempe: Kortere historikk med offentlig kryptanalyse enn BLAKE2.
  • Ulempe: Ikke FIPS-godkjent, ifølge rapporter tidligst aktuelt i 2028.

Verdikt: hvilken bør du velge i 2026

Tallene peker i en klar retning for de fleste nye prosjekter som håndterer moderate til store datamengder: BLAKE3 vinner på ren gjennomstrømning, med en fordel som spenner fra 13-14 % på små 4 KiB-blokker til over 5x på store filer med AVX-512-støtte, og over 20x med flere tråder på store meldinger ifølge IETF-utkastet. Kostnadsberegningen over viser at dette faktisk betyr noe i kroner og øre for tjenester som hasher hundrevis av terabyte daglig.

Men BLAKE3 vs BLAKE2 er ikke et spørsmål med ett riktig svar for alle. Hvis arbeidsmengden domineres av svært korte meldinger, viser både jszym.com-analysen og Hacker News-mikrobenchmarken at BLAKE2s fortsatt kan vinne. Hvis systemet må være compliant med PCI-DSS, NIS2 eller norske offentlige sikkerhetskrav, er verken BLAKE2 eller BLAKE3 et lovlig valg der en FIPS-godkjent algoritme kreves, og du bør holde deg til SHA-256 eller SHA-3. Og hvis du allerede bruker Argon2 til passordhashing, gjør du ingenting: BLAKE2b sitter der internt uansett, og det finnes ingen grunn til å bytte ut selve KDF-en.

Den praktiske anbefalingen: velg BLAKE3 for nye systemer som hasher store datamengder og ikke er bundet av FIPS-krav, behold BLAKE2 der det allerede er dypt integrert (Argon2, WireGuard-baserte VPN-oppsett), og test alltid på egen arbeidsmengde før du migrerer en produksjonstjeneste basert på generelle benchmarks alene.

Sett i et litt lengre perspektiv er BLAKE3 vs BLAKE2 også et eksempel på et mønster som går igjen i kryptografi: en teknisk overlegen algoritme trenger tid på seg til å bygge samme grad av tillit og standardstøtte som forgjengeren. BLAKE2 brukte ti år på å bli en etablert byggekloss i WireGuard og Argon2. BLAKE3 er fem år inn i den samme reisen, med sterk vekst i verktøy som b3sum og diskusjoner i prosjekter som ccache og Btrfs, men uten den formelle RFC-statusen som ville gjort den til et opplagt valg i regulerte miljøer. Følg standardiseringsprosessen fremover, spesielt IETF-utkastet og en eventuell NIST-vurdering i 2028, før du legger BLAKE3 til grunn for noe som må vare i et tiår.

Ofte stilte spørsmål

Er BLAKE3 tryggere enn BLAKE2?

Begge er designet for 128-bits sikkerhet mot kollisjonsangrep med 256-bits digest, og ingen praktiske angrep er publisert mot noen av dem per 2026. BLAKE2 har lengre historikk med offentlig kryptanalyse siden RFC 7693 kom i 2015, mens BLAKE3 er nyere og har hatt kortere tid til gjennomgang, selv om designteamets argumenter for sikkerhetsmarginen ikke er motbevist.

Kan jeg bruke BLAKE3 i et system som krever FIPS-godkjenning?

Nei. Verken BLAKE2 eller BLAKE3 er FIPS-godkjent per 2026, og rapporter peker på at BLAKE3 tidligst kan bli vurdert for FIPS 140-3 i 2028. Bruk SHA-256 eller SHA-3 i systemer som er underlagt slike krav.

Hvorfor er BLAKE3 raskere enn BLAKE2 på store filer?

BLAKE3 bygger på en Merkle-tre-konstruksjon som deler data i 1024-byte blokker og hasher dem parallelt før resultatene kombineres. BLAKE2 er sekvensiell og kan ikke utnytte flere kjerner på samme måte, noe som gir BLAKE3 en fordel som vokser med datamengden og tilgjengelig CPU-parallellitet.

Bruker Argon2 BLAKE2 eller BLAKE3?

Argon2, spesifisert i RFC 9106, bruker BLAKE2b internt både som den variable-lengde hashfunksjonen H og som grunnlag for komprimeringsfunksjonen G. Det finnes ingen offisiell BLAKE3-variant av Argon2 per 2026.

Er BLAKE2 eller BLAKE3 raskest på korte meldinger?

Det varierer. En 2025-analyse fra jszym.com fant at BLAKE2s slo BLAKE3 på hashing av enkeltord under 1 kB, mens en masteroppgave fra Universitetet i Turku fant at BLAKE3 fortsatt vant på 64-byte MAC-operasjoner. Test begge på din faktiske arbeidsmengde før du konkluderer.

Koster det noe å bruke BLAKE2 eller BLAKE3 kommersielt?

Nei. Begge algoritmenes offisielle referanseimplementasjoner er lisensiert under CC0/public domain med Apache 2.0 som alternativ, uten royalty eller lisenskostnad, uavhengig av bruksområde.

Hvilke prosjekter bruker BLAKE2 og BLAKE3 i produksjon i dag?

BLAKE2s er en kjerneprimitiv i VPN-protokollen WireGuard, og BLAKE2b er byggesteinen i passordhashfunksjonen Argon2. BLAKE3 evalueres aktivt for sjekksummer i Btrfs-filsystemet og diskuteres som erstatning for BLAKE2 i kompilator-cachen ccache, i tillegg til å distribueres som det offisielle kommandolinjeverktøyet b3sum for filintegritet. Felles for eksemplene er at valget sjelden handler om én isolert benchmark, det handler om hvilken egenskap som betyr mest i den konkrete arbeidsmengden: WireGuard prioriterte lav latens på korte håndtrykk, Argon2 prioriterte en veldokumentert, hardnet komprimeringsfunksjon, mens Btrfs og ccache begge prioriterer rå gjennomstrømning på potensielt store datamengder.

Bør jeg migrere et eksisterende BLAKE2-system til BLAKE3 i dag?

Kun hvis arbeidsmengden din faktisk er begrenset av hashing-ytelse på moderate til store datamengder, og systemet ikke er underlagt FIPS-krav. Er BLAKE2 dypt integrert i et fungerende system som Argon2-basert passordhashing, er det ingen grunn til å bytte. Følg migreringsguiden over og behold en kompatibilitetsperiode med parallell hashing før du fjerner BLAKE2-støtten.

Er BLAKE3 tilgjengelig som standardbibliotek i Python, Go eller andre språk?

Nei, ikke ennå. BLAKE2b og BLAKE2s har vært innebygd i Pythons hashlib siden versjon 3.6 og er tilgjengelig i OpenSSL siden versjon 1.1.0, mens BLAKE3 per 2026 krever et eksternt bibliotek som det offisielle Rust-crate, en Python-pakke via pip, eller tilsvarende binding for språket du bruker. Dette påvirker ikke sikkerheten, men det betyr en ekstra avhengighet å vedlikeholde og oppdatere i produksjonssystemer.