Symmetrisk vs. asymmetrisk kryptering: De vanligaste användningsområdena 2025

Publicerad: juli 2025. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och kryptografirådgivningsteam.

Beskrivning

Varje säker anslutning, krypterad disk och signerad programvara är beroende av en av två kryptografiska metoder: symmetrisk kryptering eller asymmetrisk kryptering. Nyckelns natur definierar skillnaden mellan symmetrisk och asymmetrisk kryptering . Symmetrisk kryptering kräver en enda delad nyckel; asymmetrisk kryptering kräver ett matematiskt länkat offentligt och privat nyckelpar. Ingen av metoderna är universellt "bättre". Produktionssystem, från TLS till meddelandeappar, använder båda tillsammans, och att välja fel nyckel för ett givet jobb skapar verkliga prestanda-, nyckelhanterings- eller efterlevnadsproblem. Den här guiden täcker aktuella algoritmrekommendationer, en hotmodell som inkluderar kvantrisk, en praktisk urvalsprocess och var varje metod implementeras år 2026.

Vad är den centrala skillnaden mellan symmetrisk och asymmetrisk kryptering?

Symmetrisk kryptering använder en hemlig nyckel för att både kryptera och dekryptera data, så den som innehar nyckeln kan utföra båda operationerna. Asymmetrisk kryptering använder två matematiskt relaterade nycklar, en offentlig nyckel som vem som helst kan inneha och använda för att kryptera eller verifiera, och en privat nyckel som endast ägaren innehar och använder för att dekryptera eller signera. Den strukturella skillnaden är det som driver alla andra avvägningar mellan de två: symmetrisk kryptering är snabb men kräver att nyckeln når båda parter säkert i förväg, medan asymmetrisk kryptering löser nyckeldistribution på bekostnad av hastighet.

Vad är symmetrisk kryptering och vilken algoritm bör du använda?

Symmetrisk kryptering krypterar och dekrypterar data med en enda delad nyckel. En betrodd part genererar nyckeln, avsändaren krypterar klartext till chiffertext med den, chiffertexten färdas över nätverket eller lagras, och mottagaren dekrypterar den med samma nyckel. Säkerheten för hela systemet beror helt på att nyckeln aldrig når en obehörig part.

Rekommenderad algoritm och nyckelstorlek: använd AES-256 (Advanced Encryption Standard, 256-bitars nyckel) som standard. AES standardiserades av NIST i FIPS 197 år 2001 och är fortfarande den nuvarande federala standarden för symmetrisk blockkryptering; den har ingen praktisk kryptanalytisk brytning vid någon nyckelstorlek. AES-128 anses fortfarande vara säker, men AES-256 är standardrekommendationen där efterlevnadsramverk, PCI DSS-omfattning eller långlivad data är inblandade, och det kostar nästan ingenting i prestanda på modern hårdvara med AES-NI-acceleration.

När man ska använda ChaCha20 istället: ChaCha20-Poly1305 , standardiserad i RFC 8439 , är en strömchiffer med en inbyggd autentiserare (en AEAD-konstruktion, samma kategori som AES-GCM) som fungerar bra i programvara utan dedikerad AES-hårdvara. Det är den föredragna chiffern på mobila enheter, IoT-hårdvara med låg strömförbrukning och alla plattformar som saknar AES-NI, och det är en av de två chiffersvitfamiljer som varje TLS 1.3-implementering måste stödja. Ta bort äldre symmetriska chiffer: DES och single DES är trasiga, 3DES är föråldrad av NIST och förbjuden efter 2023 för ny användning, och RC4 har kända bias som utesluter det helt.

Symmetrisk kryptering passar väl för alla slutna system där nyckeln kan distribueras och lagras under egen kontroll:

Betalnings- och bankdata : kortnätverk och utgivare använder AES för att skydda kortinnehavardata i vila och under överföring, ett krav enligt PCI DSS.

Vilande data : verktyg för fullständiga diskkryptering som BitLocker (Windows) och FileVault (macOS) använder AES-256-XTS för att skydda data på bärbara datorer och hårddiskar när enheten är avstängd eller låst.

Databaskryptering : transparent datakryptering (TDE) i SQL Server-, Oracle- och PostgreSQL-tillägg krypterar datafiler och säkerhetskopior med AES för att skydda kundregister mot direkt filåtkomst.

Säkra meddelanden : Signal och WhatsApp krypterar meddelandeinnehåll med AES-256 i Signal-protokollet, efter att asymmetrisk nyckelutbyte använts för att konfigurera sessionsnyckeln.

Molnsäkerhetskopior och lagring : leverantörer som iCloud, Google Workspace, AWS S3 och Azure Blob Storage krypterar vilande data med AES-256, vanligtvis med nycklar som hanteras via ett moln-KMS.

Vad är asymmetrisk kryptering och vilken algoritm bör du använda?

Asymmetrisk kryptering använder ett matematiskt länkat nyckelpar. Data som krypterats med den publika nyckeln kan bara dekrypteras med den matchande privata nyckeln, så den publika nyckeln kan delas fritt medan den privata nyckeln förblir hemlig för sin ägare.

1. Offentlig nyckel: distribueras öppet och används för att kryptera data eller verifiera en signatur. Eftersom den inte kan dekryptera något själv, medför den ingen sekretessrisk om den exponeras.
2. Privat nyckel: hålls hemlig av sin ägare och används för att dekryptera data eller generera en signatur. Det är den enda felpunkten i hela schemat, vilket är anledningen till att privata produktionsnycklar hör hemma i en hårdvarusäkerhetsmodul (HSM) snarare än på disk.

Rekommenderade algoritmer och nyckelstorlekar: för kryptering och nyckelutbyte, använd RSA vid 3072 bitar eller större , eller ECC på kurva P-256 (secp256r1) eller starkare . Båda ger ungefär samma säkerhetsstyrka, cirka 128 bitar, men ECC-nycklar är mycket mindre och snabbare att beräkna med, vilket är anledningen till att de flesta moderna TLS-distributioner som standard använder ECDHE framför klassiskt RSA-nyckelutbyte. NIST SP 800-131A Revision 2 behandlar 2048-bitars RSA som acceptabelt fram till 2030 men rekommenderar att man övergår till 3072-bitarsnycklar nu för allt med lång säkerhetslivstid, och den tillåter inte 1024-bitars RSA och DSA helt.

För digitala signaturer är FIPS 186-5 , publicerad i februari 2023, den nuvarande standarden för digitala signaturer. Den behåller RSA och ECDSA, slopar DSA för ny signaturgenerering (endast verifiering) och lägger formellt till EdDSA (Ed25519 och Ed448) som godkända signaturalgoritmer, vilka nu är vanliga inom SSH och kodsignering eftersom de är snabba och motståndskraftiga mot flera implementeringsfallgropar som historiskt sett har påverkat ECDSA-noncegenerering.

Säker e-post : PGP och S/MIME använder asymmetrisk kryptering så att endast den avsedda mottagarens privata nyckel kan öppna ett meddelande.

Digitala signaturer : RSA, ECDSA och i allt högre grad Ed25519 signerar e-postmeddelanden, finansiella transaktioner och programvaruversioner, vilket ger mottagaren integritet och oförvitlighet som symmetrisk kryptering inte kan ge på egen hand.

Nyckelutbyte : Diffie-Hellman och dess elliptiska kurvvariant ECDHE låter två parter komma överens om en delad symmetrisk nyckel över ett öppet nätverk utan att någonsin överföra den nyckeln direkt.

Säker webbsurfning : TLS 1.3 använder ECDHE för nyckelutbyte och RSA- eller ECDSA-certifikat för serverautentisering under handskakningen, och växlar sedan till en symmetrisk chiffer för själva sessionen.

