Säkra din organisations data med dessa krypteringsalgoritmer

Valet av krypteringsalgoritm avgör styrkan på ditt dataskydd: fel val kan göra data sårbara för brute-force-attacker, kända kryptanalytiska svagheter eller framtida hot från kvantberäkning. Datakryptering konverterar klartext till chiffertext som endast behöriga parter med rätt nyckel kan läsa. Rekommenderad åtgärd: använd AES-256-GCM för vilande data, TLS 1.3 med ECDHE för data under överföring, ECC P-256 eller RSA-3072 för asymmetriska operationer och undvik DES och 3DES i alla nya implementeringar. Nyckelhantering, inte själva algoritmen, är den vanligaste felpunkten i krypteringsimplementeringar.

Snabbt svar: Vilken krypteringsalgoritm bör din organisation använda?

Algoritmen beror på användningsfallet för dataskydd. För vilande data, använd AES-256-GCM: snabb, NIST-rekommenderad och tillhandahåller autentiserad kryptering som upptäcker manipulering utöver kryptering. För data under överföring, använd TLS 1.3 med AES-256-GCM- eller ChaCha20-Poly1305-krypteringssviter och ECDHE-nyckelutbyte för framåtriktad sekretess. För digitala signaturer och certifikat, använd ECDSA P-256 (föredras för nya distributioner på grund av mindre nyckelstorlek och snabbare operationer) eller RSA-3072 (minimum; RSA-2048 är det absoluta minimumet och föreslås för utfasning efter 2030 enligt NIST IR 8547). Undvik DES (56-bitars nyckel, trasig), 3DES (formellt föråldrad av NIST för nya applikationer 2019, Sweet32-sårbarhet), RC4 och MD5. Planera migrering av asymmetriska algoritmer till ML-KEM (FIPS 203) och ML-DSA (FIPS 204) för post-kvantumberedskap.

Jämförelse av krypteringsalgoritmer

Tabellen nedan jämför de vanligaste krypteringsalgoritmerna inom de dimensioner som är viktiga för säkerhetsbeslut. Den här bloggens tydliga fokus är vägledning för operativt urval: vilken algoritm för vilket användningsfall och varför, med explicit NIST-efterlevnadsstatus för varje.

Algoritm	Typ	Nyckelstorlek	Säkerhetsstyrka	Fart	NIST-status	Använda för
AES-128-GCM	Symmetrisk blockchiffer (AEAD)	128 bitar	128-bitars (post-quantum: ~64-bitars)	Mycket snabb (hårdvaruaccelererad)	Godkänd; FIPS 197	Vilande data, TLS-sessionskryptering
AES-256-GCM	Symmetrisk blockchiffer (AEAD)	256 bitar	256-bitars (post-quantum: ~128-bitars)	Snabb (hårdvaruaccelererad)	Godkänd; FIPS 197; CNSA 2.0 krävs för nationell säkerhet	Vilande data, data under överföring, data med högst känslighet
ChaCha20-Poly1305	Symmetrisk strömchiffer (AEAD)	256 bitar	256-bitars	Mycket snabb (ingen hårdvaruacceleration behövs)	Godkänd; används i TLS 1.3	TLS-sessionskryptering; mobil och IoT där AES-NI inte är tillgängligt
RSA-2048	Asymmetrisk (publik nyckel)	2048-bitars modul	112-bitars	Långsam för signering; snabb för verifiering	Godkänd till och med 2030; föreslagen utfasning efter 2030 enligt NIST IR 8547	TLS-certifikat, nyckelutbyte (äldre); kodsignering (minimum)
RSA-3072	Asymmetrisk (publik nyckel)	3072-bitars modul	128-bitars	Långsammare än RSA-2048	Godkänd; rekommenderas för nya RSA-distributioner	Ny RSA-baserad certifikat- och signaturinfrastruktur
ECDSA P-256	Asymmetrisk (elliptisk kurva)	256-bitars punkt	128-bitars	Snabb	Godkänd; FIPS 186-5	TLS-certifikat, kodsignering, digitala signaturer (föredras framför RSA-3072 för nya implementeringar)
3DES (Trippel DES)	Symmetrisk blockchiffer	168-bitars nominell (112-bitars effektiv)	112-bitars effektiv (Sweet32-attack på 64-bitars blockstorlek)	Sakta	Föråldrad för nya applikationer (NIST SP 800-131A Rev. 2, 2019)	Endast äldre verifiering; använd inte för ny kryptering
DES	Symmetrisk blockchiffer	56 bitar	Mindre än 56-bitars (uttömmande nyckelsökning möjlig)	Sakta	Inte godkänd; ogiltigförklarad	Använd inte

