Varför 3DES eller Triple DES officiellt pensioneras

Publicerad: mars 2022. Uppdaterad: augusti 2026. Granskad av Encryption Consultings krypteringsrådgivningsteam.

3DES, även kallad Triple DES eller TDEA (Triple Data Encryption Algorithm), är en symmetrisk blockchiffer byggd genom att köra den ursprungliga DES- algoritmen tre gånger per datablock med antingen två eller tre nycklar. NIST introducerade den på 1990-talet som en tillfällig lösning efter att DES 56-bitarsnyckel visade sig vara för kort, och banker, betalningsnätverk och myndighetssystem antog den i stor utsträckning för data i vila och data under överföring. Den tillfälliga lösningen är nu över. NISTs egen publicerade vägledning förbjuder 3DES för all ny kryptering, och oberoende kryptanalys gav branschen en konkret, praktisk anledning att sluta använda den år innan efterlevnadsfristen löpte ut.

Varför pensioneras 3DES?

3DES tas ur bruk eftersom dess 64-bitars blockstorlek inte längre ger en tillräcklig säkerhetsmarginal vid moderna datavolymer, och NIST har meddelat detta skriftligen. NIST SP 800-131A Revision 2 anger att kryptering med trenyckel-TDEA är föråldrad till och med den 31 december 2023 och inte tillåten för nya applikationer efter det datumet. Tvånyckel-TDEA-kryptering var ännu tidigare otillåten. NIST förstärkte denna punkt 2023 med ett formellt meddelande om att de skulle dra tillbaka SP 800-67 Revision 2 , specifikationen som definierar TDEA själv, med verkan från och med den 1 januari 2024. Efter det datumet är TDEA inte längre en godkänd blockchiffer för att skydda ny data. Det är fortfarande endast tillåtet för dekryptering, nyckeluppackning och MAC-verifiering av data som redan var skyddad före gränsen.

Tillbakadragandet var inte ett överraskande beslut. NIST signalerade först tillbakadragandet i ett utkast till riktlinjer som publicerades den 19 juli 2018, vilket gav leverantörer och företag ungefär fem års offentligt meddelande innan förbudet trädde i kraft. Gapet mellan utkastet från 2018 och tillämpningen från 2023 till 2024 gav branschen tid att migrera, men som implementeringsexemplen nedan visar missade många äldre system det fönstret.

Hur skiljer sig 3DES från den ursprungliga DES?

DES är en symmetrisk nyckelalgoritm med en enda 56-bitars nyckel, som brute-force-hårdvara tog över för årtionden sedan. 3DES utformades för att förlänga DES livslängd utan att ändra dess hårdvara, genom att kedja samma DES-algoritm genom tre omgångar, vanligtvis kryptera med nyckel 1, dekryptera med nyckel 2 och sedan kryptera igen med nyckel 3 ("EDE"-konstruktionen). Använd med tre genuint oberoende nycklar ger detta en effektiv nyckelstyrka på cirka 112 bitar snarare än de teoretiska 168 bitarna, på grund av en känd "meet-in-the-middle"-reduktion mot trippelkryptering. Den extra nyckelstyrkan gav 3DES ytterligare två decenniers tjänst, men den ändrade aldrig den underliggande 64-bitars blockstorleken, och den blockstorleken var den egenskap som så småningom hann ikapp den.

Vad är Sweet32-sårbarheten?

Sweet32 är en kollisionsattack med födelsedagsgräns, spårad som CVE-2016-2183 för TLS och CVE-2016-6329 för OpenVPN, som låter en angripare återställa klartext från vilken 64-bitars blockchiffer som helst, inklusive 3DES och Blowfish, när tillräckligt med data har krypterats under en enda nyckel. Forskarna Karthikeyan Bhargavan och Gaetan Leurent från INRIA publicerade attacken på ACM CCS 2016 och dokumenterade den på sweet32.info.

