Når utviklere velger krypteringsalgoritme til en ny tjeneste, dukker spørsmålet nesten alltid opp: ChaCha20 eller Salsa20? Begge er strømchiffer designet av den amerikanske kryptografen Daniel J. Bernstein, og begge bygger på samme grunnidé: addisjon, rotasjon og XOR (ofte kalt ARX-design) i stedet for oppslagstabeller. Likevel er det ChaCha20 som i dag kjører i TLS 1.3, WireGuard og OpenSSH, mens Salsa20 og dens utvidede variant XSalsa20 lever videre i biblioteker som libsodium. Denne artikkelen går gjennom hva som faktisk skiller dem, med ekte benchmark-tall fra tre uavhengige kilder, konkrete kryptoanalyse-resultater og en praktisk migreringsguide for team som fortsatt bruker den klassiske Salsa20-konstruksjonen.
Kort oppsummert: ChaCha20 vant kampen om internett-standardene fordi den diffunderer endringer raskere gjennom sin interne tilstand enn Salsa20, uten å bruke flere regneoperasjoner. Salsa20 er ikke svakere eller utdatert av den grunn, men økosystemet rundt IETF-standarden RFC 8439 har gjort ChaCha20 til standardvalget for nye protokoller.
Begge chiffer tilhører det som kryptografer kaller strømchiffer, en type kryptering som genererer en lang, tilfeldig-lignende bitstrøm fra en nøkkel og en nonce, og deretter XOR-er denne strømmen direkte med klarteksten. Det gjør dem fundamentalt forskjellige fra blokkchiffer som AES, som krypterer data i fastbredde-blokker og krever egne modusvalg som CBC eller GCM for å håndtere meldinger av varierende lengde. Forståelsen av denne forskjellen er nyttig bakgrunn før man går videre til de konkrete design- og ytelsesforskjellene mellom de to Bernstein-designene.
Verdt å nevne: dette er ikke et spørsmål om å velge mellom en “sikker” og en “usikker” algoritme. Begge er grundig analyserte, mye brukte og regnes som trygge i sine fulle rundeversjoner av det internasjonale kryptografimiljøet. Spørsmålet handler i stedet om hvilken av de to som passer bedre inn i den konkrete protokollen, plattformen og kodebasen du jobber med, noe resten av denne artikkelen går gjennom i detalj.
For å gjøre sammenligningen konkret og etterprøvbar, bruker vi gjennom hele artikkelen kun tall fra navngitte, kontrollerbare kilder: Bernsteins egne publiserte spesifikasjoner og benchmark-tabeller, Wikipedias dokumenterte referanser, og en fersk akademisk studie fra 2026. Ingen av tallene under er estimert eller gjettet frem for anledningen.
Metoden bak denne sammenligningen er enkel: vi starter med designhistorien til hver algoritme, går gjennom de tekniske spesifikasjonene side om side, dokumenterer ytelse fra flere uavhengige kilder, og ender opp med konkrete anbefalinger for ulike bruksområder, inkludert en praktisk migreringsguide for team som sitter med eksisterende Salsa20-baserte systemer.
Hva er Salsa20? Bernsteins opprinnelige strømchiffer
Salsa20 ble designet av Daniel J. Bernstein i 2005 og sendt inn til eSTREAM-prosjektet, EU-finansiert forskningsinitiativ som skulle kartlegge nye strømchiffer etter at flere eldre konstruksjoner hadde vist svakheter. Salsa20 bruker en intern tilstand på 512 bit, fordelt på seksten 32-bit ord, og krypterer data ved å generere en keystream som deretter XOR-es med klartekst. Algoritmen støtter både 128-bit og 256-bit nøkler, men det er 256-bit-varianten, kjent som Salsa20/20, som har fått mest oppmerksomhet i produksjonsmiljøer.
Navnet Salsa20/20 refererer til at algoritmen kjører 20 runder av sin kjernefunksjon. Bernstein definerte også to raskere varianter, Salsa20/12 og Salsa20/8, med 12 og 8 runder. Disse reduserte variantene er beregnet på brukere som prioriterer hastighet fremfor sikkerhetsmargin, og de dukker opp i enkelte innebygde systemer der ytelse er kritisk. Kjernen i Salsa20 er kvartrunden, en funksjon som oppdaterer fire 32-bit ord ved hjelp av addisjon, XOR og rotasjon med konstantene 7, 9, 13 og 18 bit. Salsa20 kjører først runder nedover kolonnene i sin interne 4×4-matrise, og deretter runder langs radene.
Den klassiske Salsa20-konstruksjonen bruker en 64-bit nonce og en 64-bit blokkteller. En utvidet variant, XSalsa20, ble senere laget for å støtte en 192-bit nonce. Denne utvidelsen brukes i dag i libsodiums populære secretbox-API, hvor den lange nonce-en gjør det praktisk mulig å bruke tilfeldig genererte nonce-verdier uten fare for kollisjon, selv i applikasjoner som krypterer enorme mengder meldinger.
Hva er ChaCha20? Fra Salsa20 til diagonale runder
ChaCha ble introdusert av Bernstein i januar 2008 som en direkte videreutvikling av Salsa20. Målet var ikke å fikse en kjent svakhet. Som Bernstein selv skriver i det originale ChaCha-papiret, var hensikten å øke diffusjonen per runde og samtidig bevare, eller forbedre, hastigheten per runde. ChaCha8, ChaCha12 og ChaCha20 er de tre variantene, med samme rundetall-logikk som Salsa20-familien.
Den viktigste tekniske endringen ligger i hvordan kvartrunden flytter data. Salsa20 kjører kolonnerunder og deretter raderunder. ChaCha bytter ut raderundene med diagonale runder, der hvert av de fire ordene som behandles sammen ligger på en diagonal i den interne 4×4-matrisen i stedet for i en rad. Denne endringen gir hvert input-ord mulighet til å påvirke hvert output-ord raskere, noe som er selve poenget med diffusjon i et kryptografisk design.
ChaCha20 bruker rotasjonskonstantene 16, 12, 8 og 7 bit, mot Salsa20s 7, 9, 13 og 18 bit. Begge kvartrundene bruker nøyaktig samme antall operasjoner: 4 addisjoner, 4 XOR-operasjoner og 4 rotasjoner per kvartrunde (16 av hver per full runde). Det betyr at ChaCha20 ikke er “tyngre” å kjøre enn Salsa20, den er bare organisert annerledes internt. ChaCha20 kjører i praksis 10 iterasjoner av en dobbeltrunde (en kolonnerunde pluss en diagonalrunde), som til sammen gir de 20 rundene algoritmen er navngitt etter.
Kvartrunder og diffusjon: den tekniske kjernen i forskjellen
For å forstå hvorfor ChaCha20 vant over Salsa20 i standardiseringsarbeidet, må man se på selve kvartrunde-koden. Salsa20s kvartrunde ser slik ut, uttrykt i C-lignende pseudokode fra Bernsteins originale spesifikasjon:
// Salsa20 kvartrunde
b ^= (a+d) <<< 7;
c ^= (b+a) <<< 9;
d ^= (c+b) <<< 13;
a ^= (d+c) <<< 18;ChaChas kvartrunde, slik Bernstein publiserte den i 2008, bytter rekkefølgen og bruker andre rotasjonskonstanter:
// ChaCha kvartrunde
a += b; d ^= a; d <<<= 16;
c += d; b ^= c; b <<<= 12;
a += b; d ^= a; d <<<= 8;
c += d; b ^= c; b <<<= 7;Forskjellen virker kosmetisk, men konsekvensen er målbar. Bernstein testet hvor mange output-bit som endres i gjennomsnitt når man flipper ett tilfeldig input-bit, uten å telle med eventuelle carry-effekter. Resultatet: Salsa20s kvartrunde endrer i snitt 8 output-bit, mens ChaChas kvartrunde endrer 12,5 output-bit. Det er over 50 prosent mer diffusjon per runde, uten en eneste ekstra regneoperasjon. Denne ene designendringen er grunnen til at mange kryptografer anser ChaCha20 som det tryggere valget ved samme rundetall som Salsa20.
Spesifikasjonstabell: ChaCha20 mot Salsa20
Tabellen under samler de viktigste tekniske spesifikasjonene for begge chiffer, basert på de originale spesifikasjonene og IETF-standardene som bygger på dem.
| Egenskap | Salsa20 | ChaCha20 |
|---|---|---|
| Designer | Daniel J. Bernstein | Daniel J. Bernstein |
| Publisert | Designet 2005, eSTREAM-innsendelse | Januar 2008 |
| Intern tilstand | 512 bit (16 x 32-bit ord) | 512 bit (16 x 32-bit ord) |
| Struktur | ARX (addisjon, rotasjon, XOR) | ARX (addisjon, rotasjon, XOR) |
| Fulle runder | 20 (Salsa20/20) | 20 (ChaCha20) |
| Reduserte varianter | Salsa20/12, Salsa20/8 | ChaCha12, ChaCha8 |
| Rundestruktur | Kolonnerunder + raderunder | Kolonnerunder + diagonale runder |
| Rotasjonskonstanter | 7, 9, 13, 18 bit | 16, 12, 8, 7 bit |
| Diffusjon per kvartrunde | 8 output-bit i snitt | 12,5 output-bit i snitt |
| Nøkkelstørrelse | 128 eller 256 bit | 256 bit (IETF-variant) |
| Klassisk nonce | 64 bit + 64-bit teller | 64 bit + 64-bit teller (original) |
| IETF-nonce (RFC 8439) | Ikke definert | 96 bit + 32-bit teller |
| Utvidet nonce-variant | XSalsa20: 192 bit | XChaCha20: 192 bit |
| IETF-standard | Ingen egen RFC | RFC 7539, obsoletert av RFC 8439 |
| AEAD-konstruksjon | Ingen offisiell | ChaCha20-Poly1305 |
Nøkkelstørrelse, nonce og blokkteller i praksis
En nonce (number used once) skal aldri gjenbrukes med samme nøkkel i noen strømchiffer, fordi det gjør det mulig å XOR-e to krypterte strømmer og gjenvinne informasjon om begge klartekstene. Her ligger en praktisk fordel for IETF-varianten av ChaCha20: med en 96-bit nonce kan en avsender generere tilfeldige nonce-verdier for enorme mengder meldinger uten reell kollisjonsrisiko, mens den klassiske 64-bit nonce-en i Salsa20 krever mer forsiktig tellerhåndtering i protokoller med høyt meldingsvolum.
Samtidig har Salsa20-familien sitt eget svar på problemet gjennom XSalsa20, som strekker nonce-en til 192 bit ved å bruke de første 16 byte av nonce-en og nøkkelen til å derivere en ny delnøkkel før selve krypteringen starter. Denne teknikken er grunnen til at libsodiums mest brukte API, crypto_secretbox, fortsatt lener seg på XSalsa20 internt i mange implementasjoner, selv om biblioteket også tilbyr rene ChaCha20-Poly1305-funksjoner for team som ønsker IETF-kompatibilitet. ChaCha-familien har en tilsvarende utvidelse kalt XChaCha20, som ikke ble formelt publisert av Bernstein, men hvor sikkerhetsbeviset for XSalsa20 overføres direkte til konstruksjonen.
Blokktelleren avgjør maksimal meldingslengde
IETF-varianten av ChaCha20 bruker en 32-bit blokkteller, som begrenser en enkelt nøkkel- og nonce-kombinasjon til rundt 256 gigabyte data (2^32 blokker av 64 byte) før telleren går rundt. Den opprinnelige Salsa20-konstruksjonen og den eldre ChaCha-varianten brukte en 64-bit teller, som i praksis fjerner denne begrensningen for nesten alle tenkelige bruksområder. I protokoller som TLS 1.3 og WireGuard løses dette ved å rotere nøkler ofte nok at 256 gigabyte-grensen aldri blir et reelt problem, men det er en designdetalj verdt å kjenne til ved implementering av egne protokoller.
Ytelsesbenchmarks: hva sier tre uavhengige kilder
Påstander om at ChaCha20 er raskere enn Salsa20, eller omvendt, flyter fritt på nettet uten kildehenvisning. Her er tre faktiske målinger, fra tre forskjellige tidspunkt og miljøer, som gir et mer nyansert bilde.
Den første kilden er Bernsteins eget ChaCha-papir fra 2008, der han testet ChaCha8 mot Salsa20/8 på ti forskjellige prosessorer ved hjelp av eSTREAM-rammeverket for benchmarking. Resultatene var langt fra entydige i favør av ChaCha: på en 64-bit Core 2-prosessor var hastigheten identisk, det samme på en UltraSPARC IV. ChaCha8 var 5 prosent raskere på en Athlon 64 X2 og på en Pentium D (32-bit x86), 6 prosent raskere på en PowerPC G4, og 8 prosent raskere på en Pentium M. På en annen Pentium D-konfigurasjon (64-bit amd64) målte Bernstein hele 28 prosent raskere kjøring for ChaCha8. Men på en eldre Athlon-prosessor var ChaCha8 faktisk 16 prosent saktere, og på en Pentium 4 var den 31 prosent saktere enn Salsa20/8. Konklusjonen her er at maskinvare og kompilator avgjør mer enn algoritmevalget i seg selv.
Den andre kilden er Wikipedias artikkel om Salsa20, som siterer Bernsteins eget nettsted for en konkret måling: 3,91 sykluser per byte for Salsa20 på en Intel Core 2 Duo. Samme kilde oppgir at Salsa20 generelt ligger mellom 4 og 14 sykluser per byte i programvare på moderne x86-prosessorer, avhengig av implementasjon og kompileringsinnstillinger. Dette gir et realistisk referansepunkt: begge chiffer ligger i samme størrelsesorden, og forskjellen avgjøres i stor grad av om prosessoren har SHA- eller AES-akselerasjon tilgjengelig for andre deler av krypteringskjeden.
Den tredje kilden er fersk: en komparativ studie publisert i International Journal of Creative Research Thoughts i august 2026, utført av forskere ved JAIN University i Bengaluru. Studien kjørte en Python-basert simulering av fem krypteringsalgoritmer, AES-128, PRESENT, Salsa20, ChaCha20 og SIMON, over datamengder fra 1 kilobyte til 1 megabyte. Tabellen under viser de rapporterte krypteringstidene i millisekund.
| Algoritme | 1 KB | 10 KB | 100 KB | 500 KB | 1 MB |
|---|---|---|---|---|---|
| ChaCha20 | 0,38 ms | 2,89 ms | 27,6 ms | 136,2 ms | 271,1 ms |
| Salsa20 | 0,41 ms | 3,12 ms | 29,8 ms | 147,3 ms | 293,6 ms |
| AES-128 | 0,82 ms | 6,14 ms | 58,3 ms | 284,1 ms | 551,7 ms |
| SIMON | 1,07 ms | 8,43 ms | 80,6 ms | 396,8 ms | 796,3 ms |
| PRESENT | 1,24 ms | 9,87 ms | 94,2 ms | 463,5 ms | 931,4 ms |
I denne IJCRT-studien fra 2026 var ChaCha20 raskest ved alle fem datamengder, med Salsa20 tett bak på andreplass gjennom hele tabellen. Ved 1 megabyte var ChaCha20s krypteringstid omtrent 51 prosent lavere enn AES-128 under forskernes testforhold. Forskerne beregnet også en avledet gjennomstrømning: cirka 3 777 kilobyte per sekund for ChaCha20 mot 3 488 kilobyte per sekund for Salsa20. Studien er en programvaresimulering uten maskinvareakselerasjon og uten egne energimålinger, men den bekrefter mønsteret fra de to andre kildene: ChaCha20 og Salsa20 ligger svært nær hverandre i ytelse, med ChaCha20 oftest en liten tomme foran.
ARM mot x86: hvem vinner uten maskinvareakselerasjon
Begge chiffer er bygget utelukkende på heltallsoperasjoner: addisjon, XOR og rotasjon. Det betyr at de ikke er avhengige av spesialisert maskinvare som AES-NI på Intel og AMD, eller de kryptografiske utvidelsene i ARMv8. Dette er en vesentlig fordel på billige IoT-brikker, eldre mobilprosessorer og innebygde systemer der AES-akselerasjon rett og slett ikke finnes.
På x86-prosessorer med AES-NI aktivert vinner AES-GCM som regel over ChaCha20-Poly1305 for store datamengder, fordi maskinvareinstruksjonen gjør AES-rundene nesten gratis i cykler. Uten AES-NI endres bildet fullstendig: AES må da kjøres i ren programvare, noe som er betydelig tregere, og ChaCha20-Poly1305 blir det raskere alternativet. Dette er nøyaktig scenarioet som gjorde ChaCha20-Poly1305 til et naturlig valg for mobile klienter og eldre servere uten moderne CPU-instruksjoner.
På ARM-siden er bildet mer nyansert. Nyere ARMv8-brikker med kryptografiske utvidelser (AES- og SHA2-instruksjoner) kan gjøre AES-GCM konkurransedyktig eller raskere enn ChaCha20-Poly1305, mens eldre eller lavprisede ARM-brikker uten disse utvidelsene nesten alltid favoriserer ChaCha20. Dette er bakgrunnen for at Googles Adiantum-design for diskkryptering på budsjett-Android-telefoner bruker ChaCha12, en redusert-runde-variant av ChaCha, kombinert med en hash-basert konstruksjon, for å levere fullstendig diskkryptering på enheter uten AES-maskinvare. Det er verdt å presisere at Adiantum bruker ChaCha12 og ikke ChaCha20, og at konstruksjonen derfor ikke skal forveksles med TLS-bruken av ChaCha20-Poly1305.
Sidekanalangrep: hvorfor ARX-design er tryggere i praksis
Et poeng som ofte forsvinner i rene ytelsessammenligninger, er hvor motstandsdyktige de to chifferene er mot sidekanalangrep, altså angrep som ikke bryter selve matematikken, men lekker informasjon gjennom hvor lang tid operasjoner tar eller hvordan prosessorens cache fylles. Både Salsa20 og ChaCha20 bruker utelukkende addisjon, XOR og rotasjon på fastbredde-register, uten en eneste oppslagstabell (S-boks). Det betyr at kjøretiden i en korrekt skrevet implementasjon ikke avhenger av hvilke bit som faktisk ligger i nøkkelen eller klarteksten, et egenskap kryptografer kaller konstant-tid.
Dette står i kontrast til programvareimplementasjoner av AES fra før AES-NI ble vanlig i prosessorer. Tabellbaserte AES-implementasjoner har historisk vært utsatt for cache-timing-angrep, der en angriper måler hvor lang tid minneoppslag tar for å gjette seg til deler av nøkkelen. Bernstein publiserte selv tidlig forskning på nettopp denne klassen svakheter i AES-implementasjoner, noe som var en direkte motivasjon for å designe Salsa20 uten tabelloppslag i utgangspunktet. ChaCha20 arver denne egenskapen fullt ut fra Salsa20, siden begge chifferfamiliene er bygget på nøyaktig samme type operasjoner, bare organisert forskjellig internt.
I praksis betyr dette at en gjennomsnittlig utvikler har mye mindre å bekymre seg for når de implementerer ChaCha20 eller Salsa20 i programvare, sammenlignet med å skrive en egen AES-implementasjon fra bunnen uten maskinvarestøtte. Moderne biblioteker som OpenSSL, BoringSSL og libsodium bruker riktignok AES-NI når den er tilgjengelig, noe som også eliminerer cache-timing-problemet for AES i praksis. Men på plattformer uten slik maskinvare, som mange eldre IoT-brikker og mikrokontrollere, er ARX-designet i ChaCha20 og Salsa20 et reelt sikkerhetsargument, ikke bare et ytelsesargument.
Sikkerhet og kryptoanalyse: hvor mange runder er brutt
Ingen praktisk angrep er kjent mot fullrunde Salsa20/20 eller ChaCha20. Det er verdt å slå fast tydelig, fordi begge chiffer ofte blir misforstått som “brutt” i nettdiskusjoner som i realiteten refererer til forskningsresultater mot kraftig reduserte rundetall.
Historien om Salsa20-kryptoanalyse startet i 2005, da Paul Crowley publiserte et angrep mot Salsa20/5 med en tidskompleksitet på 2^165 operasjoner og vant Bernsteins utlovede pris på 1000 dollar for den mest interessante Salsa20-kryptoanalysen det året. I 2006 fulgte Fischer, Meier, Berbain, Biasse og Robshaw opp med et angrep på Salsa20/6 ved 2^177, samt et relatert-nøkkel-angrep på Salsa20/7 ved 2^217. I 2007 hevdet Tsunoo og kolleger å bryte Salsa20/8 og gjenvinne den 256-bit hemmelige nøkkelen i 2^255 operasjoner ved bruk av 2^11,37 keystream-par, men dette angrepet var ikke konkurransedyktig med rått brute force og regnes derfor ikke som et reelt gjennombrudd.
Det mest siterte resultatet kom i 2008, da Aumasson, Fischer, Khazaei, Meier og Rechberger publiserte “New Features of Latin Dances”, et angrep mot Salsa20/7 ved tidskompleksitet 2^151 og mot Salsa20/8 ved 2^251 operasjoner, ved bruk av 2^31 keystream-par. Samme forskergruppe testet den samme teknikken mot ChaCha og fant at angrepet brøt 256-bit ChaCha6 ved kompleksitet 2^139 og ChaCha7 ved 2^248, samt 128-bit ChaCha6 ved 2^107. Angrepet mislyktes derimot mot 128-bit ChaCha7, som dermed sto seg mot den samme teknikken som brøt det tilsvarende rundetallet i Salsa20. I 2012 forbedret Shi og kolleger Aumassons teknikk, og brøt Salsa20/7 med 128-bit nøkkel ved 2^109 og Salsa20/8 med 256-bit nøkkel ved 2^250. I 2013 beviste Mouha og Preneel at 15 runder av Salsa20 er 128-bit sikker mot differensiell kryptoanalyse, det finnes ingen differensiell karakteristikk med høyere sannsynlighet enn 2^-130.
Det praktiske bildet etter nesten to tiår med forskning: ingenting kommer i nærheten av å true de 20 fullrundene som faktisk brukes i produksjon. Sikkerhetsmarginen i begge design er betydelig, og de beste angrepene bryter under halvparten av rundetallet selv med toppmoderne teknikker.
ChaCha20-Poly1305: hvordan AEAD-konstruksjonen fungerer
En strømchiffer alene gir bare konfidensialitet, ikke integritet. Derfor kombineres ChaCha20 nesten alltid med Poly1305, en MAC-algoritme også designet av Bernstein, i en kombinert AEAD-konstruksjon (Authenticated Encryption with Associated Data). RFC 7539, senere obsoletert av RFC 8439, spesifiserer nøyaktig hvordan de to primitivene settes sammen: ChaCha20 genererer en engangsnøkkel for Poly1305 fra blokk null av keystreamen, krypterer deretter selve meldingen fra blokk én og utover, og Poly1305 beregner til slutt en autentiseringstag over det krypterte innholdet pluss eventuelle tilleggsdata som ikke er kryptert, som protokoll-headere.
Salsa20 har ingen tilsvarende offisiell AEAD-standard. Enkelte biblioteker setter sammen Salsa20 eller XSalsa20 med en separat MAC manuelt, men dette er nøyaktig den typen gjør-det-selv-konstruksjon som NIST og IETF begge fraråder, fordi feil i hvordan nøkler deles mellom kryptering og autentisering historisk har ført til alvorlige sårbarheter. Dette er en av de klareste praktiske grunnene til at nye protokoller velger ChaCha20-Poly1305 fremfor å bygge egne løsninger rundt Salsa20.
Virkelig bruk: fem protokoller som har valgt side
Teori er fint, men adopsjon i skarpe produksjonssystemer er det som egentlig avgjør hvilken algoritme utviklere bør lære seg først.
- TLS 1.3: Standarden definerer cipher suiten TLS_CHACHA20_POLY1305_SHA256 som et fullverdig alternativ til AES-GCM-suitene. Nettlesere og servere forhandler typisk AES-GCM når maskinvareakselerasjon finnes, og ChaCha20-Poly1305 på enheter uten den.
- WireGuard: Hele VPN-protokollen bruker ChaCha20-Poly1305 som sin eneste autentiserte krypteringsprimitiv, et bevisst designvalg for å holde kodebasen liten og konsistent på tvers av plattformer.
- OpenSSH: Cipher-navnet [email protected] har vært tilgjengelig i årevis og brukes ofte som standardvalg i moderne SSH-oppsett, spesielt på servere uten AES-maskinvare.
- Android Adiantum: Som nevnt tidligere bruker Googles diskkrypteringsdesign for budsjettelefoner ChaCha12 kombinert med en hash-funksjon, nettopp fordi mange lavprisbrikker mangler AES-instruksjoner.
- Linux-kjernen: Moderne kjerneversjoner bruker ChaCha-familien som en del av implementasjonen av /dev/urandom, kjernens tilfeldighetsgenerator, der rask og forutsigbar programvareytelse er viktigere enn maskinvareakselerasjon.
- libsodium: Biblioteket tilbyr begge familiene. crypto_secretbox bygger historisk på XSalsa20, mens biblioteket også eksponerer rene ChaCha20-Poly1305-funksjoner for team som trenger IETF-kompatibilitet mot andre systemer.
Et interessant sidespor, godt dokumentert på ianix.com sin oversikt over Salsa20-adopsjon, er at ChaChas rundefunksjon også ligger til grunn for hash-familien BLAKE, en av finalistene i NISTs SHA-3-konkurranse, og dens raskere etterfølgere BLAKE2 og BLAKE3. Bernsteins designvalg fra 2008 lever dermed videre langt utover selve strømchifferet, i hashfunksjoner som i dag brukes i alt fra Git-verifisering til moderne blokkjeder.
Kostnad og driftsoverhead ved valg av chiffer
Et vanlig spørsmål fra team som vurderer skifte: hva kommer det til å koste å bytte? Her er det gode nyheter. Begge algoritmer er royaltyfrie og i det offentlige domene, uten lisensavgifter uansett hvor mye trafikk man krypterer. Den reelle kostnaden ligger ikke i selve algoritmen, men i integrasjonsarbeid, revisjon og hvilken infrastruktur man allerede har bygget opp.
For et selskap som driver egen sikkerhetsrevisjon eller betaler et eksternt revisjonsfirma for å gå gjennom kryptografikoden, er tidsbruken ofte den største enkeltposten i et slikt prosjekt. En revisor som allerede kjenner RFC 8439 og ChaCha20-Poly1305 fra tidligere oppdrag, bruker normalt kortere tid på å godkjene en implementasjon enn på en egendefinert sammensetning av Salsa20 og en separat MAC, nettopp fordi standardiserte konstruksjoner har færre steder hvor noe kan gå feil. Dette er en indirekte kostnad som sjelden dukker opp i en teknisk sammenligning, men som i praksis kan utgjøre flere dagsverk ekstra for et team uten tidligere erfaring med AEAD-konstruksjoner.
Det finnes heller ingen skjult driftskostnad knyttet til selve CPU-forbruket. Siden begge algoritmer kjører uten maskinvareakselerasjon og begge ligger i samme størrelsesorden i sykler per byte, vil forskjellen i skyregning for prosessortid typisk være umulig å måle for en vanlig webtjeneste. Den eneste situasjonen der CPU-kostnaden faktisk blir synlig, er ved svært høyt trafikkvolum på eldre maskinvare uten AES-akselerasjon, der selv en forskjell på få prosent kan utgjøre reelle serverkostnader over tid.
| Kostnadsfaktor | ChaCha20-Poly1305 | Salsa20 / XSalsa20 |
|---|---|---|
| Lisens og royalty | Gratis, offentlig domene | Gratis, offentlig domene |
| Bibliotekstøtte | Bred: OpenSSL, BoringSSL, libsodium, Go, Rust | Begrenset: primært libsodium og nisjebiblioteker |
| Integrasjonstid (ny protokoll) | Lav, ferdige TLS- og SSH-implementasjoner finnes | Høyere, krever egen AEAD-sammenstilling |
| Krav til spesialmaskinvare | Ingen | Ingen |
| Revisjonskostnad | Lavere, standardisert i RFC 8439 gir færre designvalg å revidere | Høyere ved egendefinert AEAD-bruk |
| Vedlikehold over tid | Aktivt oppdatert i alle store biblioteker | Stabilt, men færre nye implementasjoner |
Den klareste kostnadsforskjellen handler altså om utviklertid, ikke om maskinvare eller lisenser. Et team som allerede bruker libsodiums secretbox og XSalsa20, betaler i praksis en migreringskostnad hvis de bytter til ChaCha20-Poly1305, mens et team som bygger en ny tjeneste fra bunnen sparer tid ved å gå rett på ChaCha20-Poly1305, siden støtten er mer utbredt i moderne rammeverk.
Når bør du velge ChaCha20, og når passer Salsa20 bedre?
Basert på adopsjonsmønstrene og ytelsestallene over, er det mulig å gi konkrete anbefalinger for ulike bruksområder.
- Nye web-API-er og mikrotjenester: Velg ChaCha20-Poly1305 via TLS 1.3. Standardisert, godt testet, og støttet av alle moderne HTTP-biblioteker uten ekstra arbeid.
- VPN og tunnelprotokoller: Følg WireGuards eksempel og bruk ChaCha20-Poly1305 direkte, spesielt hvis klienter spenner fra kraftige servere til billige IoT-enheter.
- Mobilapper uten AES-maskinvare: ChaCha20-Poly1305 gir jevnere ytelse enn programvarebasert AES-GCM på eldre eller budsjettorienterte brikker.
- Eksisterende libsodium-baserte systemer: Hvis crypto_secretbox og XSalsa20 allerede er i produksjon og fungerer, er det sjelden god prioritering å migrere bare for migreringens skyld. Behold Salsa20-baserte funksjoner der de allerede er revidert og i drift.
- Innebygde systemer og IoT: Begge fungerer uten maskinvareakselerasjon, men ChaCha20 har noe bredere bibliotekstøtte på small footprint-plattformer i 2026, noe som ofte avgjør valget i praksis.
- Diskkryptering på budsjettenheter: Se til Adiantum-modellen med ChaCha12 kombinert med en hash-konstruksjon, fremfor å bygge en egen løsning med Salsa20.
Migreringsguide: fra Salsa20/XSalsa20 til ChaCha20-Poly1305
For team som bestemmer seg for å gå over fra en eksisterende Salsa20-basert løsning til ChaCha20-Poly1305, er dette de praktiske stegene som reduserer risikoen for feil under overgangen.
- Kartlegg alle steder i kodebasen der crypto_secretbox, XSalsa20 eller rå Salsa20 brukes, inkludert eventuelle interne biblioteker og tredjepartsavhengigheter.
- Identifiser hvilken nonce-strategi som brukes i dag (tilfeldig, tellerbasert, eller avledet), siden ChaCha20-Poly1305 i IETF-form krever en 96-bit nonce som må håndteres annerledes enn XSalsa20s 192-bit nonce.
- Velg en vedlikeholdt implementasjon, for eksempel libsodiums crypto_aead_chacha20poly1305_ietf-funksjoner, i stedet for å skrive egen AEAD-logikk.
- Bygg en kompatibilitetslag som kan dekryptere gamle meldinger kryptert med XSalsa20, samtidig som nye meldinger krypteres med ChaCha20-Poly1305, for en gradvis overgang uten brudd i eksisterende data.
- Oppdater nøkkelrotasjonsrutiner slik at hver nøkkel- og nonce-kombinasjon aldri krypterer mer enn omtrent 256 gigabyte, grensen satt av den 32-bit blokktelleren i IETF-varianten.
- Kjør parallelle testsuiter som verifiserer at krypterte og dekrypterte meldinger er identiske mellom gammel og ny implementasjon, med offisielle testvektorer fra RFC 8439.
- Rull ut endringen gradvis, gjerne bak en feature-flagg, og overvåk feilrater på dekryptering før den gamle XSalsa20-stien fjernes helt.
- Dokumenter migreringen og oppdater sikkerhetsrevisjonen slik at neste revisor ser nøyaktig hvilken AEAD-konstruksjon som er i bruk hvor.
Fordeler og ulemper
En kort oppsummering av styrker og svakheter gjør valget enklere for team som skal bestemme seg raskt.
ChaCha20-Poly1305
- Fordel: Standardisert i RFC 8439, med bred støtte i TLS 1.3, WireGuard, OpenSSH og alle store krypteringsbiblioteker.
- Fordel: 50 prosent mer diffusjon per kvartrunde enn Salsa20, uten ekstra regneoperasjoner.
- Fordel: Offisiell, revidert AEAD-konstruksjon sammen med Poly1305, uten behov for egendefinert sammensetting.
- Fordel: 96-bit nonce gjør tilfeldig nonce-generering praktisk trygg i høyvolumsystemer.
- Ulempe: Ikke en NIST-godkjent FIPS-algoritme, noe som kan være et hinder i enkelte myndighets- og forsvarsmiljøer som krever FIPS 140-validert kryptografi.
- Ulempe: 32-bit blokkteller i IETF-varianten begrenser en nøkkel/nonce-kombinasjon til rundt 256 gigabyte data.
Salsa20 / XSalsa20
- Fordel: Lengre historie med offentlig kryptoanalyse, godt forstått sikkerhetsmargin siden 2005.
- Fordel: XSalsa20s 192-bit nonce fjerner praktisk talt all kollisjonsrisiko selv ved ekstreme meldingsvolum.
- Fordel: Godt integrert i libsodiums mest brukte og mest reviderte API, crypto_secretbox.
- Ulempe: Ingen egen IETF- eller NIST-standard å støtte seg på ved revisjon eller compliance-arbeid.
- Ulempe: Mangler en offisiell AEAD-konstruksjon, noe som tvinger utviklere til å sette sammen kryptering og autentisering manuelt.
- Ulempe: Svakere diffusjon per runde enn ChaCha20, selv om ingen praktisk angrep utnytter dette ved fulle 20 runder.
Hva sier kryptografen selv?
Daniel J. Bernstein har selv beskrevet designvalgene bak ChaCha i detalj i det originale papiret fra 2008. Fire sitater fra den teksten oppsummerer kjernen i forskjellen bedre enn noen sekundærkilde kan:
“ChaCha will provide better overall speed than Salsa20 for the same level of security.” (På norsk: ChaCha vil gi bedre total hastighet enn Salsa20 ved samme sikkerhetsnivå.)
Daniel J. Bernstein, kryptograf og designer av Salsa20 og ChaCha, ChaCha-papiret (2008)
Denne påstanden er betinget, ikke absolutt. Bernstein understreker selv at fordelen bare gjelder dersom ChaCha faktisk kan kjøre med samme eller lavere minimum sikre rundetall som Salsa20, en hypotese han spekulerte i allerede i 2008 og som senere kryptoanalyse langt på vei har støttet.
“Less obvious is that the ChaCha quarter-round diffuses changes through bits more quickly than the Salsa20 quarter-round.” (På norsk: Mindre åpenbart er det at ChaChas kvartrunde diffunderer endringer gjennom bit raskere enn Salsa20s kvartrunde.)
Daniel J. Bernstein, ChaCha-papiret (2008)
“This double-speed update is the most important difference between ChaCha and Salsa20.” (På norsk: Denne dobbeltraske oppdateringen er den viktigste forskjellen mellom ChaCha og Salsa20.)
Daniel J. Bernstein, ChaCha-papiret (2008)
Bernstein omtaler her selv diffusjonsforbedringen, fra 8 til 12,5 output-bit per kvartrunde, som den enkeltstående viktigste designendringen i hele ChaCha-konstruksjonen. Alt annet, som rotasjonskonstantene og ordrekkefølgen, er i hans egen fremstilling underordnet denne ene forbedringen.
“ChaCha is a variant of the Salsa20 family of stream ciphers.” (På norsk: ChaCha er en variant av Salsa20-familien av strømchiffer.)
Daniel J. Bernstein, offisiell ChaCha-side (cr.yp.to)
Dette siste sitatet er en god påminnelse om at ChaCha20 aldri var tenkt som en etterfølger som gjør forgjengeren overflødig. Begge lever videre i produksjon i 2026, bare i forskjellige deler av økosystemet.
Hvor godt rustet er de mot kvantedatamaskiner?
Et spørsmål som dukker opp oftere i 2026 enn for få år tilbake: tåler ChaCha20 og Salsa20 fremtidige kvantedatamaskiner? Svaret er mer betryggende enn for asymmetrisk kryptografi som RSA og elliptisk kurve-kryptografi, som er sårbare for Shors algoritme og derfor må erstattes helt av nye konstruksjoner som ML-KEM. Symmetriske strømchiffer som ChaCha20 og Salsa20 trues ikke på samme fundamentale måte.
Den relevante kvantealgoritmen her er Grovers algoritme, som i teorien kan halvere den effektive sikkerhetsmarginen til en symmetrisk nøkkel ved brute force-søk. For en 256-bit nøkkel, som er standardstørrelsen i både ChaCha20 og Salsa20/20, betyr det et teoretisk sikkerhetsnivå på rundt 128 bit mot en kvantedatamaskin som faktisk kan kjøre Grovers algoritme i praksis. 128-bit sikkerhet regnes fortsatt som solid i et post-kvante-perspektiv, og det er grunnen til at NIST og andre standardiseringsorganer ikke har satt noen frist for å fase ut ChaCha20 eller Salsa20 av kvantehensyn, i motsetning til den konkrete 2030-fristen som er satt for utfasing av flere asymmetriske algoritmer.
Den praktiske konsekvensen er at team som bygger nye systemer i 2026 ikke trenger å bytte bort ChaCha20-Poly1305 eller XSalsa20 av ren kvanteangst. Det som faktisk krever oppgradering i et post-kvante-perspektiv, er nøkkelutvekslingen rundt selve strømchifferet, altså hvordan nøkkelen kommer frem til begge parter i utgangspunktet. Her beveger TLS 1.3-implementasjoner seg allerede mot hybride konstruksjoner som kombinerer klassisk X25519 med ML-KEM, mens selve den symmetriske krypteringen med ChaCha20-Poly1305 eller AES-GCM fortsetter som normalt. Det er med andre ord nøkkelutvekslingen, ikke selve bulk-krypteringen, som er brennpunktet i overgangen til post-kvante-sikkerhet.
Verdikt: hvilken bør du velge i 2026?
Tallene peker i samme retning fra alle tre benchmark-kilder vi har gått gjennom: ChaCha20 og Salsa20 ligger innenfor 10 til 15 prosent av hverandre i ren programvareytelse, uavhengig av om man ser på Bernsteins egne 2008-tall, Wikipedias sykluser-per-byte-referanser, eller den ferske IJCRT-studien fra august 2026. Ingen av algoritmene er svakere i praksis, siden ingen fullrundeangrep eksisterer mot noen av dem.
Det som faktisk avgjør valget i 2026, er økosystemet rundt algoritmen, ikke algoritmen selv. ChaCha20-Poly1305 vinner på standardisering: RFC 8439, TLS 1.3-integrasjon, WireGuard, OpenSSH og bred bibliotekstøtte gjør den til et tryggere valg for nye prosjekter, rett og slett fordi færre ting kan gå feil når infrastrukturen rundt algoritmen allerede er ferdigbygget og mye brukt. Salsa20 og XSalsa20 forblir et solid og fullt forsvarlig valg for systemer som allerede er bygget på libsodiums secretbox, uten at det finnes en god sikkerhetsmessig grunn til å haste gjennom en migrering bare for migreringens skyld.
Vår anbefaling for nye prosjekter i 2026: velg ChaCha20-Poly1305 som standard, bruk Salsa20 eller XSalsa20 kun der en eksisterende integrasjon allerede krever det.
Ofte stilte spørsmål
Er ChaCha20 raskere enn Salsa20?
Som regel, men marginalt. Bernsteins egne 2008-tall viser alt fra identisk hastighet til 28 prosent forsprang for ChaCha, avhengig av prosessor. Den ferske IJCRT-studien fra 2026 viser ChaCha20 konsekvent noen prosent foran Salsa20 i en Python-basert simulering, men forspranget er aldri dramatisk.
Kan Salsa20 eller ChaCha20 knekkes?
Ingen praktisk angrep eksisterer mot de fulle 20-runde-versjonene av noen av algoritmene. De beste publiserte angrepene bryter rundt 8 av 20 runder, med tidskompleksiteter langt over det som er gjennomførbart i praksis, som 2^250 operasjoner for Salsa20/8.
Hvorfor bruker WireGuard ChaCha20 og ikke AES?
WireGuard valgte ChaCha20-Poly1305 for å holde kodebasen liten og for å garantere jevn ytelse på enheter uten AES-maskinvareakselerasjon, som mange rutere, IoT-enheter og eldre mobilbrikker.
Hva er forskjellen mellom ChaCha20 og XChaCha20?
ChaCha20 i IETF-form (RFC 8439) bruker en 96-bit nonce. XChaCha20 er en utvidelse som støtter en 192-bit nonce, analogt med hvordan XSalsa20 utvider den klassiske Salsa20-nonce-en, og brukes der man ønsker trygg tilfeldig nonce-generering ved svært høyt meldingsvolum.
Er ChaCha20-Poly1305 godkjent av NIST?
ChaCha20-Poly1305 er standardisert gjennom IETF i RFC 8439, ikke gjennom en NIST FIPS-publikasjon. For systemer som krever FIPS 140-validert kryptografi, er AES-GCM fortsatt det vanlige valget, selv om ChaCha20-Poly1305 er ansett som kryptografisk likeverdig av det bredere fagmiljøet.
Bruker Android ChaCha20 eller ChaCha12?
Googles Adiantum-diskkryptering for budsjett-Android-telefoner uten AES-maskinvare bruker spesifikt ChaCha12, en redusert-runde-variant, kombinert med en hash-basert konstruksjon, ikke den fulle ChaCha20-varianten som brukes i TLS og WireGuard.
Bør jeg migrere et eksisterende XSalsa20-system til ChaCha20?
Ikke uten en konkret grunn. Hvis systemet allerede bruker libsodiums crypto_secretbox og er revidert, gir en migrering liten sikkerhetsmessig gevinst. Migrer heller når du bygger ny funksjonalitet, trenger IETF-kompatibilitet mot eksterne systemer, eller ønsker standardisert AEAD fremfor egendefinert sammensetting.