Waarom 3DES of Triple DES officieel wordt stopgezet

Gepubliceerd: maart 2022. Bijgewerkt: augustus 2026. Beoordeeld door het Encryption Advisory-team van Encryption Consulting.

3DES, ook wel Triple DES of TDEA (Triple Data Encryption Algorithm) genoemd, is een symmetrische blokversleuteling die is opgebouwd door het oorspronkelijke DES- algoritme drie keer per datablok uit te voeren met twee of drie sleutels. NIST introduceerde het in de jaren 1990 als een tijdelijke oplossing nadat de 56-bits sleutel van DES te kort bleek. Banken, betalingsnetwerken en overheidssystemen namen het vervolgens op grote schaal in gebruik voor data in rust en data in transit. Die tijdelijke oplossing is nu voorbij. De eigen richtlijnen van NIST verbieden 3DES voor elke nieuwe versleuteling, en onafhankelijke cryptanalyses gaven de industrie jaren vóór de deadline al een concrete, praktische reden om ermee te stoppen.

Waarom wordt 3DES uitgefaseerd?

3DES wordt uitgefaseerd omdat de blokgrootte van 64 bits niet langer een adequate veiligheidsmarge biedt bij de huidige datavolumes, en NIST heeft dit schriftelijk bevestigd. NIST SP 800-131A Revisie 2 stelt dat encryptie met drie-sleutel TDEA is afgekeurd tot en met 31 december 2023 en na die datum niet meer is toegestaan ​​voor nieuwe toepassingen. Encryptie met twee-sleutel TDEA was al eerder afgekeurd. NIST benadrukte dit punt in 2023 met een formele mededeling dat het SP 800-67 Revisie 2 , de specificatie die TDEA zelf definieert, per 1 januari 2024 zou intrekken. Na die datum is TDEA geen goedgekeurd blokcijfer meer voor de bescherming van nieuwe data. Het is alleen nog toegestaan ​​voor het decoderen, het ontcijferen van sleutels en de MAC-verificatie van data die vóór de deadline al beveiligd was.

De intrekking was geen verrassing. NIST kondigde de stopzetting al aan in een conceptrichtlijn die op 19 juli 2018 werd gepubliceerd, waardoor leveranciers en bedrijven ongeveer vijf jaar de tijd kregen om zich voor te bereiden voordat de intrekking van kracht werd. De periode tussen het concept van 2018 en de handhaving in 2023 of 2024 gaf de sector de tijd om te migreren, hoewel, zoals de onderstaande implementatievoorbeelden laten zien, veel verouderde systemen die periode hebben gemist.

Waarin verschilt 3DES van de originele DES?

DES is een symmetrisch sleutelalgoritme met één 56-bits sleutel, dat decennia geleden door brute-force-hardware werd ingehaald. 3DES werd ontworpen om de levensduur van DES te verlengen zonder de hardware te veranderen, door hetzelfde DES-algoritme in drie stappen te herhalen: versleutelen met sleutel 1, ontsleutelen met sleutel 2 en vervolgens opnieuw versleutelen met sleutel 3 (de "EDE"-constructie). Gebruikt met drie werkelijk onafhankelijke sleutels, levert dit een effectieve sleutelsterkte op van ongeveer 112 bits in plaats van de theoretische 168 bits, vanwege een bekende meet-in-the-middle-reductie tegen drievoudige versleuteling. Die extra sleutelsterkte gaf 3DES nog eens twintig jaar dienst, maar de onderliggende blokgrootte van 64 bits bleef hetzelfde, en die blokgrootte is uiteindelijk de eigenschap die het algoritme de das om deed.

Wat is de Sweet32-kwetsbaarheid?

Sweet32 is een aanval die gebaseerd is op een verjaardag en waarvan de kwetsbaarheid is vastgelegd als CVE-2016-2183 voor TLS en CVE-2016-6329 voor OpenVPN. Met deze aanval kan een aanvaller de onversleutelde tekst van elke 64-bits blokcodering, inclusief 3DES en Blowfish, achterhalen zodra voldoende gegevens met één sleutel zijn versleuteld. Onderzoekers Karthikeyan Bhargavan en Gaetan Leurent van INRIA publiceerden de aanval op ACM CCS 2016 en documenteerden deze op sweet32.info.