Mekanismen är en enkel tillämpning av födelsedagsproblemet för att blockera chifferutdata. Med ett 64-bitarsblock börjar en angripare som kan observera ungefär 2^32 block (cirka 32 GB) chiffertext krypterad under en nyckel se blockkollisioner, och dessa kollisioner läcker information om den underliggande klartexten genom en XOR-relation mellan kolliderande block. I forskarnas proof-of-concept mot HTTPS återställde en angripare som kunde injicera skadlig JavaScript i ett offers webbläsare för att generera långlivad krypterad trafik en 16-byte autentiseringscookie efter att ha samlat in cirka 785 GB data, en rimlig mängd över en långlivad anslutning som hållits öppen i under två dagar. AES 128-bitarsblock ger en födelsedagsgräns så långt bortom praktisk räckhåll (cirka 2^64 block) att samma attack inte gäller.

Sweet32 är viktigt för tidslinjen för avveckling eftersom det förvandlade en abstrakt, långsiktig kryptografisk svaghet till en demonstrerad, reproducerbar attack mot verkliga protokoll. Det är det praktiska beviset bakom NIST:s efterlevnadsfrist, inte ett separat, orelaterat fynd.

Hur väljer man en ersättningsalgoritm?

För nästan alla användningsfall som för närvarande kör 3DES är den direkta ersättningen AES-256, vald utifrån datatillstånd och protokoll snarare än utifrån vana.

• Data under överföring (TLS, VPN-tunnlar, meddelanden): Använd AES-256-GCM, ett autentiserat krypteringsläge som ger både konfidentialitet och integritet. Det är standardrekommendationen i TLS 1.2 och den enda generella AEAD-familjen som förts vidare till TLS 1.3.
• Vilande data (diskar, databaser, säkerhetskopior): använd AES-256 i XTS-läge, specialbyggt för blocklagringskryptering, eller AES-256-GCM där autentiserad kryptering av diskreta poster krävs.
• Programvarubaserade miljöer utan AES-NI: använd ChaCha20-Poly1305, en AEAD-chiffer som fungerar bra i ren programvara och inte behöver någon dedikerad hårdvaruinstruktionsuppsättning, vilket gör den till ett rimligt alternativ på äldre eller begränsade processorer.
• Betalkorts- och tokeniseringssystem som måste behålla en fast fältlängd eller ett fast format: utvärdera NIST-godkänd formatbevarande kryptering (FF1 eller FF3-1) snarare än att anta att 3DES blockbeteende kan bytas ut mot AES utan att det omgivande dataformatet rör.

Undvik att välja ett läge som standard. AES i ECB-läge läcker mönster i klartext och bör aldrig användas; AES-CBC behöver en separat meddelandeautentiseringskod som läggs ovanpå för att undvika utfyllnadsorakelattacker (Lucky 13, POODLE) som drabbade CBC-baserade TLS-chiffer tidigare. GCM och XTS finns specifikt så att implementatörer inte behöver sätta ihop det skyddet manuellt.

Vad är den verkliga hotmodellen för 3DES idag?

Den praktiska risken med fortsatt 3DES-användning beror starkt på hur chiffern distribueras, inte bara på det faktum att den är föråldrad.

• Högvolym, långlivade, nätverksobserverbara anslutningar (en TLS-session eller VPN-tunnel som förblir öppen och bär tiotals gigabyte under en nyckel) är det scenario Sweet32 faktiskt siktar på, och det där 3DES utgör en påvisad, exploaterbar risk idag.
• Låg volym, offline eller användning med begränsad kapacitet (en enda krypterad fil, en batch-export, ett isolerat äldre gränssnitt utan angriparkontrollerad trafikgenerering) når i praktiken långt ifrån födelsedagsgränsen, vilket är anledningen till att NIST fortfarande tillåter äldre dekryptering snarare än att kräva omedelbar omkryptering av varje historisk 3DES-artefakt.
• Compliancerisk gäller oavsett trafikvolym. Revisorer som kontrollerar mot PCI DSS, FIPS 140-3-validering eller NIST-anpassad intern policy kommer att flagga all 3DES-kryptering av ny data som icke-kompatibel efter den 31 december 2023, oberoende av om Sweet32 är praktiskt utnyttjande i den specifika implementeringen.