Prestanda: Det som är viktigt i praktiken

Algoritmprestanda är relevant men sällan den primära beslutsfaktorn för de flesta organisationer. Moderna processorer med AES-NI (AES Native Instructions) hårdvaruacceleration kör AES-256-GCM tillräckligt snabbt för att algoritmprestanda vanligtvis inte är en flaskhals för datakryptering i vila eller under överföring, inte ens vid hög dataflödeshastighet. De prestandadimensioner som spelar roll i praktiken:

• Symmetrisk kryptering (AES-256-GCM vs. ChaCha20-Poly1305): På hårdvara med AES-NI är AES-256-GCM vanligtvis snabbare. På mobil eller IoT-hårdvara utan AES-NI är ChaCha20-Poly1305 betydligt snabbare. TLS 1.3 stöder båda och förhandlar baserat på klient- och serverkapacitet.
• Asymmetriska operationer (RSA vs. ECC): RSA-verifiering (operation med offentlig nyckel) är snabb; RSA-signering (operation med privat nyckel) är långsam. ECDSA P-256-signering är betydligt snabbare än RSA-3072-signering vid motsvarande säkerhetsstyrka, vilket är viktigt för kodsignering med hög datakapacitet eller certifikatutfärdande. ECDSA-verifiering är något långsammare än RSA-verifiering.
• Nyckelstorlekens inverkan på lagring och bandbredd: Ett RSA-3072-certifikat är ungefär 6 gånger större än ett ECDSA P-256-certifikat med motsvarande säkerhet. För DNSSEC (där svar måste passa i UDP-paket) och mobilapplikationer (där bandbredd och latens spelar roll) minskar ECC-nyckelstorlekar avsevärt overheadkostnaderna.

AES: Standarden för symmetrisk kryptering

AES (Advanced Encryption Standard) valdes ut av NIST år 2001 efter en offentlig tävling och definieras i FIPS 197. Det är den universellt accepterade standarden för symmetrisk kryptering inom myndigheter, finansiella tjänster, sjukvård och de flesta andra branscher. AES är en blockchiffer som bearbetar 128-bitarsblock med hjälp av substitutions-permutationsoperationer som tillämpas i omgångar:

Nyckelstorlek	Omgångar	Säkerhetsstyrka	Användningsfall
128 bitar	10	128-bitars (~64-bitars post-quantum med Grovers)	Standard datakryptering; TLS-sessionsnycklar
192 bitar	12	192-bitars	Sekretessbelagd information på nivån ”Hemlig” (amerikanska regeringen)
256 bitar	14	256-bitars (~128-bitars post-quantum med Grovers)	Data med högsta känslighet; CNSA 2.0-krav; standardrekommendation för nya implementeringar

AES-krypteringsprocessen består av fyra operationer som tillämpas i varje omgång: SubBytes (icke-linjär bytesubstitution med S-Box), ShiftRows (cyklisk byteförskjutning inom rader i 4×4-tillståndsmatrisen), MixColumns (linjär blandning över kolumner för diffusion) och AddRoundKey (XOR med rundningsnyckeln härledd från chiffernyckeln). Den sista omgången utelämnar MixColumns. Dekryptering tillämpar inversen av varje operation i omvänd ordning.

Algoritmval: Vilken som ska användas för vilket användningsfall

Användningsfall	Rekommenderad algoritm	Undvik	Hänvisning
Vilande data (databaser, filsystem, säkerhetskopior)	AES-256-GCM	DES, 3DES, AES-ECB (ingen integritet), AES-CBC utan MAC	NIST SP 800-111; FIPS 197
Data under överföring (TLS)	TLS 1.3 med AES-256-GCM eller ChaCha20-Poly1305; ECDHE-nyckelutbyte	SSL 3.0, TLS 1.0/1.1, RC4, 3DES-krypteringssviter	NIST SP 800-52 Rev. 2
Digitala signaturer och certifikat	ECDSA P-256 (föredraget) eller RSA-3072 (minimum för ny RSA); RSASSA-PSS för RSA	RSA-1024, RSA-2048 för ny långlivad infrastruktur, DSA	NIST FIPS 186-5; NIST IR 8547
Nyckelutbyte / inkapsling	ECDH P-256 eller X25519; postkvantum: ML-KEM (FIPS 203)	RSA-nyckelutbyte (ingen framåtriktad sekretess); statisk DH	NIST SP 800-56A Rev. 3; FIPS 203
Hashing (integritet, signaturer)	SHA-256 eller SHA-384	MD5, SHA-1 (båda trasiga för kollisionsskydd)	NIST FIPS 180-4; NIST SP 800-131A
Mobil och IoT (ingen AES-NI-hårdvara)	ChaCha20-Poly1305 för kryptering; Ed25519 för signaturer	DES, RC4, svaga chiffersviter	RFC 8439 (ChaCha20-Poly1305); RFC 8032 (Ed25519)
Postkvantmigration (asymmetrisk)	ML-KEM (FIPS 203) för nyckelutbyte; ML-DSA (FIPS 204) för signaturer	RSA och ECC ensamma för ny långlivad infrastruktur	NIST FIPS 203, 204, 205; NIST IR 8547

Implementeringsexempel: Flerskiktskryptering i en miljö för finansiella tjänster

En finansiell tjänsteorganisation som krypterar kunders finansiella register och transaktionsdata implementerar följande algoritmstack:

1. Vilande data (kryptering av databasfält): AES-256-GCM med krypteringsnycklar per post (DEK). Varje DEK är inkapslad med en nyckelkrypteringsnyckel (KEK) lagrad i en HSM. HSM utför nyckeluppackningsoperationer inuti hårdvaran; KEK:n går aldrig in i applikationsminnet.
2. Vilande data (fullständig databaskryptering): AES-256-CBC med HMAC-SHA-256 (för kompatibilitet med databasens inbyggda krypteringsfunktion, som inte stöder GCM). AES-256-GCM på fältnivå används för de fält med högst känslighet (kontonummer, personnummer) där integritetsverifiering per post krävs.
3. Data under överföring (webbapplikationer för allmänheten): TLS 1.3 med AES-256-GCM-krypteringssvit. ECDHE P-256-nyckelutbyte ger framåtriktad sekretess. TLS-certifikat använder ECDSA P-256, vilket minskar certifikatstorleken och TLS-handskakningstiden jämfört med RSA-2048-certifikat.
4. Data under överföring (interna tjänst-till-tjänst-API:er): ömsesidig TLS (mTLS) med samma TLS 1.3-konfiguration. Både klienten och servern presenterar ECDSA P-256-certifikat, vilket ger kryptografisk autentisering av båda sidor av anslutningen.
5. Kodsignering för programvaruversioner: RSASSA-PSS med SHA-256 och RSA-3072, signering utförd inuti en HSM med hjälp av CodeSign SecureDen privata nyckeln för signering lämnar aldrig HSM.
6. PQC-planering: organisationens kryptografiska inventering (framtagen med hjälp av CBOM-säkerhet) identifierar alla RSA- och ECC-instanser. En stegvis migreringsplan prioriterar långlivade certifikathierarkier och kodsigneringsinfrastruktur för migrering till ML-DSA (FIPS 204) senast 2027.

Nyckelhantering: Den verkliga avgörande faktorn för krypteringseffektivitet

Krypteringsalgoritmens styrka spelar ingen roll om nycklarna komprometteras. En organisation som använder AES-256-GCM med en nyckel lagrad i en klartextkonfigurationsfil på samma server som den krypterade informationen har ungefär samma verkliga skydd som om den inte använder någon kryptering: alla angripare som läser den krypterade informationen kan också läsa nyckeln. Bästa praxis för nyckelhantering för organisatorisk datakryptering:

• Separera nycklar från krypterad data: Krypteringsnycklar får inte lagras på samma plats som de data de skyddar. Använd en dedikerad nyckelhanteringstjänst (KMS) eller Hardware Security Module (HSM) för att lagra och hantera krypteringsnycklar. Se HSM som en tjänst för hårdvarubaserad nyckellagring.
• Använd kuvertkryptering: kryptera enskilda poster eller filer med en datakrypteringsnyckel (DEK), och kryptera DEK:n med en nyckelkrypteringsnyckel (KEK) som lagras i KMS/HSM. Detta frikopplar nyckelrotation från dataåterkryptering: att rotera KEK:n är operativt mycket enklare än att omkryptera stora datamängder.
• Definiera kryptoperioder och framtvinga nyckelrotation: NIST SP 800-57 definierar rekommenderade kryptoperioder för olika nyckeltyper. Symmetriska datakrypteringsnycklar: två till tre år beroende på volym. RSA-privata nycklar: ett till tre år. Rotation kräver antingen att data krypteras om under den nya DEK eller (vid kuvertkryptering) att DEK omlindas under den nya KEK.
• Inventera alla kryptografiska tillgångar: organisationer kan inte skydda det de inte har kartlagt. CBOM-säkerhet upptäcker alla krypteringsnycklar, certifikat och algoritmer som distribuerats i din miljö, inklusive skuggimplementeringar och äldre algoritmer som kan ha distribuerats av enskilda utvecklingsteam utan centraliserad tillsyn.

Begränsningar och avvägningar

• Starkare algoritmer är inte alltid snabbare: AES-256 har 14 rundor jämfört med 10 för AES-128; de extra rundorna ökar beräkningskostnaden. På hårdvara med AES-NI är skillnaden försumbar för de flesta applikationer. På hårdvara utan AES-NI-acceleration kan AES-256 vara 30–40 % långsammare än AES-128.
• Asymmetriska algoritmer är inte lämpliga för masskryptering: RSA- och ECC-operationer är flera storleksordningar långsammare än AES för kryptering av stora mängder data. Asymmetrisk kryptering används för små dataelement (nycklar, signaturer, certifikat) medan symmetrisk kryptering hanterar massdata. Att försöka använda RSA för masskryptering av stora filer producerar opraktiskt långsamma krypteringshastigheter.
• Begränsningar för GCM-autentiseringstaggar: AES-GCM använder en 96-bitars nonce (initialiseringsvektor). Om noncen upprepas med samma nyckel bryts GCM-autentiseringen och både sekretessen och integriteten hos tidigare krypterad data kan äventyras. Noncehantering är avgörande: noncedata får aldrig återanvändas med samma GCM-nyckel. Nyckelrotation och nonceräknare per nyckel åtgärdar detta.
• Algoritmövergångar har driftskostnader: Att migrera från en algoritm till en annan kräver att befintliga data krypteras om, alla system som läser och skriver dessa data uppdateras och alla tillhörande nycklar och certifikat roteras. PQC-migrering för organisationer med stor RSA/ECC-infrastruktur är ett flerårigt program, inte en enskild åtgärd.

Slutsats