Het mechanisme is een rechtstreekse toepassing van het verjaardagsprobleem op de uitvoer van blokcijfers. Met een 64-bits blok begint een aanvaller die ongeveer 2^32 blokken (ongeveer 32 GB) aan versleutelde tekst onder één sleutel kan observeren, blokbotsingen te zien. Deze botsingen lekken informatie over de onderliggende platte tekst via een XOR-relatie tussen botsende blokken. In het proof-of-concept van de onderzoekers tegen HTTPS kon een aanvaller die kwaadaardige JavaScript in de browser van een slachtoffer injecteerde om langdurig versleuteld verkeer te genereren, een authenticatiecookie van 16 bytes herstellen na het verzamelen van ongeveer 785 GB aan gegevens. Dit is een haalbare hoeveelheid voor een langdurige verbinding die minder dan twee dagen open blijft. Het 128-bits blok van AES geeft een verjaardagsgrens die zo ver buiten het praktische bereik ligt (ongeveer 2^64 blokken) dat dezelfde aanval niet van toepassing is.

Sweet32 is relevant voor de uitfasering omdat het een abstracte, langetermijncryptografische zwakte heeft omgezet in een bewezen, reproduceerbare aanval op echte protocollen. Het is het praktische bewijs voor de nalevingsdeadline van NIST, geen aparte, ongerelateerde bevinding.

Hoe kies je een vervangend algoritme?

Voor vrijwel alle toepassingen waar momenteel 3DES wordt gebruikt, is AES-256 een direct alternatief. De keuze hiervoor hangt af van de datastatus en het protocol, en niet zozeer van gewoonte.

• Gegevens in transit (TLS, VPN-tunnels, berichtenverkeer): Gebruik AES-256-GCM, een geauthenticeerde versleutelingsmodus die zowel vertrouwelijkheid als integriteit biedt. Het is de standaardaanbeveling in TLS 1.2 en de enige algemene AEAD-familie die is overgenomen in TLS 1.3.
• Gegevens in rust (schijven, databases, back-ups): Gebruik AES-256 in XTS-modus, speciaal ontworpen voor blokopslagversleuteling, of AES-256-GCM wanneer geauthenticeerde versleuteling van afzonderlijke records vereist is.
• Softwarematige omgevingen zonder AES-NI: Gebruik ChaCha20-Poly1305, een AEAD-coderingsalgoritme dat goed presteert in pure software en geen speciale hardware-instructieset vereist, waardoor het een redelijk alternatief is voor oudere of beperkte CPU's.
• Betaalkaart- en tokenisatiesystemen die een vaste veldlengte of -indeling moeten behouden: Evalueer door NIST goedgekeurde formaatbehoudende encryptie (FF1 of FF3-1) in plaats van aan te nemen dat het blokgedrag van 3DES kan worden vervangen door AES zonder het omliggende gegevensformaat aan te tasten.

Vermijd het standaard kiezen van een modus. AES in ECB-modus lekt patronen in de platte tekst en mag nooit worden gebruikt; AES-CBC vereist een aparte berichtauthenticatiecode die er bovenop is geplaatst om aanvallen van het padding-oracle-type (Lucky 13, POODLE) te voorkomen die in het verleden CBC-gebaseerde TLS-cijfers hebben getroffen. GCM en XTS bestaan ​​specifiek zodat implementeerders die bescherming niet handmatig hoeven te implementeren.

Wat is het huidige dreigingsmodel voor 3DES in de praktijk?

Het praktische risico van voortgezet gebruik van 3DES hangt sterk af van hoe de versleuteling wordt ingezet, en niet alleen van het feit dat deze verouderd is.

