Existe-t-il une liste de chiffrements SSH faibles?
Existe-t-il un site qui fournit une liste de suites de chiffrement faibles pour (Open-) SSH? Je sais par exemple qu'arcfour n'est pas recommandé, mais il y a toute une liste d'autres suites de chiffrement proposées, dont je ne suis pas sûr.
Sur la plupart des systèmes, OpenSSH prend en charge AES, ChaCha20, Blowfish, CAST128, IDEA, RC4 et 3DES. Je suppose que vous parlez des chiffres symétriques utilisés. Si vous vous posez également des questions sur le HMAC et l'échange de clés, je peux modifier ma réponse pour expliquer lesquelles sont également fortes ou faibles.
Le bon
AES et ChaCha20 sont les meilleurs algorithmes actuellement pris en charge. AES est la norme de l'industrie et toutes les tailles de clés (128, 192 et 256) sont actuellement prises en charge avec une variété de modes (CTR, CBC et GCM). ChaCha20 est un chiffrement plus moderne et est conçu avec une marge de sécurité très élevée. C'est très rapide. Bien que AES soit sécurisé, le mode CBC entraîne un certain potentiel vulnérabilités , il n'est donc plus recommandé. Le mode CTR, ou mieux GCM, serait préféré. ChaCha20 d'autre part est un chiffrement de flux, il n'utilise donc pas un mode de fonctionnement par blocs et n'est donc pas en mesure d'utiliser CBC de manière non sécurisée. ChaCha20 utilise en outre Poly1305 pour l'authentification, rendant un HMAC inutile. Contrairement à un HMAC, Poly1305 ne repose pas sur l'hypothèse de sécurité de tout algorithme de hachage. Tant que le chiffrement sous-jacent est sécurisé, l'authentification ne sera pas interrompue.
Le mauvais
Blowfish, IDEA et CAST128 ne sont pas de mauvais chiffres en soi, mais ils ont une taille de bloc de 64 bits. Cela signifie que la clé doit être réamorcée périodiquement. De plus, 3DES, en raison d'une attaque de rencontre au milie , a sa sécurité effective réduite de 168 bits à 112 bits. Ce n'est pas horrible, mais ce n'est pas idéal. Le problème des tailles de blocs 64 bits est assez bien décrit sur le site Sweet32 , décrivant les attaques rendues possibles. L'essentiel est que le cryptage d'une grande quantité de données avec une seule clé peut divulguer des informations sur le texte en clair. Lorsque 32 GiB de données sont cryptées, les choses deviennent vraiment mauvaises. Il est souvent recommandé de changer les clés après chaque 4 Gio. Bien que les petites tailles de bloc ne soient pas importantes, OpenSSH réamorce automatiquement ces chiffres plus souvent que sinon pour tenter d'atténuer cette faille. Les chiffres eux-mêmes ne sont pas particulièrement mauvais. Ces chiffres, bien qu'anciens, ne sont pas soumis à des attaques connues qui permettent une rupture complète du chiffre. Il existe simplement de meilleures alternatives.
Le moche
Arcfour, ou RC4, n'est pas particulièrement sûr, comme vous l'avez dit. De graves biais statistiques sont connus depuis longtemps et de nouvelles attaques continuent d'être découvertes. Bien qu'OpenSSH supprime les 1536 premiers octets problématiques du chiffrement, il est toujours soumis à une variété d'autres attaques. Évitez d'utiliser RC4.
Dans l'ensemble, vous devez utiliser ChaCha20 ou AES et éviter RC4. Utilisez 3DES uniquement lorsque cela est nécessaire pour une compatibilité descendante. Les paramètres OpenSSH par défaut sur toute installation moderne devraient être corrects dans pratiquement toutes les circonstances. Vous ne pouvez pas vous tromper en utilisant les valeurs par défaut.
Pour ajouter à la réponse de la forêt, il existe des fonctions cryptographiques supplémentaires autres que le chiffrement symétrique comme le hachage (ou HMAC), le chiffrement à clé publique-privée et plus encore.
Le NIST 140-2 couvre tout cela. https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf