Le Meilleur Algorithme de Keygen Public et Privé – et Pourquoi

Gravitational a sponsorisé cet article.

Virag Mody
Virag a rejoint Gravitational en janvier 2020, après avoir cofondé une société d’audit de code logiciel pour les applications Ethereum. Il continue d’apprendre sur les technologies tendances et produit du contenu écrit et vidéo de haute qualité.

Qu’y a-t-il de pire que de laisser des clés privées sans surveillance? Avoir des clés publiques qui peuvent être forcées brutalement.

Le “secure” dans “secure shell” provient de la combinaison du hachage, du chiffrement symétrique et du chiffrement asymétrique. Ensemble, SSH utilise des primitives cryptographiques pour connecter en toute sécurité des clients et des serveurs. Au cours des 25 années qui ont suivi sa création, la puissance et les vitesses de calcul conformes à la loi de Moore ont nécessité des algorithmes de bas niveau de plus en plus compliqués.

En 2020, les algorithmes de cryptographie asymétrique les plus largement adoptés dans le monde des ICP sont RSA, DSA, ECDSA et EdDSA. Alors lequel est le meilleur?

Alors lequel utiliser?

Le choix du bon algorithme dépend de quelques critères:

  • Mise en œuvre: Les experts peuvent-ils le gérer ou doit-il être roulé?
  • Compatibilité : Existe-t-il des clients SSH qui ne prennent pas en charge une méthode ?
  • Performance : Combien de temps faudra-t-il pour générer une clé suffisamment sécurisée ?
  • Sécurité : La clé publique peut-elle être dérivée de la clé privée ? (L’utilisation de l’informatique quantique pour casser le chiffrement n’est pas abordée dans cet article.)

RSA

Implémentation Les bibliothèques RSA peuvent être trouvées pour tous les langages principaux, y compris les bibliothèques approfondies

(JS, Python, Go, Rust, C).

Compatibilité L’utilisation de SHA-1 (OpenSSH) ou de clés publiques sous 2048 bits peut ne pas être prise en charge.
Performances Les clés plus grandes nécessitent plus de temps pour être générées.
Security Des algorithmes spécialisés tels que le Tamis Quadratique et le Tamis de champ de nombres Généraux existent pour factoriser des entiers avec des qualités spécifiques.

Le temps a été le plus grand allié et le plus grand ennemi de RSA. Publié pour la première fois en 1977, RSA offre le support le plus large de tous les clients et langages SSH et a vraiment résisté à l’épreuve du temps en tant que méthode de génération de clés fiable. Par la suite, il a également été soumis à la loi de Moore pendant des décennies et la longueur du bit clé a augmenté en taille. Selon les normes du NIST, la sécurité 128 bits nécessite une clé d’une longueur de 3072 bits, alors que d’autres algorithmes utilisent des clés plus petites. La sécurité des bits mesure le nombre d’essais requis pour forcer brutalement une clé. la sécurité 128 bits signifie que 2128 essais doivent être interrompus.

AVD

La mise en œuvre DSA a été adoptée par la FIPS-184 en 1994. Il est largement représenté dans les principales bibliothèques cryptographiques, similaires à RSA.
Compatibilité Alors que DSA prend en charge les clients basés sur PuTTY, OpenSSH 7.0 désactive DSA par défaut.
Performance Amélioration significative des temps de génération de clés pour obtenir des forces de sécurité comparables, bien que la longueur de bits recommandée soit la même que RSA.
La sécurité DSA nécessite l’utilisation d’une valeur imprévisible et secrète générée aléatoirement qui, si elle est découverte, peut révéler la clé privée.

Ce qui rend DSA différent de RSA, c’est que DSA utilise un algorithme différent. Il résout un problème entièrement différent, connu sous le nom de problème du logarithme discret, en utilisant un ensemble différent d’équations, d’éléments et d’étapes.

Cet algorithme implique l’utilisation d’un nombre généré aléatoirement, m, qui est utilisé pour signer un message avec une clé privée, k. Ce nombre m doit être conservé en privé. La valeur mis signifiait être un nonce, qui est une valeur unique incluse dans de nombreux protocoles cryptographiques. Cependant, les conditions supplémentaires d’imprévisibilité et de secret rendent le nonce plus proche d’une clé, et donc extrêmement important.

Note du sponsor

 logo du sponsor

Gravitational propose aux systèmes d’exploitation de fournir, d’accéder et de gérer des applications cloud natives sur n’importe quelle infrastructure avec un effort minimal. Teleport est notre passerelle de sécurité pour la gestion des accès privilégiés à l’infrastructure serveur via SSH et Kubernetes. Essayez-les à gravitational.com .