• Verbindingen met een hoog volume, een lange levensduur en die waarneembaar zijn via het netwerk. (Een TLS-sessie of VPN-tunnel die open blijft en tientallen gigabytes aan data onder één sleutel transporteert) is het scenario waarop Sweet32 zich daadwerkelijk richt, en waar 3DES vandaag de dag een bewezen, exploiteerbaar risico vormt.
• Toepassingen met een laag volume, offline of in een geïsoleerde omgeving. (Een enkel versleuteld bestand, een batchexport, een geïsoleerde legacy-interface zonder door een aanvaller gecontroleerde verkeersgeneratie) voldoen in de praktijk lang niet aan de verjaardagsgrens, en daarom staat NIST nog steeds legacy-ontsleuteling toe in plaats van onmiddellijke herversleuteling van elk historisch 3DES-artefact te verplichten.
• Het nalevingsrisico is van toepassing ongeacht het verkeersvolume. Auditors die controleren op basis van PCI DSS, FIPS 140-3-validatie of intern beleid dat is afgestemd op NIST, zullen elke 3DES-versleuteling van nieuwe gegevens na 31 december 2023 als niet-conform markeren, ongeacht of Sweet32 in die specifieke implementatie daadwerkelijk kan worden misbruikt.

Het eerlijke dreigingsmodel kent dus twee afzonderlijke drijfveren die tot dezelfde conclusie leiden: een cryptanalytische (Sweet32, het ergst in netwerkprotocollen met een hoog volume) en een compliance-gerelateerde (de NIST-verbodsbepaling, die uniform van toepassing is). Elk van beide drijfveren op zich rechtvaardigt migratie; samen maken ze elke reden om 3DES in nieuwe ontwerpen te behouden overbodig.

Hoe migreer je van 3DES naar AES?

Een migratie van 3DES naar AES is meer een kwestie van volgorde dan van codering. De onderstaande stappen geven de volgorde aan die voorkomt dat de interoperabiliteit halverwege het project wordt verbroken.

1. Inventariseer elk 3DES-gebruik. Zoek naar 3DES in de configuratie van de TLS-coderingssuite, VPN-beleid, database- en bestandsversleutelingsinstellingen, HSM-sleutelceremonies en applicatiecode, inclusief componenten van leveranciers en firmware die het mogelijk hardcoderen. Een cryptografische detectietool zoals CBOM Secure vindt deze gevallen in code, certificaten en sleutelarchieven, waardoor handmatige controles overbodig worden.
2. Classificeer elk gebruik op basis van gegevensgevoeligheid, protocol en wederpartij. Een TLS-listener die je van begin tot eind beheert, migreert anders dan een interface van een betalingsnetwerk, waarbij de tegenpartij ook moet migreren.
3. Selecteer voor elk gebruik de AES-modus en de sleutelgrootte. met behulp van de bovenstaande richtlijnen (GCM voor transit, XTS voor rusttoestand, ChaCha20-Poly1305 waar AES-NI ontbreekt).
4. Test de interoperabiliteit met elke tegenpartij en klant. Die apparaten moeten ook de nieuwe versleuteling ondersteunen, waaronder oudere TLS-clients, verouderde HSM-firmware en integraties van derden die mogelijk eerst een eigen upgrade nodig hebben.
5. Plan een overgangsperiode voor dubbele ondersteuning. waarbij zowel 3DES als AES worden aangeboden, met AES als standaard, zodat niet-gemigreerde tegenpartijen zichtbaar zijn in de logboeken voordat u de overstap forceert.
6. Herversleutel downstream-systemen en genereer nieuwe AES-sleutels. onder de juiste sleutelbeheercontroles in plaats van ze af te leiden van het oude 3DES-sleutelmateriaal.
7. 3DES wordt buiten gebruik gesteld ten gunste van nieuwe encryptie. zodra het venster voor dubbele ondersteuning geen AES-ongeschikte clients meer laat zien, terwijl de mogelijkheid behouden blijft om oudere 3DES-beveiligde gegevens te decoderen zoals de NIST-richtlijnen nog toestaan.
8. Documenteer de wijziging als bewijs van naleving., aangezien auditors gedateerd bewijs willen zien dat de nieuwe encryptie vóór de betreffende deadline is gestopt met het gebruik van 3DES.

Afwegingen tussen prestaties en interoperabiliteit bij verouderde systemen

3DES was al de langzamere optie voordat het werd afgekeurd, omdat het het DES-algoritme drie keer volledig per blok uitvoert. AES is sneller op vrijwel alle moderne hardware, met name met AES-NI, de speciale CPU-instructieset die aanwezig is in vrijwel elke server- en desktopprocessor die sinds begin 2010 is uitgebracht en die AES-encryptie en -decryptie in hardware versnelt. Waar AES-NI niet beschikbaar is, zoals bij sommige embedded controllers en oudere microcontrollers, is ChaCha20-Poly1305 doorgaans het snellere softwarematige alternatief voor beide versleutelingsmethoden.

Prestaties vormen zelden het grootste probleem bij een 3DES-migratie; interoperabiliteit met bestaande hardware is dat wel. Kassaterminals en geldautomatennetwerken zijn vaak gecertificeerd op basis van een specifieke cipherlijst, soms gekoppeld aan een PCI PTS-apparaatgoedkeuring die expliciet 3DES DUKPT (Derived Unique Key Per Transaction) vermeldt. Mainframe-applicaties en oudere HSM-firmware bieden mogelijk geen AES-modi aan via hun bestaande API zonder een firmware- of software-upgrade die de leverancier niet langer prioriteert voor hardware die het einde van zijn levensduur heeft bereikt. Apparaten die in het veld worden ingezet, industriële besturingssystemen en sommige IoT-hardware zijn gebouwd met 3DES ingebouwd in firmware die helemaal niet op afstand kan worden bijgewerkt. In al deze gevallen is de keuze voor het algoritme het gevolg van een hardware- en leveranciersondersteuningsbeslissing, waardoor migratietrajecten voor bestaande systemen doorgaans jaren in beslag nemen, en niet weken.

Wat zijn de belangrijkste beheersafhankelijkheden tijdens de migratie?

Het uitfaseren van 3DES heeft meer gevolgen voor het sleutelbeheer dan voor de versleuteling zelf, en dit is meestal het aspect dat organisaties onderschatten.

