To hashfunksjoner dominerer nå samtalen om filintegritet og ytelse: BLAKE3, den yngste medlemmen i BLAKE-familien, og SHA-3, NIST-standarden som vant en fem år lang konkurranse. Forskjellen i hastighet er ikke marginal. BLAKE3-teamet oppgir selv at algoritmen er “much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2”, og uavhengige benchmarks fra Intel-maskinvare bekrefter et gap på opptil 15 ganger i rå gjennomstrømming. Likevel velger store deler av bransjen fortsatt SHA-3, spesielt der lovkrav og protokoller styrer valget.
Valget mellom de to handler sjelden om ren matematikk. Et team som bygger et byggesystem eller en backup-tjeneste bryr seg om megabyte per sekund og skyregninger. Et team som bygger på Ethereum har ikke noe valg i det hele tatt, fordi protokollen allerede har bestemt hvilken Keccak-variant som gjelder. Og et team som leverer til offentlig sektor må forholde seg til FIPS 202 uansett hva et benchmark-diagram viser. Denne artikkelen går gjennom arkitektur, ytelsestall fra flere uavhengige kilder, sikkerhetsstatus per 2026, kostnad ved skalering i skyen, konkrete migreringssteg, og hvilken algoritme som faktisk passer til hvilket formål.
Hva er BLAKE3? Tre-struktur møter ChaCha
BLAKE3 bygger videre på BLAKE2s, som igjen henter kjernelogikken fra ChaCha-strømchifferet sitt kvart-runde-design (Add-Rotate-Xor, ofte kalt ARX). I stedet for den klassiske Merkle-Damgård-kjeden som eldre hashfunksjoner bruker, deler BLAKE3 input i blokker på 1 KiB og hasher hver blokk uavhengig med en nøklet komprimeringsfunksjon. Resultatene kobles deretter sammen i et binært Merkle-tre. Komprimeringsfunksjonen kjører bare 7 runder, mot langt flere i eldre design, men treet gir mye av sikkerhetsmarginen tilbake gjennom struktur i stedet for rå rundetall.
Tre-strukturen gjør noe eldre hashfunksjoner ikke kan: den lar CPU-en hashe flere blokker parallelt, selv på én kjerne, ved hjelp av brede SIMD-instruksjoner. Tre-modusen åpner også for strømmende verifisering. Delvis nedlastede filer kan verifiseres etter hvert som bitene kommer inn, en teknikk kjent fra Bao-prosjektet, uten at hele filen må hashes på nytt fra bunnen.
SIMD og maskinvareakselerasjon i praksis
Den offisielle Rust- og C-implementasjonen fra BLAKE3-teamet inkluderer håndoptimaliserte bakender for SSE2, SSE4.1, AVX2, AVX-512, NEON og WASM, med automatisk deteksjon av CPU-funksjoner ved kjøretid. I praksis betyr det at samme binærfil kjører optimalt uansett om den havner på en gammel bærbar eller en fersk Xeon-server, uten at utvikleren trenger å kompilere separate versjoner for hver maskinvareplattform. Effekten av dette er størst på store filer, fordi tre-strukturen deler input i mange uavhengige 1 KiB-blokker som kan fordeles utover både SIMD-baner og fysiske kjerner samtidig. På en liten fil, godt under blokkstørrelsen, forsvinner mye av fordelen, og BLAKE3 nærmer seg heller ytelsen til en enklere ARX-basert konstruksjon.
Nøklet hashing og nøkkelutledning
BLAKE3 spesifiserer eksplisitte flagg for ulike bruksmoduser: vanlig hashing, nøklet hashing og nøkkelutledning (KDF) er alle adskilt i designet, ikke tilføyd i etterkant. Det reduserer risikoen for at en utvikler ved et uhell bruker samme nøkkel til to ulike formål, en feilkilde som har rammet mindre gjennomtenkte konstruksjoner tidligere. Nøkkelutledningsmodusen gjør at BLAKE3 kan brukes direkte som en KDF uten et separat bibliotek som HKDF, noe som forenkler avhengighetstreet i mindre prosjekter. Samtidig betyr domeneseparasjonen i tre-flaggene at interne node-hasher i Merkle-treet aldri kan forveksles med selve sluttresultatet, selv om en angriper har full kontroll over deler av input.
Hva er SHA-3 (Keccak)? Svampen forklart
SHA-3 er ikke bygget som en kjede av blokker, men som en svamp. Algoritmen holder en intern tilstand på 1600 bit, delt i en “rate” (r) og en “capacity” (c). For SHA3-256 er raten 1088 bit og kapasiteten 512 bit, og kapasiteten er direkte knyttet til hvor mye sikkerhetsmargin funksjonen har. Meldingsblokker XOR-es inn i tilstanden (absorpsjon), en permutasjon kalt Keccak-f[1600] kjøres 24 runder, og til slutt leses output ut i biter av samme størrelse som raten (squeeze). Selve permutasjonen jobber på et 5×5-array av 64-bits ord og går gjennom fem trinn per runde: theta, rho, pi, chi og iota.
Et poeng bransjen ofte trekker frem: Keccaks svampkonstruksjon er matematisk uavhengig av SHA-2s design. Skulle det noen gang dukke opp et strukturelt angrep mot SHA-2-familien, påvirker det ikke SHA-3, fordi de to bygger på helt forskjellige matematiske prinsipper. Det er selve grunnen til at NIST ønsket en ny familie ved siden av SHA-2, ikke bare en oppdatering av den.
FIPS 202: fra konkurranse til standard
NIST godkjente konstruksjonen i FIPS 202 i august 2015, etter at Keccak vant NISTs offentlige hash-konkurranse, en prosess som startet i 2007 og varte i nesten fem år før en vinner ble kåret i 2012. Standarden definerer fire faste hash-lengder (SHA3-224, SHA3-256, SHA3-384, SHA3-512) og to funksjoner med variabel utlengde, SHAKE128 og SHAKE256, som gjør at utviklere kan trekke ut akkurat så mange bit output som en gitt protokoll krever. Den lange, offentlige prosessen er selve grunnlaget for tilliten SHA-3 nyter i dag. Hver runde av konkurransen involverte hundrevis av kryptografer som aktivt forsøkte å bryte kandidatalgoritmene, og Keccak overlevde alle forsøkene som var alvorlige nok til å diskvalifisere en finalist.
Ulempen er at svampdesignet er tyngre å kjøre i programvare enn en ren ARX-kjede. Keccak-f[1600] er bit-slicet og 64-bit-orientert, og godt optimaliserte implementasjoner støtter seg på 64-bits heltallsoperasjoner og SIMD (AVX2, AVX-512VL), men mangler den native tre-parallelliteten som BLAKE3 er bygget rundt fra dag én. Det betyr i praksis at et team som ønsker maksimal ytelse fra SHA-3 må investere i maskinvarespesifikk optimalisering, mens BLAKE3 leverer mye av gevinsten automatisk gjennom kjøretidsdeteksjon.
Spesifikasjoner side om side
Tabellen under stiller opp de tekniske egenskapene direkte mot hverandre, hentet fra BLAKE3s offisielle dokumentasjon og NISTs FIPS 202-standard. Legg spesielt merke til radene om parallellisering og strømmende verifisering, siden det er nettopp disse strukturelle forskjellene, ikke selve rundetallet, som forklarer mesteparten av ytelsesgapet lenger ned i artikkelen.
| Egenskap | BLAKE3 | SHA-3 (SHA3-256) |
|---|---|---|
| Konstruksjonstype | Merkle-tre over ARX-kjerne (ChaCha-basert) | Svamp (sponge) over Keccak-f[1600] |
| Runder i kjernefunksjon | 7 runder per komprimering | 24 runder permutasjon |
| Intern tilstand | 256-bit kjedeverdi, blokker på 1 KiB | 1600-bit tilstand (rate 1088 + capacity 512) |
| Standard output | 256-bit, med XOF for vilkårlig lengde | 224/256/384/512-bit faste, pluss SHAKE128/256 XOF |
| Kollisjonssikkerhet | ~128-bit | ~128-bit (SHA3-256) |
| Parallellisering | Nativ, via tre-struktur og SIMD | Begrenset, sekvensiell svamp |
| SIMD-bakender | SSE2, SSE4.1, AVX2, AVX-512, NEON, WASM | AVX2, AVX-512VL (bit-slicing) |
| Sykluser per byte (typisk x86-64) | Under 1 cpb med AVX-512 på store filer | 6,4 cpb (AVX-512VL) til 12,6 cpb (referanse) |
| NIST/FIPS-standardisert | Nei | Ja, FIPS 202 (august 2015) |
| Nøklet hashing / KDF | Innebygd i spesifikasjonen | Via HMAC eller SHAKE, ikke nativt i samme forstand |
| Strømmende verifisering | Ja, Bao-stil inkrementell sjekk | Nei, krever full ny hashing |
| Kjente praktiske angrep (2026) | Ingen på fullversjonen | Ingen på full 24-runders Keccak-f[1600] |
| Typisk bruksområde | Filintegritet, byggesystemer, pakkeregistre | Blokkjedeadresser (Keccak-256), myndighetssamsvar |
Hastighet i praksis: benchmarks fra tre uavhengige kilder
Påstander om hastighet er lette å komme med og vanskelige å etterprøve, så tallene under er hentet fra tre atskilte miljøer: en uavhengig Go-implementasjon med AVX-støtte, BLAKE3-teamets egne offisielle målinger, og Keccak-teamets og OpenSSLs referansetall for SHA3-256. Ingen av tallene er hentet fra markedsføringsmateriell. Go-implementasjonen er et åpent kildekode-bibliotek med offentlig tilgjengelige benchmark-skript hvem som helst kan kjøre på egen maskinvare, mens Keccak- og OpenSSL-tallene er akademiske referanseverdier som har stått uendret gjennom flere år med gjennomgang.
| Kilde | Algoritme | Resultat | Maskinvare |
|---|---|---|---|
| Go-implementasjon (lukechampine), AVX-512 | BLAKE3 | 4034 MB/s på 64 KiB-blokker | x86-64 med AVX-512 |
| Go-implementasjon (lukechampine), AVX2 | BLAKE3 | 2105 MB/s på 64 KiB-blokker | x86-64 med AVX2 |
| 2026-analyse, LLVM-optimalisert | BLAKE3 vs. SHA-256 | Opptil 27x raskere på 100 MB input | Intel Xeon W, AVX-512 |
| BLAKE3-teamets offisielle måling | BLAKE3 vs. SHA3-256 | 15x raskere enn SHA3-256, 5x raskere enn BLAKE2 | Intel Cascade Lake-SP 8275CL |
| Keccak-teamets referansetall | SHA3-256 | 12,6 sykluser per byte | Typisk x86-64 |
| OpenSSL, AVX-512VL | SHA3-256 | ~6,4 sykluser per byte | Skylake-X |
| OpenSSL, AVX2 | SHA3-256 | ~7,8 sykluser per byte | Skylake |
| Uavhengig 2025-måling | SHA3-256 | 280-420 MB/s gjennomstrømming | Moderne x86-64, generisk konfigurasjon |
Mønsteret er konsekvent på tvers av alle tre kildene. BLAKE3 vinner klart på ren gjennomstrømming, og forspranget vokser med filstørrelse fordi tre-strukturen lar flere kjerner og bredere SIMD-registre jobbe samtidig. SHA-3 holder seg i et mer stabilt, men lavere, hastighetsbånd uavhengig av hvor stor filen er, fordi svampen behandler data sekvensielt. Forskjellen mellom 6,4 og 12,6 sykluser per byte for SHA3-256 viser samtidig at maskinvarestøtte (AVX-512VL versus eldre instruksjonssett) fortsatt gir nesten dobbel effekt selv innenfor samme algoritme.
Verdt å understreke: tallene i tabellen er ikke direkte sammenlignbare på tvers av rader, siden hver kilde måler på ulik maskinvare og med ulik metodikk. De er likevel entydige hver for seg, og retningen er den samme uansett hvilken enkeltkilde man velger å stole mest på.
Gapet betyr noe forskjellig avhengig av arbeidsmengden. For en enkelt liten API-forespørsel, der man hasher noen hundre byte payload, er forskjellen i praksis umulig å merke, fordi begge algoritmene fullfører på mikrosekunder og annen overhead (nettverk, serialisering) dominerer totaltiden. Forskjellen blir synlig først når volumet skalerer: en CDN som verifiserer integriteten til hver eneste fil som passerer gjennom nettverket, en backup-tjeneste som hasher terabyte med data hver natt, eller et CI/CD-system som beregner sjekksummer for tusenvis av byggeartefakter hver dag. I disse tilfellene akkumulerer de små forskjellene i sykluser per byte seg til reell ventetid og reell CPU-regning, noe kostnadsberegningen lenger ned i artikkelen viser konkret.
Sikkerhetsnivå og kryptoanalyse i 2025-2026
Begge algoritmene regnes som trygge i produksjon per i dag. SHA3-256 er bygget med 512-bits kapasitet, noe som gir omtrent 128-bits kollisjonssikkerhet og opptil 256-bits preimage-sikkerhet, avhengig av angrepstype. BLAKE3 har tilsvarende sikkerhetsmål arvet fra BLAKE2s, med 128-bits kollisjonssikkerhet ved standard 256-bits output, forsterket av domeneseparasjon i tre-flaggene som gjør det vanskeligere å blande sammen intern node-hashing med sluttresultatet.
Bransjens forsiktighet rundt nyere hashfunksjoner har historiske grunner. Både MD5 og senere SHA-1 gikk fra å være anbefalte standarder til å bli praktisk brutt, sistnevnte demonstrert offentlig med et konkret kollisjonsangrep i 2017. Det er nettopp denne typen historikk som gjør at NIST krevde en helt ny matematisk konstruksjon, svampen, i stedet for enda en Merkle-Damgård-variant da SHA-3 skulle designes. BLAKE3 unngår ikke det samme spørsmålet bare fordi det er en nyere algoritme. Tvert imot er alder og bredde i offentlig gransking en av de få faktorene et sikkerhetsteam faktisk kan måle objektivt, og det taler foreløpig i SHA-3s favør, selv om ingen konkrete svakheter er funnet i BLAKE3.
Forskjellen ligger i sporhistorikken. Publiserte angrep mot Keccak, som “Improved Practical Attacks on Round-Reduced Keccak” og lignende kollisjonsforsøk fra 2023 og senere, treffer alltid reduserte rundetall, aldri de fulle 24 rundene som står i FIPS 202. NIST beskriver selv SHA-3 som motstandsdyktig mot kollisjon, preimage og second-preimage-angrep i standardteksten. BLAKE3 har på sin side ingen publiserte praktiske angrep mot fullversjonen per 2026, men algoritmen er yngre, lansert i 2020, og har dermed samlet færre år med uavhengig kryptoanalyse enn en etablert NIST-standard. Det er ikke et tegn på svakhet i seg selv, men et faktum konservative sikkerhetsteam legger vekt på når de vurderer hvilken algoritme som skal bære langsiktig ansvar for et system.
Et strukturelt poeng er verdt å ta med: fordi Keccaks svampkonstruksjon er matematisk uavhengig av SHA-2, fungerer SHA-3 som en reell reserve dersom et fremtidig gjennombrudd skulle svekke SHA-2-familien. BLAKE3 deler derimot ARX-slektskap med ChaCha og BLAKE2, så et strukturelt gjennombrudd mot den familien ville i prinsippet kunne påvirke flere algoritmer samtidig. Ingen kjente svakheter peker i den retningen per 2026, men det er et argument for algoritme-mangfold, ikke et argument mot BLAKE3 alene.
Ingen av algoritmene har heller fått offentliggjort CVE-er knyttet til selve den kryptografiske konstruksjonen per 2026. Sårbarheter som dukker opp i praksis, knytter seg nesten alltid til enkeltimplementasjoner (feil i en spesifikk biblioteksversjon, feil håndtering av tomme input, eller sidekanal-lekkasje i en dårlig skrevet bakende), ikke til selve matematikken bak BLAKE3 eller SHA-3. Det understreker hvorfor det lønner seg å bruke offisielle, mye brukte biblioteker fremfor egenskrevne implementasjoner, uavhengig av hvilken av de to algoritmene et team velger. En egenskrevet, ikke-verifisert implementasjon introduserer som regel langt større risiko enn selve valget mellom to veletablerte, mye reviderte algoritmer.
Kostnad ved skyskalering: hva koster hashingen egentlig?
Hastighetsforskjellen har en direkte prislapp når volumet blir stort nok. Regnestykket under bruker AWS sin on-demand-pris for en c7i.xlarge-instans, notert til 0,1785 dollar per time per september 2026, kombinert med de målte gjennomstrømningstallene fra forrige seksjon (4000 MB/s for BLAKE3 med AVX-512, mot et konservativt gjennomsnitt på 350 MB/s for SHA3-256). Dette er en forenklet enkeltkjerne-beregning, ikke en fasit, men den illustrerer størrelsesordenen på besparelsen.
| Datamengde | Tid og kostnad med BLAKE3 | Tid og kostnad med SHA3-256 |
|---|---|---|
| 1 TB | ~4 minutter, ca. 0,01 dollar | ~48 minutter, ca. 0,14 dollar |
| 100 TB | ~7 timer, ca. 1,24 dollar | ~79 timer, ca. 14,17 dollar |
| 1 PB | ~69 timer, ca. 12,39 dollar | ~794 timer, ca. 141,68 dollar |
Selv om beløpene i absolutte tall er små, sier forholdet mellom dem noe viktig: kostnaden ved å hashe samme datamengde med SHA3-256 ligger konsekvent rundt 11 ganger høyere enn med BLAKE3 på denne konfigurasjonen. For et selskap som hasher petabyte-mengder daglig, for eksempel i en backup-pipeline eller et innholdsdistribusjonsnettverk, blir forskjellen fort merkbar i den samlede skyregningen, selv om selve hash-jobben sjelden er den største kostnadsposten.
Det er verdt å presisere at dette er en engangsberegning på én instanstype, ikke en universell fasit. Reell produksjonsbruk vil ofte fordele jobben over flere billigere spot-instanser, cache deler av resultatet, eller kjøre hashingen som en del av en større pipeline der CPU-tiden uansett betales for andre formål. Poenget med tabellen er ikke det eksakte dollarbeløpet, men forholdstallet: uansett hvilken instanstype eller prismodell et team faktisk bruker, vil BLAKE3 typisk koste en brøkdel av det SHA3-256 koster for samme datamengde, fordi forholdet mellom syklustallene er det samme uavhengig av timepris.
For selskaper som driver innholdsdistribusjon eller strømmetjenester, der hver eneste fil som leveres til en sluttbruker gjerne verifiseres på veien, kan denne typen forskjell gjøre seg gjeldende flere ganger per dag, ikke bare som en engangsjobb. Samme resonnement gjelder for en backup-leverandør som hasher hele kundedatasett hver natt for å oppdage endringer siden forrige kjøring. I begge tilfeller er det ikke selve dollarbeløpet fra tabellen over som er poenget, men at valget av hashfunksjon faktisk er en linje i budsjettet, ikke bare en teknisk detalj.
Hvem bruker BLAKE3? Virkelige eksempler
BLAKE3 har rukket å bli standardvalg i flere verktøy der ytelse er avgjørende. IPFS, det distribuerte filsystemet, har lagt til støtte for BLAKE3 nettopp fordi prosjektet gjør enormt mye hashing for å sikre filintegritet på tvers av noder som ikke stoler på hverandre. Bao-prosjektet bygger direkte på BLAKE3s tre-modus for å tilby verifisert strømming, altså mulighet til å sjekke ektheten av en fil mens den fortsatt lastes ned, uten å vente på hele filen før verifiseringen kan starte. Det er en egenskap eldre hashfunksjoner som SHA-1 og SHA-256 rett og slett ikke er designet for å tilby.
Cargo, den offisielle pakkebehandleren for Rust, bruker BLAKE3 til sjekksummer for crates, som betyr at svært mange utviklere kjører algoritmen kontinuerlig uten å tenke over det. Bazel, byggesystemet Google har gjort åpen kildekode, støtter BLAKE3 som digest-funksjon for filintegritet i byggegrafen, der tusenvis av filer må verifiseres på hver eneste bygg-jobb. rclone-prosjektet har også hatt en åpen forespørsel om b3sum-støtte som alternativ til md5sum og sha1sum, et tegn på at etterspørselen finnes selv i verktøy som ennå ikke har fullført overgangen. Fellesnevneren for alle disse fire eksemplene er at de håndterer store datamengder der hashing skjer kontinuerlig i bakgrunnen, ikke som en enkeltstående operasjon en bruker venter på.
Hvem bruker SHA-3 og Keccak-256? Virkelige eksempler
Det største enkeltbruksområdet for en Keccak-variant er trolig Ethereum. Ethereum bruker Keccak-256, altså varianten fra før FIPS 202 ble ferdigstilt, til å utlede kontoadresser, hashe transaksjonsdata og beregne røttene i Merkle Patricia-treet som lagrer kontraktstilstand i EVM-en. Alle EVM-kompatible kjeder har arvet dette valget, så Keccak-256 kjører i praksis på et større transaksjonsvolum enn noen standardisert SHA3-variant gjør alene. Det er verdt å merke seg presist: Keccak-256 og FIPS-godkjent SHA3-256 er ikke identiske, fordi paddingen i meldingen er forskjellig. Et bibliotek bygget for SHA3-256 gir dermed ikke samme output som Ethereums Keccak-256, selv med identisk input.
Utover Ethereum bruker blokkjedene Nexus (NXS) og SmartCash (SMART) varianter av SHA-3 i sine protokoller. På myndighetssiden gir FIPS 202 amerikanske føderale etater en godkjent hash-familie som er uavhengig av SHA-2, noe som er relevant for organisasjoner som må vise algoritme-mangfold som en del av forsvar-i-dybden. Offentlige kontraktører innen forsvar og deler av helse- og finanssektoren, der FIPS-samsvar er et krav, kan ikke bytte til alternativer uten at NIST har godkjent dem, og det gjør SHA-3 til et fast innslag i mange samsvarsdokumenter uavhengig av rå ytelse.
Mange kryptografibiblioteker har i tillegg lagt SHA3-256, SHA3-512 og SHAKE-variantene til side om side med eldre funksjoner som MD5 og SHA-256, nettopp for å gi utviklere et FIPS-godkjent alternativ uten å måtte bytte hele biblioteket. OpenSSL, som brorparten av internett-infrastrukturen lener seg på for TLS og signering, har hatt native SHA3-implementasjoner med målbar ytelse siden versjon 1.1.1, og de fleste språks standardbibliotek (Python, Go, Java) har fulgt etter i årene siden.
Ekspertene om BLAKE3 mot SHA-3
Utsagnene under er hentet direkte fra prosjektdokumentasjon, fagpresse og offentlige diskusjoner blant kryptografer, ikke fra markedsføringstekster skrevet av en tredjepart. De gir et bilde av hvor samstemt bransjen faktisk er om ytelsesforskjellen, selv om synet på hvilken algoritme som er “riktig” valg fortsatt varierer med bruksområde.
BLAKE3-teamet selv er ikke beskjedne om ytelsesgapet. I den offisielle prosjektbeskrivelsen skriver de at algoritmen er “much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2” – BLAKE3-team, prosjektvedlikeholdere.
Kryptografipraktikeren Andrew Moon har uttrykt det samme poenget mer direkte i en offentlig diskusjon om hash-familier: “The ‘SHA-3’ named hash functions SHA3-256 and SHA3-512 are both quite slow compared to BLAKE2/BLAKE3” – Andrew Moon, kryptografipraktiker.
Teknologimediet InfoQ dekket det opprinnelige lanseringsbenchmarket i detalj og oppsummerte det slik: “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, redaksjonell dekning.
På den tekniske siden peker BLAKE3s egne utkastforfattere i IETF-spesifikasjonen på en designdetalj som knytter algoritmen til SHA-2-slekten: “The initial value (IV) of BLAKE3 is the same as SHA-256 IV, namely the 8-word IV[0..7]” – BLAKE3-utkastforfatterne, IETF-spesifikasjon. Det er et lite, men talende eksempel på hvor tett de to slektstrærne i moderne hashdesign faktisk henger sammen, selv når toppnivå-konstruksjonene ser helt forskjellige ut.
Slik migrerer du fra SHA-3 til BLAKE3
En overgang fra SHA-3 til BLAKE3 er sjelden en ren finn-og-erstatt-jobb, spesielt hvis eksisterende hash-verdier er lagret i en database eller brukes som identifikator andre steder i systemet. Bytter man hash-algoritme uten en overgangsplan, risikerer man at gamle klienter plutselig ikke lenger kan verifisere data de allerede har lastet ned, eller at et deduplisering-system begynner å behandle identisk innhold som unikt fordi nøkkelrommet har endret seg. Følg denne rekkefølgen for å unngå brutte referanser:
- Kartlegg bruken: Finn hvor SHA3-256 eller SHAKE brukes i kodebasen i dag, for eksempel filintegritet, cache-nøkler, deduplisering, eller protokollnivå som blokkjede-adresser. En enkel søk-og-liste-øvelse i kodebasen avdekker som regel flere steder enn teamet husker fra hukommelsen.
- Skjerm protokollbundet bruk: Fjern all bruk som er styrt av et protokollkrav, som Keccak-256 i EVM-sammenheng, fra migreringslisten. Det er ikke noe å migrere der, og et forsøk på å bytte vil bare skape inkompatible data.
- Kjør parallelt i en overgangsperiode: La begge algoritmene kjøre samtidig for nye data, og lagre begge hash-verdiene, slik at gamle klienter fortsatt kan verifisere mot SHA3-256 mens nye klienter går over til BLAKE3.
- Bytt biblioteksavhengighet: Rust-prosjekter bruker
blake3-crate-t direkte, mens Python-prosjekter typisk installererblake3via pip fremfor å utvidehashlib. Sjekk at biblioteket støtter riktig SIMD-bakende for målplattformen. - Oppdater verifiseringslogikken: Endre systemet slik at det leser hash-type fra metadata i stedet for å anta ett fast format. Dette er ofte den mest tidkrevende delen av migreringen, fordi den berører flere lag i applikasjonen.
- Fase ut det gamle formatet: Slutt å skrive SHA3-256 for nye data når overvåkingen viser at ingen klienter lenger krever det gamle formatet, og planlegg en dato for når historiske SHA3-256-verdier eventuelt kan fjernes helt.
Et enkelt eksempel på dobbelthashing i overgangsfasen, i Python, ser slik ut:
import hashlib
import blake3
def dual_hash(data: bytes) -> dict:
return {
"sha3_256": hashlib.sha3_256(data).hexdigest(),
"blake3": blake3.blake3(data).hexdigest(),
}
with open("stordokument.bin", "rb") as f:
payload = f.read()
resultat = dual_hash(payload)
print(resultat)Denne tilnærmingen koster ekstra CPU-tid i overgangsperioden, men gir et sikkerhetsnett dersom noe i den gamle infrastrukturen fortsatt forventer et SHA3-256-format. Når overvåkingsdataene viser null trafikk mot det gamle feltet, er det trygt å fjerne det.
Et team som planlegger en større migrering bør sette av tid til å teste ytelsen på egen maskinvare før beslutningen tas endelig, ikke bare stole på publiserte tall fra andres testmiljø. Forskjeller i CPU-generasjon, tilgjengelig SIMD-instruksjonssett og til og med hvordan operativsystemet planlegger tråder kan gi avvik fra referansetallene i denne artikkelen. En enkel mikrobenchmark på representative filstørrelser tar sjelden mer enn en time å sette opp, og gir et langt mer pålitelig grunnlag for beslutningen enn å ekstrapolere fra et annet selskaps maskinvarepark.
Fra kommandolinjen er overgangen enda enklere å teste manuelt. Verktøyet b3sum fungerer som en direkte erstatning for sha3sum i skript, og gir samme type utdata (hash pluss filnavn), noe som gjør det trygt å kjøre begge side om side i en overgangsperiode og diffe resultatene automatisk:
> b3sum stordokument.bin
3f5c8e2a... stordokument.bin
> sha3sum -a 256 stordokument.bin
9d1a4b7c... stordokument.binLegg merke til at de to hash-verdiene aldri vil være like, selv for identisk input, fordi algoritmene er fundamentalt forskjellige. Poenget med å kjøre begge er ikke å sammenligne verdiene direkte, men å bekrefte at begge kommandoene fullfører uten feil og at den nye BLAKE3-verdien lagres konsekvent før man fjerner avhengigheten til SHA3-256 fullstendig.
Fordeler og ulemper med BLAKE3
BLAKE3s største styrke er hastighet kombinert med moderne funksjonalitet i ett paket: nøklet hashing, nøkkelutledning og strømmende verifisering er alle innebygd fra start, uten behov for separate konstruksjoner som HMAC eller andre hashfunksjoner bygget på toppen av en grunnalgoritme. Den native parallelliteten gjør at ytelsen skalerer godt med både filstørrelse og antall CPU-kjerner, noe som er verdifullt i byggesystemer, pakkehåndtering og backup-verktøy som håndterer enorme datamengder daglig. Biblioteket er dessuten lite og har få avhengigheter, noe som gjør det enkelt å revidere manuelt for team med strenge krav til kodekvalitet.
Svakheten er mangelen på formell standardisering. BLAKE3 er verken FIPS- eller ISO-godkjent per 2026, noe som stenger den ute fra offentlige anbud og bransjer med strenge samsvarskrav. Algoritmen er også yngre, lansert i 2020, og har dermed hatt kortere tid til å samle den brede, uavhengige kryptoanalysen som gir en etablert standard som SHA-3 sin tyngde. Ingen praktiske svakheter er funnet så langt, men “ingen kjente angrep ennå” er ikke det samme som “årelangt utprøvd” i manges risikovurdering. Et team som velger BLAKE3 bør derfor være forberedt på å begrunne valget overfor revisorer eller sikkerhetsansvarlige som er vant til å se etter en NIST-standard i sjekklisten.
Fordeler og ulemper med SHA-3
SHA-3s fremste fordel er tillit bygget over tid: en åpen, flerårig NIST-konkurranse, formell standardisering i FIPS 202, og en svampkonstruksjon som er matematisk uavhengig av SHA-2. Det siste punktet gjør SHA-3 til en reell forsikring dersom SHA-2-familien noen gang skulle svekkes strukturelt. For organisasjoner som må dokumentere samsvar, spesielt offentlig sektor og regulerte bransjer, er FIPS-godkjenningen ofte det som avgjør valget, uavhengig av ytelsestall. Bredden i støtte er også en fordel i seg selv: fordi SHA-3 har vært standardisert siden 2015, finnes det implementasjoner i praktisk talt alle utbredte programmeringsspråk og maskinvareplattformer, inkludert eldre systemer som aldri vil få offisiell BLAKE3-støtte.
Ulempen er ren regnekraft. Svampkonstruksjonen krever flere sykluser per byte enn en ARX-kjede, og mangelen på nativ tre-parallellitet gjør at SHA-3 ikke skalerer like elegant med moderne mange-kjerne-maskinvare. For systemer som hasher store datamengder kontinuerlig, oversettes det til lengre kjøretid og, som vist tidligere, en håndfast høyere skyregning. SHA-3 mangler også en innebygd, standardisert strømmemodus på linje med Bao, så delvis verifisering av store filer krever ekstra applikasjonslogikk rundt algoritmen i stedet for å få det gratis fra spesifikasjonen.
Fem-pluss bruksområder: hvilken algoritme passer hvor
Listen under samler opp trådene fra resten av artikkelen til konkrete anbefalinger. Den er sortert etter hvor tydelig valget er: noen av punktene er nærmest opplagte fordi de er styrt av eksterne krav, mens andre krever en reell avveining mellom ytelse og modenhet.
- Filintegritet i store datasett og backup-pipeliner: BLAKE3 er riktig valg. Hastigheten reduserer både kjøretid og skykostnad betydelig ved store volumer, og strømmende verifisering gjør at man kan begynne å sjekke en fil før hele overføringen er ferdig.
- Utvikling på Ethereum eller andre EVM-kompatible kjeder: Keccak-256 er obligatorisk, ikke valgfritt. Protokollen definerer adresser og trie-røtter med denne spesifikke varianten, og alternativer, inkludert FIPS-godkjent SHA3-256, gir feil resultat fordi paddingen skiller seg fra det EVM-en forventer.
- Offentlig sektor og FIPS-regulerte bransjer: SHA-3 (eller SHA-2) er riktig, fordi samsvarskravene som regel krever et NIST-godkjent alternativ uavhengig av rå ytelse. Dette gjelder typisk offentlige anbud, forsvarskontrakter og deler av finanssektoren.
- Byggesystemer og pakkeregistre (CI/CD-artefakter): BLAKE3 passer godt, slik Cargo og Bazel allerede har vist i produksjon, fordi det reduserer ventetiden i hver eneste byggejobb der tusenvis av filer skal sjekkes.
- Passordhashing: Verken BLAKE3 eller SHA-3 er riktig verktøy alene. Begge er designet for hastighet, som er motsatt av hva passordhashing trenger. Argon2 eller lignende minnehardt design er riktig løsning her, nettopp fordi det gjør brute force-forsøk dyre for en angriper.
- Innholdsadressering i distribuerte systemer: BLAKE3 er godt egnet, slik IPFS-prosjektet har demonstrert, fordi tre-strukturen passer naturlig med hvordan innhold deles opp og verifiseres i biter på tvers av noder som ikke nødvendigvis stoler på hverandre.
- Langsiktig arkivering med krav om algoritme-mangfold: SHA-3 som sekundær hash ved siden av SHA-2 gir reell strukturell diversitet, noe to ARX-baserte algoritmer ikke kan tilby på samme måte. Dette er relevant for arkiver som skal vare i tiår, ikke bare år.
- Ressursbegrenset maskinvare med lav batterikapasitet: Lavere sykluser per byte betyr i praksis mindre CPU-arbeid per hashet megabyte, noe som isolert sett peker mot BLAKE3 der strømforbruk er en reell begrensning, selv om selve valget bør testes mot den spesifikke maskinvaren.
Verdikt: hva sier tallene samlet sett?
Målt i rå ytelse er dette ikke en jevn kamp. BLAKE3 leverer mellom 5 og 27 ganger høyere gjennomstrømming enn SHA-3-familien, avhengig av maskinvare og målemetode, og kostnadsberegningen i skyen viser samme mønster: rundt 11 ganger lavere kostnad ved store volumer. Ingen offentlig kjente praktiske angrep rammer noen av algoritmene i fullversjon per 2026, så sikkerhetsnivået alene skiller dem ikke i dag.
Sett i sammenheng med resten av hash-familien blir bildet enda tydeligere. Sammenlignet med eldre algoritmer som SHA-1 er begge BLAKE3 og SHA-3 dramatisk tryggere, men de to skiller lag på nesten alt annet enn sikkerhetsnivået på papiret: konstruksjon, standardiseringsstatus, ytelse og hvor godt de utnytter moderne maskinvare. Det gjør sammenligningen mer nyansert enn et rent “hvilken er best”-spørsmål.
Det som faktisk avgjør valget for de fleste team, er ikke ytelse, men kontekst. Krever prosjektet FIPS-samsvar, er svaret SHA-3 uansett hva benchmarkene viser. Er algoritmen låst av en protokoll, som Ethereums Keccak-256, finnes det ikke noe valg å ta. Står teamet derimot fritt, uten regulatoriske bindinger, og prioriterer hastighet og moderne funksjonalitet som innebygd strømmeverifisering, peker tallene entydig mot BLAKE3. Konklusjonen for 2026 er derfor todelt: BLAKE3 vinner på ren ingeniørkunst, SHA-3 vinner på tillit og regelverk, og de fleste organisasjoner ender opp med å trenge begge et sted i stacken.
For lesere som vil se hvordan disse to algoritmene stiller seg mot andre hashfunksjoner, dekker kryptografiarkivet til Shattered flere direkte sammenligninger, blant annet hvordan BLAKE3 måler seg mot SHA-256 og hvordan SHA-256 selv presterer mot SHA-3. Sammen gir de tre artiklene et helhetsbilde av hvor hver algoritme faktisk hører hjemme i en moderne teknologistack.
Ofte stilte spørsmål
Er BLAKE3 tryggere enn SHA-3?
Ingen av algoritmene har kjente praktiske svakheter i fullversjon per 2026. SHA-3 har lengre dokumentert sporhistorikk gjennom NISTs standardiseringsprosess, som involverte flere år med offentlig kryptoanalyse fra hundrevis av forskere før algoritmen ble godkjent. BLAKE3 er yngre, lansert i 2020, og har dermed samlet færre år med uavhengig gjennomgang. Sikkerhetsnivået på papiret, rundt 128-bits kollisjonssikkerhet, er likevel sammenlignbart mellom de to.
Kan jeg bruke BLAKE3 i stedet for SHA-3 i en blokkjede, og er SHA-3 det samme som Keccak-256 i Ethereum?
Ikke hvis protokollen allerede definerer Keccak-256, slik Ethereum og andre EVM-kompatible kjeder gjør. Adresser og trie-røtter er definert med den spesifikke hash-varianten, og et bytte ville bryte kompatibiliteten fullstendig. Verdt å presisere: Keccak-256 og FIPS-godkjent SHA3-256 er heller ikke identiske, selv om navnene ofte brukes om hverandre. Ethereums variant er fra før FIPS 202 ble ferdigstilt og bruker en annen padding, så et bibliotek bygget for standard SHA3-256 gir ikke samme resultat som Ethereums Keccak-256 for identisk input.
Er BLAKE3 FIPS-godkjent?
Nei. BLAKE3 har verken FIPS- eller ISO-standardisering per 2026. Organisasjoner med lovpålagt samsvarskrav må derfor bruke SHA-2 eller SHA-3 i stedet, uavhengig av ytelsesfordelene BLAKE3 tilbyr.
Hvorfor er BLAKE3 så mye raskere enn SHA-3?
Hovedgrunnen er strukturell. BLAKE3s Merkle-tre lar flere CPU-kjerner og brede SIMD-registre jobbe på ulike deler av samme fil samtidig, mens SHA-3s svampkonstruksjon behandler data sekvensielt gjennom 24 permutasjonsrunder uansett filstørrelse.
Hvilken bør jeg velge til passordhashing?
Ingen av dem. Begge er raske hashfunksjoner, og hastighet er en ulempe når man skal beskytte passord mot brute force-angrep. Bruk et minnehardt design som Argon2 til det formålet.
Støtter Python, Rust og Go begge algoritmene?
Ja. Python har SHA3-256 innebygd i hashlib siden versjon 3.6, og BLAKE3 er tilgjengelig via et eget pip-pakke som wrapper den offisielle Rust-implementasjonen. Rust har begge som offisielle crates med aktivt vedlikehold. Go har SHA-3 i utvidelsesbiblioteket golang.org/x/crypto/sha3 og BLAKE3 via velprøvde tredjepartsimplementasjoner med AVX2- og AVX-512-støtte, som den fra lukechampine referert til tidligere i artikkelen.
Hvor lang tid tar det å knekke BLAKE3 eller SHA-3 med brute force?
Med rundt 128-bits kollisjonssikkerhet i begge algoritmer er et generisk brute force-angrep beregningsmessig umulig med dagens og overskuelig fremtidig maskinvare, inkludert store dedikerte klynger. Det finnes ingen kjent snarvei som reduserer denne kostnaden vesentlig for noen av algoritmene per 2026.
Kan jeg bruke BLAKE3 og SHA-3 om hverandre i samme system?
Teknisk sett ja, så lenge systemet lagrer hvilken algoritme som ble brukt for hver enkelt hash-verdi, for eksempel som et prefiks eller et eget metadatafelt. Det som ikke fungerer, er å anta at en hash-verdi automatisk kommer fra én bestemt algoritme uten å sjekke. Mange moderne verktøy løser dette ved å inkludere et kort algoritme-navn foran selve hash-strengen, nøyaktig slik migreringseksempelet tidligere i artikkelen viser.