Den ärliga hotmodellen har alltså två distinkta drivkrafter som pekar mot samma slutsats: en kryptanalytisk (Sweet32, sämst inom nätverksprotokoll med hög volym) och en efterlevnadsmodell (NIST-undantag, som gäller enhetligt). Endera drivkraften ensam motiverar migrering; tillsammans eliminerar de alla skäl för att behålla 3DES i nya designer.

Hur migrerar man från 3DES till AES?

En migrering från 3DES till AES är mer ett sekvenseringsproblem än ett kodningsproblem. Stegen nedan är den ordning som undviker att interoperabiliteten bryts mitt i projektet.

1. Inventera varje 3DES-användning. Leta reda på 3DES i TLS-krypteringskonfiguration, VPN-policyer, databas- och filkrypteringsinställningar, HSM-nyckelceremonier och applikationskod, inklusive leverantörs- och firmwarekomponenter som kan hårdkoda den. Ett kryptografiskt identifieringsverktyg som CBOM Secure hittar dessa instanser i kod, certifikat och nyckellager istället för att förlita sig på manuella granskningar.
2. Klassificera varje användning efter datakänslighet, protokoll och motpart. En TLS-lyssnare som du kontrollerar från början till slut migrerar annorlunda än ett betalningsnätverksgränssnitt där motparten också måste flytta.
3. Välj AES-läge och nyckelstorlek för varje användning med hjälp av ovanstående vägledning (GCM för transit, XTS för vila, ChaCha20-Poly1305 där AES-NI saknas).
4. Testa interoperabilitet mot varje motpart och klient som också måste stödja den nya chiffreringen, inklusive äldre TLS-klienter, äldre HSM-firmware och tredjepartsintegrationer som kan behöva sin egen uppgradering först.
5. Skanna ett dubbelt stöd genomskärningsfönster där både 3DES och AES erbjuds, används AES som standard, så att icke-migrerade motparter är synliga i loggarna innan du tvingar fram överkopplingen.
6. Omkoda nedströmssystem och generera nya AES-nycklar under korrekta nyckelhanteringskontroller snarare än att härleda dem från det gamla 3DES-nyckelmaterialet.
7. Avaktivera 3DES för ny kryptering när fönstret med dubbelt stöd inte visar några kvarvarande AES-oförmögna klienter, samtidigt som möjligheten att dekryptera äldre 3DES-skyddade data fortfarande tillåter, vilket NIST-riktlinjerna fortfarande tillåter.
8. Dokumentera ändringen för att bevisa efterlevnad, eftersom revisorer vill ha daterade bevis på att ny kryptering slutade använda 3DES senast den gällande tidsfristen.

Avvägningar mellan prestanda och interoperabilitet och äldre system

3DES var redan det långsammare alternativet innan det föråldrades, eftersom det kör DES-algoritmen tre gånger per block. AES är snabbare på nästan all modern hårdvara, särskilt med AES-NI, den dedikerade CPU-instruktionsuppsättningen som finns i praktiskt taget alla server- och stationära processorer som levererats sedan början av 2010-talet, vilket accelererar AES-kryptering och dekryptering i hårdvara. Där AES-NI inte är tillgängligt, till exempel vissa inbyggda styrenheter och äldre mikrokontroller, är ChaCha20-Poly1305 vanligtvis det snabbare programvarubaserade alternativet till endera chiffreringen.

Prestanda är sällan den svåra delen av en 3DES-migrering; interoperabilitet med äldre hårdvara är det. Point-of-sale-terminaler och bankomatnätverk certifieras ofta mot en specifik krypteringslista, ibland kopplad till ett PCI PTS-enhetsgodkännande som uttryckligen namnger 3DES DUKPT (Derived Unique Key Per Transaction). Stordatorapplikationer och äldre HSM-firmware kanske inte exponerar AES-lägen genom sitt befintliga API utan en firmware- eller programvaruuppgradering som leverantören inte längre prioriterar för uttjänt hårdvara. Fältdistribuerade enheter, industriella styrsystem och viss IoT-hårdvara byggdes med 3DES inbyggd i firmware som inte kan fjärruppdateras alls. I vart och ett av dessa fall är algoritmbeslutet nedströms ett beslut om hårdvara och leverantörssupport, vilket är anledningen till att migreringstidslinjer för äldre enheter vanligtvis löper i år, inte veckor.

