ML-KEM versus ML-DSA versus SLH-DSA: Welk algoritme lost welk probleem op?

Kort antwoord: ML-KEM regelt de sleuteluitwisseling; ML-DSA en SLH-DSA regelen digitale handtekeningen. Het zijn geen concurrerende opties voor dezelfde taak, dus "welke moet ik gebruiken?" zijn eigenlijk twee aparte vragen: wat regelt de sleuteluitwisseling en wat ondertekent uw gegevens? ML-DSA is voor bijna iedereen de standaardoplossing voor digitale handtekeningen; SLH-DSA is een specifieke, bewuste uitzondering. Deze handleiding biedt een kader voor besluitvorming en een lijst met de meest voorkomende selectiefouten. Voor een volledige vergelijking van standaarden en gegevens over de implementatievolwassenheid, zie onze FIPS 203-, 204- en 205-handleiding.

"ML-KEM versus ML-DSA" is een van de meest voorkomende zoektermen in post-kwantumplanning, maar het is tegelijkertijd een enigszins onjuist geformuleerde vraag. De twee algoritmen concurreren niet om dezelfde positie in een systeem, zoals bijvoorbeeld twee TLS-coderingssuites dat wel zouden doen. Het ene algoritme stelt een gedeeld geheim vast; het andere bewijst wie een bericht heeft verzonden en dat het niet is gewijzigd. De meeste systemen hebben beide algoritmen tegelijkertijd nodig, maar ze voeren verschillende taken uit. De werkelijke beslissingspunten liggen elders: welke parameterreeks, of SLH-DSA een plaats verdient naast ML-DSA, en waar elk algoritme daadwerkelijk wordt geconfigureerd in een certificaatketen.

Key Takeaways

• ML-KEM (FIPS 203) is een sleutelinkapselingsmechanisme; ML-DSA (FIPS 204) en SLH-DSA (FIPS 205) zijn algoritmen voor digitale handtekeningen. Ze lossen verschillende problemen op en zijn niet uitwisselbaar.
• ML-DSA is in de praktijk de standaard voor digitale handtekeningen in vrijwel alle gevallen: certificeringsinstanties, codeondertekening, TLS en algemene authenticatie.
• SLH-DSA is een bewuste, beperkte uitzondering, gekozen wanneer een tweede, onafhankelijke beveiligingsveronderstelling belangrijker is dan prestaties of omvang.
• De meest voorkomende selectiefout is helemaal geen algoritmefout: het gaat erom dat de migratievolgorde wordt overgeslagen en dat bladcertificaten worden uitgegeven op basis van een nieuw algoritme voordat de CA-hiërarchie erachter is gemigreerd.
• CNSA 2.0-omgevingen vereisen specifiek ML-KEM-1024 en ML-DSA-87; de civiele standaarden (ML-KEM-768, ML-DSA-65) voldoen niet aan die vereiste.

De vraag die er echt toe doet: Wat bescherm je?

Voordat er parameterinstellingen of afwegingen op het gebied van prestaties worden gemaakt, begint de beslissing met de vraag wat de cryptografie precies doet.

• Het beschermen van gegevens tijdens de overdracht, of het vaststellen van een gedeeld geheim tussen twee partijen: Dat is de taak van ML-KEM. TLS-handshakes, VPN-tunnels, elke vorm van sleuteluitwisseling.
• Bewijzen wie iets heeft verzonden, of dat het niet is gewijzigd: Dat is de taak van een handtekeningalgoritme, bijna altijd ML-DSA. Certificaten, codeondertekening, firmwareondertekening, protocolauthenticatie.
• De behoefte aan een tweede, onafhankelijk ondertekeningsschema als verzekering tegen een toekomstige zwakte in de roostercryptografie: Dat is het specifieke, beperkte geval voor SLH-DSA, dat naast ML-DSA wordt toegepast in plaats van in plaats daarvan.

De meeste productiesystemen vereisen dat de eerste twee gelijktijdig draaien: ML-KEM om de verbinding tot stand te brengen en ML-DSA om de certificaten te authenticeren die de verbinding in eerste instantie betrouwbaar maakten.

Ontdek hoe HSM-as-a-Service en CodeSign Secure de beslissingen rondom sleuteluitwisseling en ondertekening afhandelen die in deze handleiding worden besproken.

Veelvoorkomende selectiefouten die we zien

Dit zijn de fouten die steeds weer terugkomen in PQC-planningsgesprekken, ongeveer in volgorde van hoe vaak ze daadwerkelijk problemen veroorzaken.