• Herontwerp van de belangrijkste hiërarchie: Bij 3DES-implementaties, met name in betalingsnetwerken, worden vaak sleutelbundels van dubbele of driedubbele lengte gebruikt met sleutelcontrolewaarden (KCV's) voor verificatie. AES-sleutels zijn enkele waarden met een vaste lengte, waardoor de bijbehorende sleutelhiërarchie, opslagindeling en verificatietools die zijn gebouwd rond 3DES-sleutelbundels opnieuw ontworpen moeten worden, en niet alleen opnieuw gevuld.
• Belangrijkste ceremonies van HSM: Waar 3DES-sleutels werden gegenereerd en ingevoerd via formele, door getuigen bekrachtigde sleutelceremonies, vereisen de vervangende AES-sleutels doorgaans een gelijkwaardige ceremonie, met name in omgevingen die onder PCI of FIPS 140-3 vallen en waar bewijs van sleutelbeheer een auditvereiste is.
• PIN-blok en kaartgegevensformaten: Betalingssystemen die gebruikmaken van ISO 9564 PIN-blokformaten gebaseerd op DES/3DES-bewerkingen (inclusief PIN-vertaling tussen acquirer en issuer) vereisen een zorgvuldige formaatconversie wanneer de onderliggende versleuteling verandert. Dit komt doordat het PIN-blokformaat zelf, en niet alleen de versleuteling, onderdeel uitmaakt van het interoperabiliteitscontract tussen de partijen.
• Belangrijke continuïteit van de voogdij: Het buiten gebruik stellen van oude 3DES-sleutels mag niet plaatsvinden voordat elk systeem dat nog steeds 3DES-beveiligde gegevens uit het verleden moet decoderen, een gedocumenteerde en geteste methode daarvoor heeft. De voortdurende toestemming van NIST voor het decoderen van oude gegevens bestaat juist omdat historische gegevens niet verdwijnen op de datum waarop dit niet meer is toegestaan.
• Crypto-flexibiliteit voor de volgende transitie: Organisaties die dit beschouwen als een eenmalige 3DES-naar-AES-conversie, creëren vaak dezelfde starheid die de 3DES-migratie zo pijnlijk maakte. Door de nieuwe sleutelarchitectuur te bouwen met de huidige en toekomstige post-kwantumtransitie in gedachten, wordt voorkomen dat dit project over een paar jaar opnieuw moet worden uitgevoerd.

3DES versus AES-256: een vergelijking naast elkaar

Eigendom	3DES (Three-Key TDEA)	AES-256
Sleutelmaat	168 bits nominaal, ongeveer 112 bits effectief	256 beetjes
Blokgrootte	64 beetjes	128 beetjes
Veiligheidsmarge	Kwetsbaar voor botsingen gerelateerd aan verjaardagen (Sweet32) van ongeveer 2^32 blokken (ongeveer 32 GB) onder één sleutel.	De verjaardag is beperkt tot ongeveer 2^64 blokken; praktisch onbereikbaar.
Prestaties	Traag; drie opeenvolgende DES-passes per blok, geen speciale hardwareversnelling.	Snel; hardwarematig versneld via AES-NI op moderne CPU's.
Huidige NIST-status	Niet toegestaan ​​voor nieuwe versleuteling na 31 december 2023 (SP 800-131A Rev. 2); SP 800-67 Rev. 2 ingetrokken op 1 januari 2024; decryptie met oudere methoden blijft toegestaan.	Goedgekeurd (FIPS 197); de standaardaanbeveling voor nieuwe symmetrische versleuteling

Waar wordt 3DES tegenwoordig nog steeds ingezet?

3DES is niet zomaar uit productieomgevingen verdwenen omdat het verboden werd. De meest voorkomende plekken waar het nog steeds opduikt zijn:

• Betaalterminals en geldautomatennetwerken Het gebruik van 3DES DUKPT voor PIN-versleuteling is vaak een gevolg van het feit dat de fysieke terminalhardware jaren geleden is gecertificeerd met een vaste lijst van versleutelde bestanden en niet is vervangen.
• Mainframe-applicaties waarbij 3DES decennia geleden hardcoded is in COBOL of vergelijkbare legacy-applicatiecode en nooit meer is herzien omdat de applicatie nog steeds functioneert.
• Oudere HSM's en apparaten voor sleutelbeheer Het gebruik van firmwareversies die dateren van vóór de AES-ondersteuning in de specifieke API die de integrerende applicatie aanroept, zelfs wanneer de HSM-hardware zelf AES ondersteunt.
• Verouderde VPN- en IPsec-gateways geconfigureerd met 3DES-coderingssuites die na de initiële implementatie nooit zijn bijgewerkt, en die vaak pas worden ontdekt wanneer een beveiligingsbeoordeling of penetratietest de configuratie aan het licht brengt.
• Ingebouwde en industriële besturingssysteemapparaten met firmware die niet op afstand kan worden bijgewerkt, waarbij het vervangen van de encryptiecode betekent dat het fysieke apparaat moet worden vervangen.

Elk van deze categorieën heeft een gemeenschappelijk kenmerk: de belemmering voor migratie is zelden het AES-algoritme zelf, maar de hardware, firmware of beperkingen van de leverancier die ermee gepaard gaan.

Beperkingen

Deze richtlijn beschrijft wat NIST publiceert en wat het Sweet32-onderzoek heeft aangetoond; het vervangt geen specifieke conformiteitsbeoordeling voor uw omgeving. Enkele beperkingen die het vermelden waard zijn:

• De NIST-richtlijnen zijn van toepassing op de Amerikaanse federale systemen en worden algemeen gebruikt als maatstaf in de particuliere sector. Organisaties die onder andere regelgeving vallen (richtlijnen van de PCI DSS-raad, regionale wetgeving inzake gegevensbescherming, sectorspecifieke voorschriften) dienen echter hun eigen geldende deadlines te controleren in plaats van ervan uit te gaan dat de data van NIST klakkeloos van toepassing zijn.
• De praktische impact van Sweet32 hangt af van het verkeersvolume en de levensduur van de verbinding, zoals beschreven in het gedeelte over het dreigingsmodel; het is geen bewijs dat elke 3DES-implementatie momenteel actief wordt misbruikt, maar slechts dat de aanval is aangetoond en reproduceerbaar is onder realistische omstandigheden.
• Het ontsleutelen van voorheen beveiligde 3DES-gegevens blijft toegestaan ​​volgens de huidige NIST-richtlijnen, maar deze toestemming is niet voor onbepaalde tijd. NIST kan dit standpunt in toekomstige publicaties herzien, dus organisaties met grote hoeveelheden verouderde 3DES-versleutelde gegevens moeten de huidige uitzondering niet als permanent beschouwen.
• De hardware- en firmwarebeperkingen van oudere systemen zijn zeer specifiek voor elke leverancier en elk apparaat; de bovenstaande implementatievoorbeelden zijn veelvoorkomende patronen en geen uitputtende lijst van elke omgeving waarin 3DES nog steeds gebruikt kan worden.

Wat zou Encryption Consulting aanbevelen?

Begin met het ontdekken van de oorzaak, niet met het wisselen van versleutelingsalgoritmen. De meeste organisaties die met een vraag over 3DES bij ons aankomen, weten niet precies hoeveel systemen het nog gebruiken. Ons cryptografische inventarisatiewerk, dat door CBOM Secure geautomatiseerd wordt , scant code repositories, certificaatarchieven, HSM's en netwerkconfiguraties om een ​​accurate, op bewijs gebaseerde lijst te genereren van waar 3DES (en elk ander verouderd algoritme) nog steeds wordt gebruikt, in plaats van af te gaan op wat het team zich herinnert van vijf jaar geleden.

Van daaruit beschouwen we de migratie als een crypto-agility oefening in plaats van een eenmalige oplossing. De organisaties die het meest worstelen met de uitfasering van 3DES zijn degenen die algoritmekeuzes hardcoded hebben in applicaties, firmware en sleutelhiërarchieën zonder abstractielaag om ze later te vervangen. Precies diezelfde starheid zal de volgende overgang, naar post-kwantumalgoritmen, net zo pijnlijk maken als er nu geen actie wordt ondernomen. Onze crypto-agility aanpak en onze adviesdiensten op het gebied van encryptie zijn erop gericht om die onderliggende oorzaak aan te pakken: eerst een inventarisatie, vervolgens een geprioriteerd migratieplan op basis van risico (begin met grootschalige, netwerkblootgestelde 3DES-toepassingen waar Sweet32 een actueel probleem vormt), en ten slotte een sleutelbeheerarchitectuur die de volgende algoritmewijziging kan opvangen zonder opnieuw een meerjarige noodsituatie.

Conclusie

Het uitfaseren van 3DES is geen toekomstige gebeurtenis waar we rekening mee moeten houden; het is al gebeurd. NIST verbood nieuwe 3DES-encryptie na 31 december 2023 en trok de specificatie die het definieerde op 1 januari 2024 in, gesteund door bijna tien jaar aan cryptanalytische druk die culmineerde in de bewezen Sweet32-aanval. AES-256 is de directe, goed ondersteunde vervanging voor vrijwel elk gebruiksscenario dat 3DES ooit heeft afgedekt, en de echte uitdaging is niet het kiezen van een algoritme, maar het vinden van alle systemen die nog steeds het oude algoritme gebruiken en het ontwarren van het sleutelbeheer dat eromheen is gebouwd. Begin met een eerlijke inventarisatie, plan de migratie in op basis van waar het dreigingsmodel van Sweet32 het meest realistisch is, en bouw de vervanging zo dat de volgende algoritme-overgang niet dezelfde versleuteling vereist.

Veelgestelde Vragen / FAQ

Wanneer precies heeft NIST 3DES verboden?
NIST SP 800-131A Revisie 2 heeft de drie-sleutel TDEA (3DES)-encryptie afgekeurd voor nieuwe toepassingen tot en met 31 december 2023 en verboden na die datum. NIST heeft dit bekrachtigd door SP 800-67 Revisie 2, de specificatie die TDEA definieert, formeel in te trekken met ingang van 1 januari 2024. Na die datum is 3DES geen goedgekeurde encryptiemethode meer voor nieuwe toepassingen, hoewel het decoderen van gegevens die er al mee beveiligd waren nog steeds is toegestaan.

Wat is Sweet32 en heeft het invloed op elk gebruik van 3DES?
Sweet32 (CVE-2016-2183 voor TLS, CVE-2016-6329 voor OpenVPN) is een botsingsaanval gebaseerd op de verjaardag van een gebruiker tegen 64-bits blokcijfers. De aanval werd gepubliceerd door Bhargavan en Leurent op ACM CCS 2016. De aanval is het meest effectief tegen grote, langdurige, netwerkwaarneembare verbindingen die tientallen gigabytes aan data versleutelen met één enkele sleutel, zoals een TLS-sessie die lang genoeg open blijft om een ​​aanvaller de mogelijkheid te geven zoveel dataverkeer te genereren. Bij 3DES-gebruik met een laag datavolume of offline gebruik blijft de benodigde hoeveelheid data ver onder de drempelwaarde die de aanval vereist, hoewel het verbod van NIST geldt voor nieuwe versleuteling, ongeacht het datavolume.

Kunnen we 3DES nog steeds gebruiken om oude gegevens te decoderen?
Ja. De huidige NIST-richtlijnen staan ​​het gebruik van 3DES toe voor decryptie, sleutelontcijfering en verificatie van berichtauthenticatiecodes op gegevens die al beveiligd waren voordat het verbod van kracht werd. Wat verboden is, is het toepassen van nieuwe 3DES-encryptie in de toekomst, niet het openen van historische gegevens die er al mee versleuteld waren.

Wat moet 3DES vervangen?
AES-256 is de standaardvervanging: AES-256-GCM voor data die onderweg is en voor records die geauthenticeerde encryptie vereisen, AES-256-XTS voor blokopslagencryptie. Waar hardwareversnelling voor AES-NI niet beschikbaar is, is ChaCha20-Poly1305 een sterk softwarematig alternatief. Formaatbehoudende encryptie (FF1 of FF3-1) is de optie om te overwegen wanneer een betalings- of tokenisatiesysteem een ​​vaste veldlengte of -indeling moet behouden.

Wat is het moeilijkste aspect van het migreren van verouderde betaal- of mainframe-systemen van 3DES?
Sleutelbeheer is het belangrijkste, niet de algoritme-uitwisseling zelf. Betaalnetwerken hebben met name sleutelhiërarchieën, HSM-sleutelceremonies en PIN-blokformaten gebouwd rond de dubbele en driedubbele sleutelstructuren van 3DES, en die moeten opnieuw ontworpen worden in plaats van simpelweg vervangen. Hardwarebeperkingen, gecertificeerde kassaterminals, oudere HSM-firmware en niet-updatebare embedded apparaten vormen meestal de op één na grootste beperking, waardoor migraties van legacy-systemen doorgaans jaren duren in plaats van een enkele projectronde.

Referenties

• NIST SP 800-131A Revisie 2, Overgang van het gebruik van cryptografische algoritmen en sleutellengtes
• NIST CSRC: NIST trekt Special Publication 800-67 Revisie 2 (2023) in
• NIST SP 800-67 Revisie 2 (ingetrokken), Aanbeveling voor het Triple Data Encryption Algorithm (TDEA) blokcijfer
• Sweet32: Verjaardagsaanvallen op 64-bits blokcijfers in TLS en OpenVPN, Bhargavan en Leurent, ACM CCS 2016
• CVE-2016-2183, Nationale kwetsbaarheidsdatabase