Non seulement il est difficile d’assurer un véritable caractère aléatoire au sein d’une machine, mais une implémentation incorrecte peut casser le chiffrement. Par exemple:

  1. La classe Java SecureRandom d’Android était connue pour créer des valeurs R en collision. En d’autres termes, la classe a réutilisé certains nombres générés aléatoirement. Cela a exposé un certain nombre de différents portefeuilles Bitcoin basés sur Android à se faire voler leurs clés privées. Les exigences du nonce m signifient que deux instances quelconques avec la même valeur de nonce pourraient être rétroconcentrées et révéler la clé privée utilisée pour signer les transactions.
  2. En allant plus loin, fail0verflow a découvert la clé privée utilisée pour signer les mises à jour du micrologiciel de la Sony Playstation 3. En d’autres termes, les programmeurs pouvaient écrire leur propre code, le signer avec la clé privée révélée et l’exécuter sur la PS3. Il s’avère que Sony utilisait le même nombre aléatoire pour signer chaque message.

ECDSA et EdDSA

Les deux exemples ci-dessus ne sont pas entièrement sincères. Sony et le protocole Bitcoin utilisent tous deux ECDSA, pas DSA proprement dit. ECDSA est une implémentation de courbe elliptique de DSA. Fonctionnellement, là où RSA et DSA nécessitent des longueurs de clé de 3072 bits pour fournir 128 bits de sécurité, ECDSA peut accomplir la même chose avec seulement des clés de 256 bits. Cependant, ECDSA repose sur le même niveau d’aléatoire que DSA, donc le seul gain est la vitesse et la longueur, pas la sécurité.

En réponse aux vitesses souhaitées des courbes elliptiques et aux risques de sécurité indésirables, une autre classe de courbes a acquis une certaine notoriété. EdDSA résout le même problème de log discret que DSA/ECDSA, mais utilise une famille différente de courbes elliptiques connue sous le nom de courbe d’Edwards (EdDSA utilise une courbe d’Edwards torsadée). Tout en offrant de légers avantages en termes de vitesse par rapport à l’ECDSA, sa popularité provient d’une amélioration de la sécurité. Au lieu de compter sur un nombre aléatoire pour la valeur nonce, EdDSA génère un nonce de manière déterministe sous forme de hachage, ce qui le rend résistant aux collisions.

Prenant du recul, l’utilisation de courbes elliptiques ne garantit pas automatiquement un certain niveau de sécurité. Toutes les courbes ne sont pas les mêmes. Seules quelques courbes ont passé des tests rigoureux. Heureusement, l’industrie de l’ICP a lentement adopté Curve25519 — en particulier pour l’EdDSA. Mis ensemble, cela rend l’algorithme de signature à clé publique, Ed25519.

L’implémentation EdDSA est assez nouvelle. Crypto++ et cryptlib ne prennent actuellement pas en charge EdDSA.
Compatibilité Compatible avec les nouveaux clients, Ed25519 a connu la plus grande adoption parmi les courbes Edward; bien que le NIST ait également proposé Ed448 dans son récent projet de SP 800-186.
Performance Ed25519 est l’algorithme le plus performant de toutes les métriques. Comme avec ECDSA, les clés publiques ont une longueur deux fois supérieure à la sécurité de bits souhaitée.
Security EdDSA offre le niveau de sécurité le plus élevé par rapport à la longueur de clé. Il améliore également les insécurités trouvées dans l’ECDSA.

Fondamentalement, RSA ou EdDSA

Quand il s’agit de cela, le choix est entre RSA 2048/4096 et Ed25519 et le compromis est entre performances et compatibilité. RSA est universellement pris en charge parmi les clients SSH, tandis qu’EdDSA fonctionne beaucoup plus rapidement et offre le même niveau de sécurité avec des clés nettement plus petites. Peter Ruppel donne une réponse succincte:

“La réponse courte à cela est: tant que la force clé est suffisante pour un avenir prévisible, cela n’a pas vraiment d’importance. Parce que nous envisageons ici une signature pour l’authentification au sein d’une session SSH. La force cryptographique de la signature doit simplement résister aux attaques actuelles à la pointe de la technologie.” – Ed25519 pour SSH

N’utilisez simplement pas ECDSA /DSA!

Image de fonctionnalité via.

La nouvelle pile est une filiale en propriété exclusive d’Insight Partners, un investisseur dans les sociétés suivantes mentionnées dans cet article: Bit.

Leave a Reply