Internetbank, e-handel och blockkedja : transaktionssignering (till exempel ECDSA på kurvan secp256k1 i Bitcoin) bevisar äganderätt och godkänner en överföring utan att exponera den privata nyckeln.

Public Key Infrastructure (PKI) : certifikatutfärdare binder offentliga nycklar till verifierade identiteter via X.509-certifikat, vilket är hur webbläsare litar på en servers offentliga nyckel från första början.

Vilken hotmodell gäller, inklusive kvantrisk för asymmetriska algoritmer?

Symmetriska och asymmetriska algoritmer står inför väldigt olika hot. Att förstå båda är vad ett verkligt urvalsbeslut behöver, inte bara hastighet och nyckelstorlek.

Klassiska hot mot symmetrisk kryptering handlar nästan uteslutande om nyckelhantering snarare än själva chifferet: svag nyckelgenerering, nyckelåteranvändning, dålig rotation och osäker lagring orsakar betydligt fler verkliga intrång än någon teoretisk attack mot AES. AES-256 i sig har ingen praktisk kryptanalytisk attack.

Klassiska hot mot asymmetrisk kryptering inkluderar svag nyckelgenerering, otillräcklig nyckelstorlek (1024-bitars RSA är faktoriserad med tillräcklig beräkningsförmåga och är formellt otillåten), dålig utfyllnad (rå RSA utan OAEP eller PSS kan utnyttjas) och exponering av privata nycklar genom felkonfigurerade HSM:er, kodförråd eller säkerhetskopior.

Kvantrisk är asymmetrisk specifik. En tillräckligt stor, feltolerant kvantdator som kör Shors algoritm skulle kunna faktorisera RSA-moduler och lösa problemet med diskret logaritm med elliptisk kurva, vilket skulle bryta RSA och ECC/ECDSA/ECDH helt och hållet. Ingen sådan maskin existerar ännu, men risken är inte enbart i framtid: krypterad trafik som fångas upp idag kan dekrypteras senare när den funktionen väl finns, ett mönster som kallas "skörda nu, dekryptera senare". Det är därför NIST IR 8547 , fortfarande ett första offentligt utkast från mitten av 2026, föreslår att RSA, ECDSA, ECDH och finita fält-Diffie-Hellman-standarder avskrivs för ny federal användning efter 2030 och att de helt förbjuds efter 2035. NIST slutförde de första postkvantstandarderna i augusti 2024: FIPS 203 (ML-KEM, för nyckeletablering), FIPS 204 (ML-DSA, för signaturer) och FIPS 205 (SLH-DSA, ett konservativt hashbaserat signaturschema). Grovers algoritm påverkar även symmetriska chiffer, men bara kvadratiskt, vilket halverar AES-256:s effektiva säkerhetsmarginal till fortfarande robusta 128 bitar och AES-128:s till 64 bitar, vilket är just därför AES-256 snarare än AES-128 är den framåtblickande rekommendationen.

Nettoeffekt: symmetriska algoritmer behöver i princip ingen kvantdriven förändring utöver att föredra 256-bitarsnycklar. Asymmetriska algoritmer är de som behöver en migreringsplan, och den planen bör pågå nu snarare än att börja 2030. Se Encryption Consultings 9-fasguide för migrering av kvantkryptografi för den fullständiga färdplanen.

Hur väljer man mellan symmetrisk och asymmetrisk kryptering?

Använd den här sekvensen för att nå ett försvarbart val snarare än att som standard använda den algoritm som ett bibliotek skickar först:

1. Identifiera datavolymen. Massdata (filer, databaser, säkerhetskopior, diskar) pekar mot symmetrisk kryptering för den faktiska nyttolasten.
2. Identifiera om parterna redan delar en hemlighet. Om inte, och kanalen inte är betrodd, behöver du asymmetrisk nyckelutbyte eller ett PKI-utfärdat certifikat innan symmetrisk kryptering kan starta.
3. Avgör om du behöver identitet eller oförnekelse. Att bevisa vem som skickade något, eller att ett dokument inte har ändrats, kräver en digital signatur, som är asymmetrisk till sin konstruktion.
4. Kontrollera prestationsbudgeten. Hög dataflödeskänsliga, latenskänsliga sökvägar (massöverföring, lagringsmotorer, VPN-dataplan) bör minimera asymmetriska operationer endast till handskaknings- eller nyckelomslagssteget.
5. Bekräfta nyckelhanteringskapacitet. Symmetrisk kryptering i stor skala behöver ett KMS- eller HSM-baserat nyckellager och en rotationspolicy; asymmetrisk kryptering behöver en PKI med certifikatlivscykelhantering, återkallelse och HSM-skyddade privata nycklar.
6. Standardinställningen är hybrid. I praktiken använder nästan alla moderna protokoll (TLS, SSH, Signal, IPsec/IKEv2) asymmetriska metoder för att etablera förtroende och en symmetrisk nyckel, och växlar sedan till symmetrisk kryptering för själva datan. Bygg nya system på samma sätt istället för att välja enbart en algoritmtyp.

Symmetrisk vs. asymmetrisk kryptering: Beslutstabell

Symmetrisk och asymmetrisk kryptering löser olika problem, så den rätta jämförelsen är inte "vilken är bättre" utan "vilken passar den här uppgiften". Tabellen nedan sammanfattar de avvägningar som är viktigast för ett urvalsbeslut.

Aspect	Symmetrisk kryptering	Asymmetrisk kryptering
Nyckelanvändning	En nyckel för både kryptering och dekryptering	Publik nyckel krypterar eller verifierar; privat nyckel dekrypterar eller signerar
Fart	Mycket snabb; lämplig för bulkdata, hårdvaruaccelererad (AES-NI)	Mycket långsammare; används sparsamt, främst för handskakningar och signaturer
Nyckeldistribution	Kräver en säker kanal eller KMS för att dela den hemliga nyckeln	Den offentliga nyckeln kan delas öppet; ingen säker kanal behövs för att distribuera den
Vanligt användningsfall	Disk- och databaskryptering, VPN-dataplan, meddelandenyttolaster, säkerhetskopior	TLS-handskakning, digitala signaturer, kodsignering, certifikatutfärdande, nyckelutbyte
Nuvarande rekommenderade algoritmer	AES-256 (FIPS 197), ChaCha20-Poly1305 (RFC 8439)	RSA-3072+, ECC P-256+ (FIPS 186-5), Ed25519
Kvantsårbarhet	Låg; Grovers algoritm halverar bara den effektiva styrkan (AES-256 förblir på 128-bitars säkerhet)	Hög; Shors algoritm bryter RSA och ECC direkt när en kapabel kvantdator existerar.

Hur kombinerar hybridkryptering båda metoderna?

Hybridkryptering använder asymmetrisk kryptografi för att lösa problemet med nyckeldistribution och övergår sedan till symmetrisk kryptering för snabbare hantering. Asymmetriska algoritmer autentiserar parterna och etablerar en delad symmetrisk nyckel; den symmetriska nyckeln krypterar sedan själva applikationsdatan. TLS är det tydligaste exemplet: under TLS 1.3-handskakningen bevisar servern sin identitet med ett RSA- eller ECDSA-certifikat, båda sidor härleder en delad hemlighet med ECDHE, och varje byte i sessionen efteråt krypteras med AES-GCM eller ChaCha20-Poly1305.

