Quelle est la différence entre id_rsa.pub et id_dsa.pub?

Réponses:

64

id_rsa.pubet id_dsa.pubsont les clés publiques pour id_rsaet id_dsa.

Si vous demandez en relation avec SSH, id_rsaest une clé RSA et peut être utilisée avec le protocole SSH 1 ou 2, alors que id_dsac'est une clé DSA et ne peut être utilisée qu'avec le protocole SSH 2. Les deux sont très sécurisés, mais DSA semble être la norme de nos jours (en supposant que tous vos clients / serveurs prennent en charge SSH 2).

Mise à jour: Depuis que cela a été écrit, DSA s'est avéré non sécurisé. Plus d'informations disponibles dans la réponse ci-dessous.

Mike Pelley
la source
Je dois être en désaccord avec cela. Aujourd'hui (et, bien que dans une moindre mesure, également en 2010 lorsque cela a été publié), 1024 bits (la plus grande taille de clé disponible pour DSA) est considérée comme trop faible. Par conséquent, RSA est la meilleure option. Quant à SSH v1: je ne considérais pas cela comme sûr il y a dix ans.
Adam Katz
3
@AdamKatz DSA prend en charge les clés 2048 bits et 3072 bits depuis 2009 (selon FIPS 186-3 ). La plupart des clients / serveurs ssh prennent en charge des clés DSA plus volumineuses, notamment OpenSSH et PuTTY. La plupart des générateurs de clés prennent également en charge les clés DSA plus grandes, mais ssh-keygen d'OpenSSH ne le fait toujours pas (même si ssh et sshd le font). Pour Linux, vous pouvez générer des clés DSA plus volumineuses à l'aide d'OpenSSL, comme décrit dans cet article de blog .
Mike Pelley du
1
Intéressant! Je ne savais pas cela, et cela aide certainement à niveler le terrain entre les deux (bien que le manque de support OpenSSH soit assez accablant). Pourtant, je ne dirais pas que DSA est la norme (que ce soit maintenant ou en 2010), alors que RSA l'est absolument (et nous passons à des systèmes de courbes elliptiques comme Ed25519).
Adam Katz
46

SSH utilise des paires de clés publiques / privées , tout id_rsacomme votre clé privée RSA (basée sur des nombres premiers), qui est plus sécurisée que votre clé privée id_dsa DSA (basée sur des exposants). Gardez vos clés privées en sécurité et partagez vos clés publiques id_rsa.pubet vos id_dsa.pubclés largement.

DSA n'est pas sécurisé

DSA a un paramètre devinable si le générateur de nombres aléatoires de votre ordinateur est inférieur à la normale, ce qui révélera votre clé secrète. ECDSA (mise à niveau de la courbe elliptique de DSA) est également vulnérable . Même avec de bons nombres aléatoires, DSA a d' autres problèmes de forcePDF (on en trouve également dans Diffie-Hellman ).

OpenSSH crée des clés non sécurisées de 1024 bits ( solution de contournement ) et désactive désormais DSA par défaut .

Utilisez Ed25519 lorsque cela est possible

La cryptographie à courbe elliptique offre une complexité accrue avec des tailles de clé plus petites. Ed25519 (basé sur la complexité des courbes elliptiques modélisées en plan ) est l'implémentation préférée en raison de son absence présumée d'ingérence (des documents divulgués montrent que la NSA américaine affaiblit les normes de cryptographie ).

Malheureusement, Ed25519 est encore assez récent, nécessitant OpenSSH 6.5 ou GnuPG 2.1 (voir la liste complète ).

Utilisez RSA avec 4096 bits lorsque Ed25519 n'est pas disponible

Les tailles de clé RSA de 4096 bits doivent avoir une complexité comparable à Ed25519.

Ed25519 est toujours préféré à RSA en raison de la crainte que RSA ne soit vulnérable aux mêmes problèmes de force que DSA, bien que l'application de cet exploit à RSA soit considérablement plus difficile.

Adam Katz
la source
2
Juste une correction: DSA prend en charge les clés 2048 bits et 3072 bits depuis 2009 (selon FIPS 186-3 ). Plus d'informations dans mon commentaire ci-dessus.
Mike Pelley du
2
Infosec SE a une belle réponse à cette question qui va plus en profondeur. Il cite un discours de Black Hat 2013 qui suggère que DSA n'est plus sécurisé, même à des tailles de clé plus grandes.
Adam Katz
2
J'ai mis à jour cette réponse pour être plus complète sur les problèmes avec DSA. Elle est maintenant plus détaillée que la réponse (tout aussi valable) d'Infosec SE. Il y a encore plus de détails lorsque vous passez votre souris sur certains des liens.
Adam Katz
1
Ce message m'a tellement appris, a besoin de beaucoup plus de votes positifs.
liljoshu
1

rsa est considéré comme plus sûr.

Plus maintenant (mai 2020, dix ans plus tard), avec OpenSSH 8.2 , comme rapporté par Julio

Avis d'abandon futur

Il est désormais possible 1 d'effectuer des attaques avec préfixe choisi contre l'algorithme de hachage SHA-1 pour moins de 50 000 USD.
Pour cette raison, nous désactiverons l'algorithme de signature de clé publique "ssh-rsa" qui dépend par défaut de SHA-1 dans une version proche .

(Voir " SHA-1 est une pagaille: première collision de préfixes choisis sur SHA-1 et application au PGP Web of Trust " Leurent, G et Peyrin, T (2020))

Cet algorithme est malheureusement encore largement utilisé malgré l'existence de meilleures alternatives, étant le seul algorithme de signature de clé publique restant spécifié par les RFC SSH d'origine.

Les meilleures alternatives incluent:

  • Les algorithmes de signature RFC8332 RSA SHA-2 rsa-sha2-256 / 512.
    Ces algorithmes ont l'avantage d'utiliser le même type de clé que " ssh-rsa", mais utilisent les algorithmes de hachage SHA-2 sûrs.
    Ceux-ci sont pris en charge depuis OpenSSH 7.2 et sont déjà utilisés par défaut si le client et le serveur les prennent en charge.

  • L'algorithme de signature ssh-ed25519.
    Il est pris en charge dans OpenSSH depuis la version 6.5.

  • Les algorithmes ECDSA RFC5656: ecdsa-sha2-nistp256 / 384/521.
    Ceux-ci sont pris en charge par OpenSSH depuis la version 5.7.

Pour vérifier si un serveur utilise l'algorithme de clé publique ssh-rsa faible pour l'authentification de l'hôte, essayez de vous y connecter après avoir supprimé l' ssh-rsaalgorithme de la liste autorisée de ssh (1):

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Si la vérification de la clé d'hôte échoue et qu'aucun autre type de clé d'hôte pris en charge n'est disponible, le logiciel serveur de cet hôte doit être mis à niveau.

Une future version d'OpenSSH permettra UpdateHostKeyspar défaut de permettre au client de migrer automatiquement vers de meilleurs algorithmes.
Les utilisateurs peuvent envisager d'activer cette option manuellement .

VonC
la source
-8

On utilise DSA et on utilise RSA .

Yann Ramin
la source
en supposant que vous n'utilisez que les noms par défaut (qui logiquement cela lui ressemble), theatrus l'a frappé directement sur la tête.
David Larrabee
Vous n'avez pas répondu à la vraie partie de la question: qui est plus sûr. Un vote négatif car c'était la réponse la plus élevée N'a pas besoin de l'être.
akauppi