1. ML-KEM en ML-DSA als vervangers voor elkaar beschouwen: Het zijn geen concurrerende opties; een systeem heeft vrijwel altijd beide nodig, ingezet voor verschillende doeleinden. De vraag "moeten we ML-KEM of ML-DSA gebruiken?" voor één enkele use case is meestal een teken dat de use case nog niet is opgesplitst in de componenten voor sleuteluitwisseling en ondertekening.
2. Migreren van bladcertificaten vóór de CA-hiërarchie: Het uitgeven van een ML-DSA-bladcertificaat door een ECDSA-ondertekende certificeringsinstantie creëert geen werkende vertrouwensketen. Migratie moet eerst de root, vervolgens de certificeringsinstantie en daarna de bladcertificaten verplaatsen, in die volgorde.
3. Standaard kiezen voor SLH-DSA omdat het "veiliger klinkt": De hash-gebaseerde beveiliging van SLH-DSA is conservatief, maar de handtekeningen zijn 100 tot 700 keer groter dan die van ECDSA en het ondertekenen zelf duurt honderden milliseconden, in tegenstelling tot de lage enkele cijfers die ML-DSA haalt. Het is een bewuste afweging voor een specifieke risicotolerantie, geen algemeen sterkere standaard.
4. Het gebruik van civiele parameterreeksen in een CNSA 2.0-omgeving: ML-KEM-768 en ML-DSA-65 zijn de juiste standaardinstellingen voor de meeste bedrijfssystemen, maar CNSA 2.0 vereist specifiek ML-KEM-1024 en ML-DSA-87. Bouwen met de verkeerde parameterinstellingen vanaf het begin betekent dat het werk later opnieuw moet worden gedaan.
5. Ervan uitgaande dat HSM- en platformondersteuning uniform is voor alle drie de algoritmen: ML-KEM heeft momenteel de breedste ondersteuning voor browsers en TLS-bibliotheken; de ondersteuning voor ML-DSA op PKI-platformen voor bedrijven varieert per scenario, waarbij codeondertekening doorgaans de meest volwassen aanpak is; SLH-DSA wordt relatief weinig in productieomgevingen ingezet. Het controleren van de platformspecifieke volwassenheid voordat een implementatieplanning wordt vastgelegd, voorkomt dat een schema gebaseerd is op onjuiste aannames.

Waar elk algoritme zich daadwerkelijk bevindt in een certificaatketen

Een veelvoorkomende bron van verwarring: een TLS-certificaatketen gebruikt zowel een KEM als een handtekeningalgoritme, maar niet op de manier die men verwacht.

• De handtekening van het certificaat: de root ondertekent de uitgevende CA, de uitgevende CA ondertekent het blad, met behulp van ML-DSA. Dit bewijst de authenticiteit van de certificaatketen.
• De TLS-sleuteluitwisseling zelf: deze wordt apart onderhandeld met behulp van ML-KEM (doorgaans in een hybride constructie zoals X25519MLKEM768 tijdens de overgangsperiode). Deze is helemaal niet gecodeerd in de certificaatondertekening.
• Code- en firmwareondertekening: maakt gebruik van ML-DSA rechtstreeks op het artefact, volgens dezelfde logica als certificaatondertekening.

Simpel gezegd: het certificaat bewijst de identiteit met behulp van ML-DSA, en de verbinding die het beveiligt, onderhandelt over het gedeelde geheim met behulp van ML-KEM. Het verwarren van deze twee, of ervan uitgaan dat één veld in het certificaat beide configureert, is een veelvoorkomende oorzaak van configuratiefouten tijdens de eerste PQC-implementaties.

Snelle referentie

Situatie	Gebruik
TLS, VPN, elke vorm van sleuteluitwisseling	ML-KEM (768 civiel, 1024 CNSA 2.0)
Ondertekening door een certificeringsinstantie, codeondertekening, algemene authenticatie	ML-DSA (65 civiel, 87 CNSA 2.0)
Betrouwbare, kleinschalige en duurzame digitale handtekeningen, waarbij algoritmediversiteit van het grootste belang is.	SLH-DSA, gelaagd naast ML-DSA
Nationale veiligheidssystemen en defensie-industriële basis	ML-KEM-1024 en ML-DSA-87 in het bijzonder; SLH-DSA maakt geen deel uit van de CNSA 2.0-suite.

Voor een volledige vergelijking van de bytegrootte, een gedetailleerde analyse van de beveiligingsaspecten en een overzicht van de implementatievolwassenheid van deze aanbevelingen, raadpleegt u onze complete handleiding voor de FIPS 203-, 204- en 205-standaarden.

Wat we daadwerkelijk zouden aanbevelen