Vilka är nyckelhanteringsberoendena under migreringen?

Att lägga ner 3DES berör nyckelhantering mer än det berör själva chiffret, och det är oftast den delen som organisationer underskattar.

• Omdesign av nyckelhierarkin: 3DES-implementeringar, särskilt i betalningsnätverk, använder vanligtvis nyckelpaket med dubbel eller trippel längd med nyckelkontrollvärden (KCV) för verifiering. AES-nycklar är enkla värden med fast längd, så den omgivande nyckelhierarkin, lagringsformatet och verifieringsverktygen som är byggda kring 3DES-nyckelpaket behöver omdesignas, inte bara fyllas på igen.
• HSM-nyckelceremonier: Där 3DES-nycklar genererades och injicerades genom formella, bevittnade nyckelceremonier, behöver AES-ersättningsnycklarna vanligtvis en motsvarande ceremoni, särskilt i PCI- eller FIPS 140-3-styrda miljöer där bevis för nyckelförvaring är ett revisionskrav.
• PIN-blockering och kortdataformat: Betalningssystem som använder ISO 9564 PIN-blockformat byggda kring DES/3DES-operationer (inklusive PIN-översättning mellan inlösare och utfärdare) kräver noggrann formatmappning när den underliggande chiffern ändras, eftersom själva PIN-blockformatet, inte bara chiffern, är en del av interoperabilitetsavtalet mellan parterna.
• Kontinuitet i nyckelvård: Avveckling av gamla 3DES-nycklar får inte ske innan alla system som fortfarande behöver dekryptera äldre 3DES-skyddade data har en dokumenterad, testad väg att göra det. NISTs fortsatta tillåtelse för äldre dekryptering existerar just för att historiska data inte försvinner på avstängningsdatumet.
• Kryptoagilitet för nästa övergång: Organisationer som behandlar detta som ett engångsbyte från 3DES till AES återuppbygger ofta samma stelhet som gjorde 3DES-migreringen smärtsam. Att bygga den nya nyckelarkitekturen med den nuvarande och framtida övergången efter kvantum i åtanke undviker att upprepa detta projekt igen om några år.

3DES vs. AES-256: Jämförelse sida vid sida

Fast egendom	3DES (Tre-nyckel TDEA)	AES-256
Nyckelstorlek	168 bitar nominellt, cirka 112 bitar effektivt	256 bitar
Block storlek	64 bitar	128 bitar
Säkerhetsmarginal	Sårbar för födelsedagsbundna kollisioner (Sweet32) runt 2^32 block (cirka 32 GB) under en nyckel	Födelsedagsgränsen är cirka 2^64 kvarter; inte praktiskt nåbar
Prestanda	Långsam; tre sekventiella DES-pass per block, ingen dedikerad hårdvaruacceleration	Snabb; hårdvaruaccelererad via AES-NI på moderna processorer
Nuvarande NIST-status	Ej tillåten för ny kryptering efter 31 december 2023 (SP 800-131A Rev. 2); SP 800-67 Rev. 2 återkallad 1 januari 2024; äldre dekryptering fortfarande tillåten	Godkänd (FIPS 197); standardrekommendationen för ny symmetrisk kryptering

Var används 3DES fortfarande idag?

3DES har inte försvunnit från produktionsmiljöer bara för att det inte tillåtits. De vanligaste platserna där det fortfarande dyker upp:

• Betalterminaler och bankomatnätverk använder 3DES DUKPT för PIN-kryptering, ofta för att den fysiska terminalhårdvaran certifierades för flera år sedan mot en fast chifferlista och inte har ersatts.
• Stordatorapplikationer där 3DES hårdkodades in i COBOL eller liknande äldre applikationskod för årtionden sedan och aldrig har återvänt eftersom applikationen fortfarande fungerar.
• Äldre HSM:er och nyckelhanteringsenheter köra firmwareversioner som föregår AES-stöd i det specifika API som det integrerande programmet anropar, även när själva HSM-hårdvaran stöder AES.
• Äldre VPN- och IPsec-gateways konfigurerad med 3DES-krypteringssviter som aldrig uppdaterades efter den initiala driftsättningen, och upptäcktes ofta bara när en säkerhetsbedömning eller ett penetrationstest flaggar konfigurationen.
• Inbyggda och industriella styrsystemenheter med firmware som inte kan uppdateras på distans, där att byta ut chiffern innebär att byta ut den fysiska enheten.