Samma mönster syns även bortom TLS. Signal och WhatsApp använder Signalprotokollets X3DH-nyckelavtal (asymmetriskt) för att starta en session, sedan härleder Double Ratchet-algoritmen nya AES-256-nycklar (symmetriska) för varje meddelande. IPsec VPN:er använder IKEv2, ett asymmetriskt eller fördelat nyckelutbyte, för att förhandla fram AES-GCM-sessionsnycklar för själva tunneln; Encryption Consultings guide till post-quantum VPN-migrering täcker hur det nyckelutbytessteget förstärks med hybrid PQC-nyckelupprättande enligt RFC 9370. Från och med 2026 har stora webbläsare och CDN:er också börjat distribuera hybrid post-quantum-nyckelutbyte i TLS (kombinerar ECDHE med ML-KEM) just för att stänga gapet "harvest-nu-decrypt-later" i den asymmetriska halvan av handskakningen, samtidigt som den symmetriska chiffersviten lämnas oförändrad.

Vilka är avvägningarna mellan prestanda och interoperabilitet?

Symmetriska chiffer bearbetar massdata flera storleksordningar snabbare än asymmetriska chiffer för motsvarande säkerhetsstyrka, vilket är anledningen till att inget produktionssystem krypterar stora nyttolaster direkt med RSA eller ECC. På moderna processorer med AES-NI-instruktioner lägger AES-256-GCM till försumbar overhead; programvarubaserade miljöer utan den accelerationen fungerar ofta bättre med ChaCha20-Poly1305.

Asymmetriska operationer kostar mycket mer per byte och skalar sämre med datastorlek, vilket är just därför de är reserverade för en engångshandskakning, en signatur eller att omsluta en liten symmetrisk nyckel snarare än själva nyttolasten. Nyckelstorleken påverkar också interoperabiliteten: RSA-3072-certifikat och signaturer är märkbart större på kabeln än ECC P-256-ekvivalenter, vilket är viktigt på begränsade länkar och i protokoll med snäva paketbudgetar. ECC kräver moderna biblioteks- och TLS-versionsstöd (TLS 1.2 och 1.3, nuvarande OpenSSL, BoringSSL och molnleverantörs-SDK:er); vissa äldre inbäddade eller äldre företagsstackar stöder endast RSA, vilket är en verklig interoperabilitetsbegränsning vid planering av en migrering. Postkvantalgoritmer förvärrar detta: ML-KEM- och ML-DSA-publika nycklar och signaturer är betydligt större än deras RSA- eller ECC-motsvarigheter, vilket ökar TLS-handskakningsstorleken och kan påverka latens och MTU-beteende på begränsade nätverk, en faktor som är värd att testa innan en hybrid PQC-utrullning.

Vilka viktiga hanteringsberoenden har varje metod?

Ingen av algoritmtyperna är säkra utan disciplinerad nyckelhantering bakom sig.

Symmetrisk kryptering behöver ett sätt att få samma nyckel till varje behörig part utan att exponera den under överföring, och en policy för att rotera och ta bort nycklar. I praktiken innebär detta ett centraliserat nyckelhanteringssystem, oavsett om det är ett molnbaserat KMS (AWS KMS, Azure Key Vault, Google Cloud KMS) eller en lokal HSM, med åtkomstkontroller, granskningsloggning och kuvertkryptering så att själva datanyckeln omsluts av en huvudnyckel som aldrig lämnar HSM-gränsen.

Asymmetrisk kryptering kräver en komplett infrastruktur för publika nycklar: en certifikatutfärdare för att binda publika nycklar till verifierade identiteter, definierade certifikatprofiler och giltighetsperioder, återkallelse via CRL eller OCSP, och privata nycklar som genereras och lagras inuti FIPS 140-3-validerade HSM:er snarare än på allmänna servrar. Att förlora kontrollen över en privat nyckel är katastrofalt och vanligtvis oåterkalleligt utan att certifikatet återkallas och utfärdas på nytt; att förlora kontrollen över en symmetrisk nyckel är allvarligt men vanligtvis begränsat till de data som nyckeln skyddar.

Var distribueras symmetrisk och asymmetrisk kryptering år 2026?