Stop met de vraag "ML-KEM of ML-DSA" als één vraag te stellen, maar stel die vraag twee keer: één keer voor de sleuteluitwisseling en één keer voor de ondertekening, voor elk systeem dat binnen het toepassingsgebied valt. Kies standaard voor ML-DSA voor ondertekeningen en beschouw SLH-DSA als een opt-in-optie die een eigen rechtvaardiging vereist, en niet als een noodoplossing die uit voorzorg wordt gekozen. Controleer welke parameterinstellingen uw regelgeving daadwerkelijk vereist voordat de implementatie begint, aangezien het achteraf aanpassen van CNSA 2.0-parameters aan een civiele implementatie duurder is dan vanaf dag één de juiste instellingen te implementeren.

Hoe encryptieconsultancy kan helpen

De twee vragen die centraal staan ​​in deze handleiding pleiten voor twee verschillende producten. Voor de ML-KEM-beslissing (sleuteluitwisseling, TLS, VPN, enz.) biedt HSM-as-a-Service FIPS-gevalideerd sleutelbeheer met de juiste parameters voor uw regelgevingsomgeving. Voor de ML-DSA- of SLH-DSA-beslissing (ondertekening, certificaten, code, firmware) zorgen CodeSign Secure en CertSecure Manager ervoor dat deze keuze in productie wordt genomen. CertSecure Manager behandelt specifiek de migratievolgorde van de root-CA, die in deze handleiding als de meest voorkomende fout wordt aangemerkt.

Onze PQC-adviesdiensten nemen de parameter- en volgordebeslissingen die in deze handleiding worden behandeld, op basis van een nauwkeurig beeld van de huidige status van uw cryptografie, root-first CA-migratie, de juiste parameterinstellingen per regelgevingsomgeving en een uitrolplan dat rekening houdt met de platformspecifieke implementatievolwassenheid in plaats van een standaardtijdlijn.

Twee vragen, niet één.

ML-KEM versus ML-DSA is in feite geen wedstrijd, en de meeste selectiefouten die teams maken, komen voort uit het feit dat ze het wel zo behandelen. De echte beslissingen gaan over welke parameterreeks van toepassing is op uw regelgevingsomgeving, of SLH-DSA een bewuste plaats verdient in uw ondertekeningsstrategie, en of uw migratievolgorde rekening houdt met het feit dat een certificaatketen eerst van root naar root moet worden verplaatst. Als u die drie zaken goed aanpakt, is de algoritmeselectie niet langer het moeilijkste onderdeel van een PQC-migratie.

Veelgestelde Vragen / FAQ

Kan ML-KEM worden gebruikt voor digitale handtekeningen, of ML-DSA voor sleuteluitwisseling?

Nee. ML-KEM is een sleutelinkapselingsmechanisme en produceert geen handtekeningen. ML-DSA is een handtekeningalgoritme en voert geen sleutelinkapseling uit. In tegenstelling tot RSA, dat historisch gezien beide taken kon uitvoeren, vervult geen van de huidige NIST-algoritmen uit het post-kwantumtijdperk beide functies.

Moet ik voor mijn certificaten kiezen tussen ML-DSA en SLH-DSA?

Voor de meeste organisaties is geen keuze nodig: ML-DSA is de standaard. SLH-DSA wordt doorgaans als aanvulling gebruikt en ingezet naast ML-DSA voor een specifieke subset van zeer betrouwbare, langdurige ondertekeningsscenario's, in plaats van als algemene vervanging.

Wat is de meest voorkomende fout bij de uitrol van ML-KEM en ML-DSA?

De volgorde is belangrijk, niet de keuze van het algoritme. Het uitgeven van bladcertificaten volgens het nieuwe algoritme voordat de uitgevende CA en de root zijn gemigreerd, verbreekt de vertrouwensketen die de migratie juist moest vestigen. De volgorde van migratie (root eerst) is belangrijker dan de specifieke parameterkeuze.

Is SLH-DSA veiliger dan ML-DSA?

Niet op een manier die het een betere algemene standaard maakt. SLH-DSA is gebaseerd op een andere, meer conservatieve beveiligingsveronderstelling: hashfunctiebeveiliging in plaats van roosterhardheid. Dit is waardevol als bescherming, maar het gaat gepaard met aanzienlijk grotere handtekeningen en een trager ondertekeningsproces. Het is een bewuste afweging, geen verbetering.

Welke parameterreeksen vereist CNSA 2.0?

ML-KEM-1024 voor sleutelgeneratie en ML-DSA-87 voor handtekeningen. De standaardalgoritmen voor civiel gebruik, ML-KEM-768 en ML-DSA-65, voldoen niet aan de CNSA 2.0-vereisten, en SLH-DSA maakt helemaal geen deel uit van de CNSA 2.0-algoritmesuite.