Var och en av dessa kategorier har en gemensam egenskap: hindret för migrering är sällan själva AES-algoritmen, utan de begränsningar som finns kring den gällande hårdvaran, den inbyggda programvaran eller leverantörssupporten.

Begränsningar

Denna vägledning beskriver vad NIST publicerar och vad Sweet32-forskningen visade; den ersätter inte en specifik efterlevnadsbedömning för din miljö. Några begränsningar som är värda att ange direkt:

• NIST-riktlinjer styr amerikanska federala system och är allmänt antagna som ett riktmärke för den privata sektorn, men organisationer under andra regelverk (PCI DSS-rådets riktlinjer, regional dataskyddslag, sektorspecifika mandat) bör bekräfta sina egna tillämpliga tidsfrister snarare än att anta att NIST:s datum gäller ordagrant.
• Sweet32:s praktiska inverkan beror på trafikvolym och anslutningens livslängd, vilket beskrivs i avsnittet om hotmodellen. Det är inte bevis för att varje 3DES-distribution aktivt utnyttjas idag, bara att attacken demonstreras och är reproducerbar under realistiska förhållanden.
• Äldre dekryptering av tidigare skyddade 3DES-data är fortfarande tillåten enligt nuvarande NIST-riktlinjer, men detta tillåtande är inte avsiktligt obegränsat; NIST kan revidera denna ståndpunkt i framtida publikationer, så organisationer med stora volymer av äldre 3DES-krypterad data bör inte behandla det nuvarande undantaget som permanent.
• Hårdvaru- och firmwarebegränsningar på äldre system är mycket specifika för varje leverantör och enhet; distributionsexemplen ovan är vanliga mönster, inte en uttömmande lista över alla miljöer där 3DES fortfarande kan hittas.

Vad skulle krypteringskonsulter rekommendera?

Börja med upptäckt, inte med ett krypteringsbyte. De flesta organisationer som kommer till oss med en 3DES-fråga vet faktiskt inte hur många system som fortfarande använder det. Vårt kryptografiska inventeringsarbete, som CBOM Secure är byggt för att automatisera , skannar kodförråd, certifikatarkiv, HSM:er och nätverkskonfigurationer för att skapa en verklig, evidensbaserad lista över var 3DES (och alla andra föråldrade algoritmer) fortfarande finns, snarare än att förlita sig på vad teamet minns att de konfigurerade för fem år sedan.

Därifrån behandlar vi migreringen som en kryptoagilitetsövning snarare än en engångsåtgärd. De organisationer som kämpar mest med 3DES-pensionering är de som hårdkodade algoritmval i applikationer, firmware och nyckelhierarkier utan något abstraktionslager för att byta ut dem senare, vilket är exakt samma stelhet som kommer att göra nästa övergång till post-kvantalgoritmer lika smärtsam om den inte åtgärdas nu. Vår kryptoagilitetsstrategi och krypteringsrådgivning är byggda för att åtgärda den grundorsaken: inventering först, sedan en prioriterad migreringsplan sekvenserad efter risk (börja med högvolym, nätverksexponerade 3DES-användningar där Sweet32 är ett aktivt problem), sedan en nyckelhanteringsarkitektur som kan absorbera nästa algoritmändring utan ytterligare en flerårig brandövning.

Slutsats