• Webb- och API-trafikTLS 1.3 överallt, med ECDHE (alltmer hybrid med ML-KEM) för nyckelutbyte och AES-256-GCM eller ChaCha20-Poly1305 för sessionen.
• Företags-PKI: hantering av certifikatlivscykeln utfärdar RSA-3072- eller ECC P-256-certifikat för servrar, användare och maskinidentiteter, med kortare certifikatgiltighetsperioder som ökar den operativa belastningen på manuell utfärdande.
• KodsigneringRSA- eller ECDSA-signaturer framför byggartefakter, tidsstämplade och i allt högre grad nödvändiga för att komma från HSM-baserade nycklar snarare än utvecklararbetsstationer.
• VPN och fjärråtkomstIKEv2/IPsec använder asymmetrisk eller fördelad autentisering för att härleda AES-GCM-tunnelnycklar, med hybrid PQC-nyckelutbytesalternativ som nu ingår i aktuell firmware från större VPN-leverantörer.
• Slutpunkt och molnlagringAES-256-kryptering av fulldisk och objektlagring som standard, inte ett valfritt alternativ, hos större molnleverantörer.
• meddelandehanteringSignal Protocols asymmetriska X3DH-handskakning plus AES-256-meddelandekryptering, som används av Signal, WhatsApp och Google Messages (RCS).
• Regerings- och försvarssystemCNSA 2.0-riktlinjerna styr redan nationella säkerhetssystem mot ML-KEM och ML-DSA för nya asymmetriska användningsfall före den bredare civila tidslinjen.

Begränsningar

Symmetrisk kryptering skalar inte nyckeldistribution väl: varje nytt par av kommunicerande parter som inte kan använda en delad PKI eller KMS behöver sin egen säkert levererade nyckel, och algoritmen ger inget sätt att bevisa vem som krypterade ett meddelande, bara att den som innehar nyckeln skulle kunna ha gjort det. Asymmetrisk kryptering löser båda problemen men till en verklig beräknings- och driftskostnad: den är för långsam för bulkdata, dess nuvarande algoritmer (RSA, ECDSA, ECDH) står inför en definierad tidslinje för kvantrisk som ännu inte har producerat en slutgiltig, obligatorisk övergångsstandard, och post-kvantum-ersättningar medför större nycklar och signaturer som komplicerar begränsade enheter och stöd för äldre protokoll. Ingen av metoderna är ett komplett svar på nyckelhantering i sig, och ingen enskild artikel ersätter en kryptografisk inventering av vad din organisation faktiskt kör idag.

Vad skulle krypteringskonsulter rekommendera?

Börja med att behandla privata nycklar, oavsett om det är symmetriska huvudnycklar eller asymmetriska signeringsnycklar, som den tillgång som faktiskt behöver skyddas, inte algoritmvalet. Encryption Consultings HSM-as-a-Service placerar både symmetriska huvudnycklar och asymmetriska privata nycklar i FIPS 140-3-validerad hårdvara, utan kapitalkostnaden för att köra HSM:er internt.

För organisationer som utfärdar och hanterar certifikat i stor skala utformar vårt PKI-tjänsteteam certifikatprofiler, policyer för nyckelstorlekar och CP/CPS-dokumentation så att asymmetrisk nyckelutgivning matchar aktuell NIST-riktlinjer snarare än ärvda standardvärden från en tio år gammal CA-version.

Och eftersom kvantrisken specifikt ligger hos asymmetriska algoritmer, kör vår PQC-rådgivningsavdelning en migreringsfärdplan i nio faser, som börjar med en kryptografisk inventering av exakt var RSA, ECDSA, ECDH och Diffie-Hellman finns i din miljö, så migreringsbeslut baseras på bevis snarare än gissningar inför avvecklingsfönstret 2030.

Slutsats

