SSH-sleutels vergelijken: RSA, DSA, ECDSA of EdDSA

De keuze van het SSH-sleutelalgoritme (Secure Shell) bepaalt de cryptografische basis van elke authenticatie voor toegang op afstand in uw infrastructuur. RSA, DSA, ECDSA en EdDSA (Ed25519) hebben fundamenteel verschillende beveiligingseigenschappen, sleutelgroottes, prestatiekenmerken en compliance-status. DSA is verouderd (uitgeschakeld in OpenSSH 7.0+; door NIST afgekeurd in FIPS 186-5). Ed25519 is de moderne standaard: deterministische handtekeningen, implementatie met constante tijd, beveiliging equivalent aan 128 bits en de kleinste sleutelgroottes van alle gangbare SSH-algoritmen. In omgevingen met compliance-eisen (PCI DSS, NIST SP 800-53, FedRAMP) is de algoritmekeuze een governancebeslissing met gevolgen voor audits. De aanbevolen actie: migreer naar Ed25519 voor alle nieuwe SSH-sleutelimplementaties; gebruik RSA-4096 alleen voor legacy-systemen die Ed25519 niet ondersteunen; Plan de migratie van DSA naar een ander platform als een prioritaire herstelmaatregel.

Kort antwoord: Welk SSH-sleutelalgoritme moet je gebruiken?

Ed25519 voor alle nieuwe SSH-implementaties. Het biedt een beveiliging die ongeveer gelijk is aan 128-bits beveiliging, deterministische handtekeningen (waardoor de nonce-foutklasse wordt geëlimineerd), constante bewerkingstijd en de kleinste sleutel- en handtekeninggroottes van alle gangbare SSH-algoritmen. Moderne OpenSSH gebruikt standaard Ed25519. RSA-4096 met SHA-2-handtekeningen is een fallback voor oudere systemen die Ed25519 niet ondersteunen. Vermijd DSA volledig: het is door NIST afgekeurd, standaard uitgeschakeld in OpenSSH 7.0+, beperkt tot een beveiliging die gelijk is aan 80-bits beveiliging en kwetsbaar voor sleutelherstel met hergebruik van de nonce. ECDSA is acceptabel, maar Ed25519 heeft de voorkeur. Voor grootschalig beheer van de levenscyclus van SSH-sleutels, zie SSH Secure en ons artikel over SSH-sleutelrotatiebeleid.

Wat zijn SSH-sleutels?

SSH-sleutels zijn asymmetrische cryptografische sleutelparen die worden gebruikt om gebruikers of servers via SSH te authenticeren zonder wachtwoorden over het netwerk te versturen. Elk paar bestaat uit een privésleutel die op het clientapparaat blijft en een publieke sleutel die wordt toegevoegd aan het authorized_keys-bestand van de server voor het betreffende gebruikersaccount. Bij het verbinden controleert de server via een uitdaging-antwoorduitwisseling of de client de privésleutel bezit die overeenkomt met de geautoriseerde publieke sleutel; de privésleutel wordt nooit verzonden.

De beveiliging berust op asymmetrische (publieke-sleutel)cryptografie : de privé- en publieke sleutel zijn wiskundig aan elkaar gekoppeld, zodat een bericht dat met de privésleutel is ondertekend, alleen kan worden geverifieerd met de bijbehorende publieke sleutel. De privésleutel kan echter niet binnen een praktisch tijdsbestek uit de publieke sleutel worden afgeleid. Het specifieke algoritme (RSA, DSA, ECDSA, EdDSA) definieert het wiskundige probleem waarop deze asymmetrie is gebaseerd en bepaalt hoe handtekeningen worden gegenereerd, hoe ze worden geverifieerd en wat de rekenkosten van elke bewerking zijn.

De SSH-authenticatiehandshake werkt als volgt:

1. De client initieert een SSH-verbinding met de server en presenteert zijn publieke sleutel.
2. De server controleert of die publieke sleutel is opgenomen in het authorized_keys-bestand voor het betreffende gebruikersaccount.
3. Indien gevonden, genereert de server een willekeurige uitdaging en versleutelt deze met behulp van de publieke sleutel van de client.
4. De server stuurt de uitdaging naar de client.
5. De client decodeert de uitdaging met behulp van zijn privésleutel en stuurt het antwoord terug.
6. De server verifieert het antwoord en bevestigt dat de client de privésleutel bezit, zonder dat de sleutel daadwerkelijk wordt verzonden.