Att 3DES tas ur bruk är inte en framtida händelse att planera kring; det har redan hänt. NIST förbjöd ny 3DES-kryptering efter den 31 december 2023 och drog tillbaka specifikationen som definierade den den 1 januari 2024, med stöd av nästan ett decennium av kryptanalytiskt tryck som kulminerade i den demonstrerade Sweet32-attacken. AES-256 är den direkta, väl underbyggda ersättningen för i princip alla användningsfall som 3DES någonsin täckt, och det verkliga arbetet som återstår är inte att välja en algoritm utan att hitta alla system som fortfarande kör den gamla och reda ut nyckelhanteringen som byggts runt den. Börja med en ärlig inventering, sekvensera migreringen efter var Sweet32:s hotmodell är realistisk först och bygg ersättningen så att nästa algoritmövergång inte kräver samma kaos.

Vanliga frågor om partihandel med mat och dryck

När exakt förbjöd NIST 3DES?
NIST SP 800-131A Revision 2 avskaffade tre-nyckel TDEA (3DES)-kryptering för nya applikationer fram till den 31 december 2023 och förbjöd den efter det datumet. NIST förstärkte detta genom att formellt dra tillbaka SP 800-67 Revision 2, specifikationen som definierar TDEA, med verkan från och med den 1 januari 2024. Efter det datumet är 3DES inte en godkänd chiffer för ny kryptering, även om dekryptering av data som redan skyddades med den fortfarande är tillåten.

Vad är Sweet32, och påverkar det all 3DES-användning?
Sweet32 (CVE-2016-2183 för TLS, CVE-2016-6329 för OpenVPN) är en födelsedagsbunden kollisionsattack mot 64-bitars blockchiffer, publicerad av Bhargavan och Leurent på ACM CCS 2016. Den är mest praktisk mot högvolyms-, långlivade, nätverksobserverbara anslutningar som krypterar tiotals gigabyte under en enda nyckel, till exempel en TLS-session som hålls öppen tillräckligt länge för att en angripare ska kunna generera så mycket trafik. 3DES-användningar med låg volym eller offline når långt under den datatröskel som attacken behöver, även om NISTs förbud gäller för ny kryptering oavsett trafikvolym.

Kan vi fortfarande använda 3DES för att dekryptera gammal data?
Ja. Nuvarande NIST-riktlinjer tillåter användning av 3DES för dekryptering, nyckeluppackning och verifiering av meddelandeautentiseringskoder på data som redan var skyddade innan förbudet trädde i kraft. Det som är förbjudet är att tillämpa ny 3DES-kryptering framöver, inte åtkomst till historisk data som redan var krypterad med den.

Vad borde ersätta 3DES?
AES-256 är standardersättningen: AES-256-GCM för data under överföring och för poster som behöver autentiserad kryptering, AES-256-XTS för blocklagringskryptering. Där AES-NI-hårdvaruacceleration inte är tillgänglig är ChaCha20-Poly1305 ett starkt programvarubaserat alternativ. Formatbevarande kryptering (FF1 eller FF3-1) är alternativet för att utvärdera när ett betalnings- eller tokeniseringssystem måste behålla en fast fältlängd eller ett fast format.

Vad är den svåraste delen med att migrera äldre betalnings- eller stordatorsystem från 3DES?
Nyckelhantering, inte själva algoritmbytet. Betalningsnätverk i synnerhet byggde nyckelhierarkier, HSM-nyckelceremonier och PIN-blockformat kring 3DES dubbel- och trippellånga nyckelstrukturer, och dessa behöver omdesignas snarare än enkla utbyten. Hårdvarubegränsningar, certifierade kassaterminaler, äldre HSM-firmware och icke-uppdaterbara inbäddade enheter är vanligtvis den näst svåraste begränsningen, vilket är anledningen till att äldre migreringar vanligtvis sker på år snarare än en enda projektsprint.

Referensprojekt

• NIST SP 800-131A Revision 2, Övergång till användning av kryptografiska algoritmer och nyckellängder
• NIST CSRC: NIST återkallar specialpublikation 800-67 Revision 2 (2023)
• NIST SP 800-67 Revision 2 (återtagen), Rekommendation för Triple Data Encryption Algorithm (TDEA) Block Cipher
• Sweet32: Födelsedagsattacker på 64-bitars blockchiffer i TLS och OpenVPN, Bhargavan och Leurent, ACM CCS 2016
• CVE-2016-2183, Nationell sårbarhetsdatabas