Symmetrisk och asymmetrisk kryptering löser två olika delar av samma problem. Symmetrisk kryptering, byggd kring AES-256 eller ChaCha20-Poly1305, levererar den hastighet som behövs för bulkdata i banksystem, diskkryptering, databaser och meddelandeappar, förutsatt att nyckeln distribueras och lagras säkert. Asymmetrisk kryptering, byggd kring RSA-3072+, ECC P-256+ eller Ed25519, levererar nyckelutbyte, identitet och oförnekelse som symmetrisk kryptering inte kan ge, på bekostnad av hastighet och, på längre sikt, exponering för kvantberäkning genom Shors algoritm. Hybridkryptering, modellen bakom TLS, Signal och moderna VPN, är hur nästan alla verkliga system löser den kompromissen idag. Den öppna frågan för det kommande decenniet är inte symmetrisk kontra asymmetrisk, utan hur snabbt organisationer flyttar sina asymmetriska algoritmer till en post-kvantbas före övergångsfönstret 2030 till 2035 som NIST redan har lagt fram.

Vanliga frågor om partihandel med mat och dryck

Är AES symmetrisk eller asymmetrisk kryptering?
AES (Advanced Encryption Standard) är symmetrisk. Den använder en delad nyckel, i längder på 128, 192 eller 256 bitar, för både kryptering och dekryptering, enligt definitionen i FIPS 197.

Är RSA fortfarande säkert att använda år 2026?
Ja, förutsatt att du använder 3072-bitars eller större nycklar med korrekt utfyllnad (OAEP för kryptering, PSS för signaturer). NIST SP 800-131A Revision 2 behandlar 2048-bitars RSA som acceptabelt fram till 2030, men organisationer bör planera en post-kvantmigrering nu snarare än att vänta, eftersom RSA är på NIST IR 8547:s föreslagna avvecklingsväg efter 2030.

Kan kvantdatorer bryta AES-256?
Inte med någon känd algoritm. Grovers algoritm ger endast en kvadratisk hastighetsökning mot symmetriska chiffer, vilket minskar AES-256:s effektiva säkerhet till 128 bitar, vilket fortfarande anses säkert. Kvantrisken är koncentrerad till asymmetriska algoritmer som RSA och ECC, vilka Shors algoritm kan bryta helt.

Vad är hybridkryptering och varför använder de flesta system det?
Hybridkryptering använder asymmetrisk kryptografi för att autentisera parterna och säkert upprätta en delad symmetrisk nyckel, och använder sedan den symmetriska nyckeln för att kryptera själva informationen. TLS, SSH, Signal och IPsec fungerar alla på detta sätt eftersom de kombinerar asymmetrisk krypterings nyckeldistributionsstyrka med symmetrisk krypterings hastighet.

Behöver vi migrera till postkvantkryptografi just nu?
För de flesta organisationer, inte omedelbart, men planeringen bör börja nu. NIST har slutfört ML-KEM (FIPS 203), ML-DSA (FIPS 204) och SLH-DSA (FIPS 205), och NIST IR 8547 föreslår att RSA och ECC avvecklas efter 2030. Att bygga ett kryptografiskt inventarium idag är ett nödvändigt steg oavsett ditt slutliga migreringsdatum.

Referensprojekt

• NIST FIPS 197, avancerad krypteringsstandard (AES)
• NIST FIPS 186-5, Digital signaturstandard (DSS)
• NIST SP 800-131A Revision 2, Övergång till användning av kryptografiska algoritmer och nyckellängder
• NIST IR 8547 (inledande offentligt utkast), övergång till post-kvantkryptografistandarder
• NIST FIPS 203, standard för modulgitterbaserad nyckelinkapslingsmekanism (ML-KEM)
• NIST FIPS 204, modulgitterbaserad standard för digitala signaturer (ML-DSA)
• IETF RFC 8439, ChaCha20 och Poly1305 för IETF-protokoll
• IETF RFC 8446, Transport Layer Security (TLS)-protokollet version 1.3