SSH-sleutels worden niet alleen gebruikt voor interactieve aanmeldingen, maar ook voor bestandsoverdracht (SCP, SFTP ), port forwarding, tunneling, Git-bewerkingen en geautomatiseerde machine-naar-machinecommunicatie in CI/CD-pipelines.

De vier SSH-sleutelalgoritmes

RSA is de historische standaard; DSA is verouderd (afgeschreven); ECDSA is een alternatief met elliptische krommen; EdDSA (Ed25519) is de moderne standaard voor nieuwe installaties. OpenSSH ondersteunt RSA, ECDSA en Ed25519; moderne versies gebruiken standaard Ed25519 als er geen type is opgegeven.

RSA (Rivest-Shamir-Adleman)

RSA is gebaseerd op de wiskundige moeilijkheid om zeer grote gehele getallen te ontbinden in priemfactoren. De beveiliging hangt sterk af van de sleutellengte: 1024-bits sleutels zijn niet langer veilig; RSA-2048 is het minimaal acceptabele niveau; RSA-3072 of RSA-4096 is geschikt voor nieuwe implementaties. OpenSSH ondersteunt RSA en maakt het mogelijk om sleutels te genereren met de optie -t rsa.

Sterke punten van RSA: Het belangrijkste voordeel van RSA is de compatibiliteit. Het werkt met oudere servers, netwerkapparaten, automatiseringstools en bedrijfsproducten die mogelijk geen ondersteuning bieden voor nieuwere algoritmen. In een infrastructuur met verschillende generaties is RSA de minst storende compatibiliteitsoplossing. RSA heeft bovendien tientallen jaren operationele ervaring: beheerders zijn vertrouwd met het controleren, roteren en oplossen van problemen met op RSA gebaseerde SSH-toegang.

Beperkingen van RSA: RSA-sleutels zijn aanzienlijk groter dan sleutels gebaseerd op elliptische krommen bij een vergelijkbaar beveiligingsniveau: meer opslagruimte, meer bandbreedte en tragere bewerkingen. Veel discussies over het uitfaseren van RSA gaan specifiek over het oudere ssh-rsa SHA-1-ondertekeningsschema in plaats van RSA zelf; moderne RSA met SHA-2-ondertekeningen (rsa-sha2-256, rsa-sha2-512) blijft acceptabel bij 3072+ bits.

RSA-gebruiksscenario: een verouderde bastionhost of een apparaat van een leverancier dat alleen RSA-sleutels accepteert. In deze omgevingen is RSA-4096 met SHA-2-handtekeningen mogelijk de enige praktische optie totdat de hardware of firmware is geüpgraded om Ed25519 te ondersteunen.

DSA (Digitaal Handtekening Algoritme)

DSA werd in het verleden gebruikt in SSH, maar is al lang geleden afgekeurd en uitgeschakeld in moderne implementaties. Gebruik DSA niet voor nieuwe SSH-implementaties en beschouw bestaande DSA-sleutels als een prioritaire migratie-item.

Waarom is DSA verouderd? Drie concrete, goed gedocumenteerde redenen:

• Het SSH-protocol beperkt DSA-sleutels tot maximaal 1024 bits, wat slechts een beveiliging biedt die overeenkomt met ongeveer 80 bits, ruim onder de 112 bits die NIST sinds 2014 vereist voor nieuwe cryptografische projecten.
• DSA-handtekeningen vereisen een geheime, willekeurige nonce per handtekening. Als die nonce ooit herhaald of voorspelbaar is, kan de privésleutel wiskundig worden gereconstrueerd uit twee handtekeningen. Incidenten in de praktijk (PlayStation 3 jailbreak, gecompromitteerde Bitcoin-wallets) hebben deze foutklasse herhaaldelijk aangetoond.
• NIST heeft DSA voor het genereren van handtekeningen formeel afgekeurd in FIPS 186-5 (2023), waardoor DSA een nalevingsverplichting vormt in elke gereguleerde omgeving.

OpenSSH 7.0 en latere versies schakelen DSA standaard uit om deze redenen. Op elk huidig ​​systeem werken DSA-sleutels niet zonder expliciet een verouderd algoritme opnieuw in te schakelen. Dit is een signaal om te migreren in plaats van opnieuw in te schakelen.