Algoritmval är utgångspunkten för kryptering, inte slutet. AES-256-GCM för data i vila, TLS 1.3 med ECDHE för data under överföring, och ECDSA P-256 eller RSA-3072 för signaturer representerar den nuvarande baslinjen för nya distributioner. Algoritmjämförelsen i det här inlägget ger ramverket för att göra det valet; de nyckelhanteringsmetoder som skyddar dessa nycklar avgör om krypteringen faktiskt ger det skydd den ska. Organisationer som vill veta var deras nuvarande algoritmdistribution står och var luckorna finns bör börja med en kryptografisk inventering. Om du vill ha vägledning om val av krypteringsalgoritm, nyckelhanteringsarkitektur eller PQC-migreringsplanering, kontakta Encryption Consulting . För relaterad läsning, se vårt inlägg om Symmetrisk vs. Asymmetrisk Kryptering.

Vanliga frågor om partihandel med mat och dryck

Vilken krypteringsalgoritm bör organisationer använda för data i vila?

AES-256-GCM är den rekommenderade algoritmen. Den tillhandahåller 256-bitars säkerhetsstyrka, autentiserad kryptering (upptäcker manipulering via GCM-autentiseringstagg), stöd för hårdvaruacceleration och är godkänd av NIST (FIPS 197) och krävs av CNSA 2.0 för nationella säkerhetssystem. AES-128-GCM är också acceptabelt för mindre känsliga data.

Vad är skillnaden mellan symmetrisk och asymmetrisk kryptering?

Symmetrisk kryptering använder samma nyckel för kryptering och dekryptering (AES, ChaCha20) och är snabb för bulkdata. Asymmetrisk kryptering använder ett nyckelpar (RSA, ECC) – publik nyckel för kryptering, privat nyckel för dekryptering – och är långsammare men löser problemet med nyckeldistribution. I praktiken används de tillsammans: asymmetrisk kryptering upprättar och utbyter säkert en symmetrisk sessionsnyckel för bulkkryptering.

Är AES-256 kvantsäkert?

AES-256 bibehåller ungefär 128-bitars effektiv säkerhet mot Grovers kvantalgoritm, vilket NIST anser vara tillräckligt. AES-128 är mer sårbar (ungefär 64-bitars effektiv post-kvantalgoritm). RSA och ECC är inte kvantsäkra: Shors algoritm kan bryta dem. NIST har standardiserade post-kvantalgoritmersättningar för asymmetriska algoritmer (ML-KEM/FIPS 203, ML-DSA/FIPS 204).

Varför avskrivs 3DES?

3DES har endast 112-bitars effektiv säkerhet (meet-in-the-middle-attacken minskar den från den nominella nyckellängden på 168 bitar), och dess blockstorlek på 64 bitar gör den sårbar för Sweet32-attacken på långvariga anslutningar, som är bundna till födelsedagsgränsen. NIST avfärdade formellt 3DES för nya applikationer i SP 800-131A Rev. 2 (2019). Använd AES istället.

När ska ECC användas istället för RSA?

ECC P-256 ger 128-bitars säkerhet med en 32-byte nyckel jämfört med RSA-3072:s 384-byte nyckel. ECC är att föredra för TLS-certifikat (mindre certifikatstorlekar), kodsignering (mindre signaturer), mobil och IoT (lägre beräkningskostnader) och DNSSEC. Använd RSA där kompatibilitet med äldre system kräver det; annars är ECC ett bättre val för nya implementeringar.

Vad är AES-GCM och varför är det att föredra framför AES-CBC?

AES-GCM tillhandahåller autentiserad kryptering: den krypterar data och inkluderar en GCM-autentiseringstagg som upptäcker eventuella ändringar av chiffertexten. AES-CBC tillhandahåller endast konfidentialitet, utan integritetskontroll. AES-CBC är också sårbart för utfyllnadsattacker från Oracle när det implementeras felaktigt. AES-GCM rekommenderas enligt NIST SP 800-38D för alla nya symmetriska krypteringsdistributioner.