DSA-scenario: overgenomen omgevingen met een server die al lange tijd in gebruik is en nooit is gemoderniseerd. De juiste reactie is migratieplanning, niet voortgezet gebruik.

ECDSA (Elliptic Curve Digital Signature Algorithm)

ECDSA maakt gebruik van elliptische-curve-cryptografie , wat een sterke beveiliging biedt met veel kleinere sleutels dan RSA. SSH ondersteunt curvegroottes van 256, 384 en 521 bits (P-256, P-384, P-521). ssh-keygen dwingt deze specifieke groottes af.

Sterke punten van ECDSA: goede prestaties en kleine sleutelgroottes in vergelijking met RSA. Nuttig in omgevingen met beperkte middelen waar sleutelgrootte en transmissieoverhead van belang zijn.

Beperkingen van ECDSA: ECDSA deelt de nonce-afhankelijkheid met DSA: handtekeningen vereisen een willekeurige waarde per handtekening, en een slechte generator voor willekeurige getallen kan het mogelijk maken om de privésleutel te achterhalen. Ed25519 heeft over het algemeen de voorkeur omdat het deterministische handtekeningschema dit risico volledig elimineert. De NIST P-curves van ECDSA hebben ook vragen opgeroepen over mogelijke manipulatie, hoewel er geen exploiteerbare zwakte is aangetoond.

ECDSA-gebruiksscenario: een beperkte productieomgeving waar elliptische-curve-cryptografie vereist is en de softwarestack ECDSA al goed ondersteunt. Voor nieuwe implementaties zonder deze beperking is Ed25519 de betere standaardkeuze.

EdDSA / Ed25519

EdDSA is een moderne familie van digitale handtekeningschema's; in de SSH-praktijk verwijst het bijna altijd naar Ed25519 (gebaseerd op Curve25519, wat een beveiliging biedt die ongeveer gelijkwaardig is aan 128 bits). OpenSSH heeft ondersteuning voor Ed25519 toegevoegd in versie 6.5 en de huidige releases gebruiken standaard Ed25519 wanneer er geen algoritme is gespecificeerd.

Sterke punten van Ed25519: snel, compact en standaard veilig. Belangrijkste verschillen met DSA en ECDSA: handtekeningen worden deterministisch gegenereerd met behulp van een hash van de privésleutel en het bericht (niet een willekeurige nonce), waardoor de nonce-foutklasse volledig wordt geëlimineerd. Bewerkingen worden in constante tijd uitgevoerd om side-channel-aanvallen te weerstaan. De sleutelgroottes zijn de kleinste van alle gangbare SSH-algoritmen. Curve25519 is ontworpen met implementatieveiligheid als primair doel.

Beperkingen van Ed25519: compatibiliteit met zeer oude SSH-servers, apparaten of beheerde services. Zeer oude systemen ondersteunen Ed25519 mogelijk niet, waardoor RSA als alternatief nodig is. Deze compatibiliteitsproblemen komen steeds minder vaak voor naarmate de infrastructuur wordt gemoderniseerd.

Ed25519 gebruiksscenario: de standaardkeuze voor alle moderne SSH-implementaties. Een software-engineer die een persoonlijke SSH-sleutel genereert voor GitHub, GitLab of een productiebastionhost; een automatiseringssysteem dat veilige, niet-interactieve toegang vereist; elke nieuwe SSH-implementatie waarbij compatibiliteit met zeer oude systemen geen beperking vormt.

Vergelijking naast elkaar

Algoritme	Security	Prestaties	Sleutelgrootte	Compatibiliteit	Status	Aanbevolen voor
RSA-4096	Sterk (SHA-2 handtekeningen)	Trage keygen en ondertekening	Groot	Uitstekend (alle systemen)	Geaccepteerd; gebruik SHA-2	Verouderde systemen en maximale compatibiliteit
RSA-2048	Minimaal acceptabel (~112-bit)	Sneller dan 4096	Groot	Uitstekend	Minimum; migreer naar 3072+	Alleen beperkingen uit het verleden
DSA	Zwakke beveiliging (1024-bit, ~80-bit)	Traag; nonce-afhankelijk	Gemiddeld	Uitgeschakeld in OpenSSH 7.0+	Verouderd (FIPS 186-5, 2023)	Niet gebruiken; behandelen als migratieprioriteit
ECDSA P-256	Sterk; gevoelig voor incidenten	Snel	Klein	Goed (moderne systemen)	Aanvaard	Bestaande ECDSA-implementaties of vereisten voor elliptische krommen
EdDSA / Ed25519	Zeer sterk (~128-bit; deterministisch)	Zeer snel; constante tijd	Heel klein	Sterk in moderne systemen	Aanbevolen (moderne standaard)	Alle nieuwe SSH-implementaties

Gids voor algoritmeselectie

Voor nieuwe systemen: Ed25519. De beste balans tussen beveiliging, prestaties en eenvoud; standaard in moderne OpenSSH; geen risico op nonce-fouten; implementatie met constante uitvoeringstijd.

Voor compatibiliteit met oudere systemen: gebruik RSA-4096 met SHA-2-handtekeningen (rsa-sha2-256 of rsa-sha2-512) bij verbinding met oudere servers, apparaten of software die Ed25519 niet ondersteunen. Controleer of u een modern handtekeningschema gebruikt en niet de verouderde, op sha-1 gebaseerde ssh-rsa-variant.

Voor speciale gevallen: ECDSA met P-256 of sterker wanneer er een specifieke vereiste is voor elliptische curve-cryptografie en Ed25519 niet beschikbaar is. Zorg ervoor dat de RNG die tijdens het ondertekenen wordt gebruikt, cryptografisch sterk is.

DSA: niet gebruiken. Beschouw bestaande DSA-sleutels als een prioritaire migratie-item, ongeacht de omgeving.

Praktische migratiestrategie: gebruik zowel RSA als Ed25519 tijdens de overgangsperiode. Behoud RSA alleen voor systemen die Ed25519 nog niet ondersteunen en bouw het geleidelijk af naarmate die systemen worden geüpgraded.

1. Genereer een nieuwe Ed25519-sleutel als primaire SSH-identiteit.
2. Bewaar een RSA-4096-sleutel alleen voor systemen die deze vereisen.
3. Voeg beide publieke sleutels waar nodig toe aan authorized_keys.
4. Monitor welke sleutels nog steeds in gebruik zijn via SSH-toegangslogboeken en sleutelvingerafdrukken.
5. Verwijder RSA-sleutels zodra de verouderde systemen die ze nodig hebben, worden geüpgraded of buiten gebruik worden gesteld.

Beheer van de levenscyclus van SSH-sleutels en toegangsbeleid

De keuze van het algoritme is slechts de eerste beslissing in het beheer van SSH-sleutels. De levenscyclus van elke sleutel vereist actief beheer:

• Levenscyclusverantwoordelijkheid: Elke SSH-sleutel moet een gedocumenteerde eigenaar hebben. Sleutels zonder eigenaar worden voor onbepaalde tijd opgeslagen in authorized_keys-bestanden. Wijs eigenaarschap toe bij het genereren van de sleutel; houd dit bij in een centrale inventaris.
• Rotatietriggers: Op basis van tijd (minimaal jaarlijks); vertrek van een medewerker of functieverandering (onmiddellijk); vermoedelijke of bevestigde inbreuk (onmiddellijk); uitfasering van een algoritme (onmiddellijk); herinstallatie van het systeem.
• Toegangsbeleid: Handhaaf het principe van minimale bevoegdheden; elke gebruiker moet een uniek sleutelpaar hebben; SSH-sleutels mogen niet worden gedeeld tussen gebruikers; root-sleutels vereisen aanvullende controles en goedkeuringsprocedures.
• Controlebewijs: Registreer alle SSH-toegangsgebeurtenissen met sleutelvingerafdruk, tijdstempel, bron-IP-adres en doelgebruiker. Bewaar deze gegevens voor nalevingsdoeleinden (PCI DSS, NIST SP 800-53, ISO 27001).
• Rotatieproces: Een nieuw sleutelpaar genereren; de nieuwe publieke sleutel distribueren naar alle geautoriseerde servers; controleren of de nieuwe sleutel correct authenticeert; de oude publieke sleutel verwijderen uit de authorized_keys-bestanden van alle servers; de inventaris bijwerken.

Voor het beheer van de levenscyclus van SSH-sleutels op bedrijfsniveau, zie SSH Secure en ons artikel over het ontwerpen van een beleid voor het roteren van SSH-sleutels.

Post-kwantumoverwegingen voor SSH-sleutels

Alle vier de hier besproken SSH-sleutelalgoritmen zijn kwetsbaar voor een voldoende krachtige kwantumcomputer die het algoritme van Shor uitvoert. Dit algoritme kan zowel integerfactorisatie (RSA, DSA) als elliptische curve discrete logaritme (ECDSA, EdDSA) in polynomiale tijd kraken. Cryptografisch relevante kwantumcomputers bestaan ​​nog niet, maar organisaties met langetermijnvereisten voor geheimhouding zouden moeten beginnen met de planning voor post-kwantumcryptografie.

Post-quantum sleuteluitwisseling (KEX) in SSH: OpenSSH 10.0 introduceerde mlkem768x25519-sha256 als de standaard sleuteluitwisseling, een combinatie van de klassieke X25519 met ML-KEM-768 (NIST-gestandaardiseerde CRYSTALS-Kyber, FIPS 203 ). Deze hybride constructie beschermt de vertrouwelijkheid van de sessie: de sessiesleutel wordt afgeleid van beide componenten en blijft veilig zolang een van beide algoritmen geldig is. Dit pakt direct Harvest-Now, Decrypt-Later- aanvallen aan die gericht zijn op opgenomen SSH-sessies. In eerdere OpenSSH-versies 9.0 tot en met 9.9 is sntrup761x25519-sha512 beschikbaar en verdient de voorkeur boven pure klassieke sleuteluitwisseling voor zeer gevoelig verkeer.

Post-quantum SSH-authenticatiesleutels: nog in een vroeg ontwikkelingsstadium. NIST-goedgekeurde post-quantum handtekeningalgoritmen (ML-DSA / CRYSTALS-Dilithium, FIPS 204) zullen naar verwachting in toekomstige OpenSSH-releases beschikbaar komen voor authenticatie. Ed25519 blijft momenteel de beste praktische keuze voor SSH-authenticatie; migreer naar post-quantum authenticatiesleutels wanneer deze gestandaardiseerd zijn in OpenSSH en het bredere ecosysteem er klaar voor is.

Hoe encryptieconsultancy kan helpen

SSH Secure biedt end-to-end beheer van de levenscyclus van SSH-sleutels met volledig inzicht en controle op bedrijfsniveau:

• Gecentraliseerde zichtbaarheid en eigendomsregistratie: Zowel agentgebaseerde als agentloze detectie lokaliseert elke SSH-sleutel op servers en gebruikerscomputers; alle sleutels worden opgeslagen in één inventaris met eigendoms- en gebruiksgegevens, waardoor ongebruikte sleutels worden geëlimineerd en de sleutelverspreiding wordt verminderd.
• Veilige toegangscontrole: Gedetailleerde RBAC zorgt ervoor dat gebruikers de minimaal vereiste toegang krijgen; tijdelijke, aan de sessie gebonden sleutels voor gevoelige bewerkingen die automatisch verlopen.
• Geautomatiseerde orkestratie van de levenscyclus van sleutels: Geautomatiseerde generatie met behulp van Ed25519, ECDSA en RSA-4096; beleidsgestuurde rotatie, geplande vervaldatum en intrekking; levenscyclusbeheer elimineert zwakke en verouderde sleutels.
• HSM-geïntegreerde bescherming van privésleutels: Privésleutels beveiligd binnen HSM's; niet-exporteerbaar; fraudebestendig; geïsoleerd tegen compromittering op besturingssysteemniveau en geheugenuitleesaanvallen.
• Beleidsgestuurde kernactiviteiten: Alle processen met betrekking tot generatie, goedkeuring, rotatie en intrekking worden afgedwongen via beleidsmatige controles; consistent in de gehele omgeving; aanpasbaar aan wettelijke vereisten.
• Continue monitoring, audits en paraatheid voor naleving: Realtime monitoring met detectie van afwijkingen; integratie met Splunk en Loki-Grafana; downloadbare auditlogboeken en compliance-rapporten.

Conclusie

De keuze van het SSH-sleutelalgoritme is een beveiligingsbeslissing met implicaties voor compliance. RSA biedt compatibiliteit met oudere omgevingen; DSA is verouderd en uitgeschakeld in moderne SSH-implementaties en moet onmiddellijk worden vervangen; ECDSA is een geldige optie voor elliptische curven, maar vereist zorgvuldig beheer van de willekeurige getallengenerator (RNG); Ed25519 is de duidelijke aanbeveling voor alle nieuwe SSH-implementaties en biedt de sterkste combinatie van beveiliging, prestaties, eenvoud en eliminatie van kwetsbaarheden op implementatieniveau. Combineer Ed25519 met OpenSSH 10.0 of hoger om te profiteren van post-quantum sleuteluitwisseling die de vertrouwelijkheid van sessies al beschermt. Naast de algoritmekeuze hangt de beveiliging van SSH-sleutels af van het beheer van de levenscyclus van sleutels, dat bepaalt hoe sleutels worden beheerd, geroteerd, ingetrokken en gecontroleerd. De keuze van het algoritme en het beheer van de levenscyclus bepalen samen de daadwerkelijke beveiligingsstatus van SSH-toegang in uw omgeving. Lees voor meer informatie onze artikelen over wachtwoordloze SSH-authenticatie , SSH-sleutelrotatiebeleid en SSH Secure.

Veelgestelde Vragen / FAQ

Welk SSH-sleutelalgoritme moet ik in 2026 gebruiken?

Ed25519 voor alle nieuwe SSH-implementaties: biedt ongeveer 128-bits beveiliging, deterministische handtekeningen (geen risico op nonce-fouten), constante bewerkingstijd en de kleinste sleutelgroottes van alle gangbare algoritmen. Moderne OpenSSH gebruikt standaard Ed25519. RSA-4096 met SHA-2 voor oudere systemen; vermijd DSA volledig.

Waarom is DSA afgekeurd voor SSH?

Drie redenen: 1) Het SSH-protocol beperkt DSA tot 1024-bits sleutels (~80-bits beveiliging, onder het NIST-minimum van 112 bits). 2) DSA-handtekeningen vereisen een willekeurige nonce per handtekening; hergebruik of voorspelbaarheid van de nonce maakt herstel van de privésleutel mogelijk (aangetoond in PlayStation 3 en Bitcoin-wallets). 3) NIST heeft DSA voor het genereren van handtekeningen afgekeurd in FIPS 186-5 (2023). OpenSSH 7.0+ schakelt DSA standaard uit.

Wat is het verschil tussen ECDSA en Ed25519 voor SSH?

Beide methoden maken gebruik van elliptische-curve-cryptografie met compacte sleutelgroottes. Het belangrijkste verschil: Ed25519 genereert handtekeningen deterministisch (hash van de privésleutel en het bericht, geen willekeurige nonce), waardoor de nonce-foutklasse die ECDSA treft, wordt geëlimineerd. Ed25519 werkt in constante tijd (bestand tegen side-channel-aanvallen); de veiligheid van ECDSA is afhankelijk van de kwaliteit van de willekeurige getallengenerator. Ed25519 heeft de voorkeur voor nieuwe implementaties.

Hoe moeten SSH-sleutels op bedrijfsniveau worden geroteerd en beheerd?

Vereist: een gecentraliseerde inventaris die elke geautoriseerde sleutel koppelt aan een eigenaar; beleidsmatig gedefinieerde rotatieschema's (minimaal jaarlijks; onmiddellijk bij vertrek, inbreuk of verval); geautomatiseerde sleutelgeneratie, -distributie en -verwijdering; en continue auditregistratie. Handmatig beheer over honderden servers is niet schaalbaar; SSH-sleutelbeheerplatformen verzorgen de detectie, rotatie en intrekking centraal.

Zijn SSH-sleutels kwetsbaar voor aanvallen met kwantumcomputers?

Ja. Alle vier de algoritmen zijn kwetsbaar voor het algoritme van Shor op een kwantumcomputer. OpenSSH 10.0 introduceerde mlkem768x25519-sha256 als de standaard sleuteluitwisseling (hybride klassiek + ML-KEM-768) om de vertrouwelijkheid van sessies te beschermen. SSH-authenticatiesleutels voor na het kwantumtijdperk zijn nog in ontwikkeling; Ed25519 blijft momenteel de beste authenticatiekeuze.

Welke compliance-kaders zijn van toepassing op de selectie van SSH-sleutelalgoritmen?

NIST SP 800-53 (Systeem- en communicatiebeveiliging); NIST SP 800-57 (sleutelbeheer); PCI DSS v4.0 Vereiste 2.2.7 (sterke cryptografie voor administratieve toegang buiten de console); FIPS 186-5 (formeel afgeschafte DSA); NIST SP 800-131A (goedgekeurde algoritmen: minimaal RSA-2048, Ed25519 en ECDSA P-256+ goedgekeurd).