Pourquoi une clé Blowfish plus longue ne corrige pas un bloc de 64 bits

Un profil VPN propose Blowfish avec une clé de 448 bits, et quelqu'un suggère d'utiliser la clé la plus longue pour conserver le chiffrement. La longueur de clé est réelle, mais ce n'est pas le bon nombre à optimiser. Blowfish transforme des blocs de 64 bits quelle que soit la longueur de la clé, et c'est la largeur du bloc qui limite la quantité de trafic qu'une clé peut protéger en sécurité. Exécutez les vérifications ci-dessous dans l'ordre et arrêtez-vous à la première qui disculpe le service, car une étape ultérieure ne peut pas réparer une étape antérieure.

Vérifiez ce que les pairs négocient réellement

Lisez le chiffrement du canal de données aux deux extrémités, pas dans le profil que vous comptiez déployer. Une configuration client peut lister plusieurs chiffrements, et celui qui est retenu résulte de la négociation entre deux implémentations et leurs versions. Augmentez la verbosité des journaux sur une connexion de test et lisez la ligne du canal de données, qui nomme le chiffrement et la taille de clé réellement initialisés.

Si le chiffrement négocié est AES-GCM ou ChaCha20-Poly1305, arrêtez-vous ici. Ces constructions utilisent un bloc de 128 bits et authentifient la charge utile, donc l'argument de collision sur 64 bits ci-dessous ne s'applique pas à elles.

Séparez la longueur de clé de la largeur de bloc

Blowfish accepte des clés de 32 à 448 bits, et la documentation de l'auteur de l'algorithme indique les deux nombres séparément. La clé est le secret ; le bloc est l'unité de transformation. Allonger le secret rend la devinette plus difficile et ne change rien à la largeur du bloc que le chiffrement traite.

En mode CBC, le chiffrement s'applique à des blocs de largeur fixe, chaînés avec le bloc de texte chiffré précédent et complétés à la fin. Pour Blowfish, cette largeur est de 64 bits, soit huit octets. Le calendrier de clé peut être aussi grand que vous voulez ; la chaîne avance toujours de huit octets à la fois.

C'est pourquoi allonger la clé n'est pas une mesure d'atténuation. Cela vise la force brute contre la clé, alors que le risque de collision ci-dessous est une propriété de la largeur de bloc et du mode.

Appliquez l'arithmétique des anniversaires à la taille du bloc

Un bloc de 64 bits a une échelle d'anniversaire d'environ 2^32 blocs chiffrés sous une même clé avant que les collisions deviennent probables. Chaque bloc porte huit octets, donc la même échelle représente environ 2^35 octets, soit 32 GiB de données sous une seule clé.

Considérez cela comme une échelle, pas comme un quota. Les collisions sont probabilistes, et qu'une collision divulgue quelque chose dépend du mode, du profil de trafic et de la capacité de l'attaquant à reconnaître ou à influencer le texte clair environnant. Le premier octet au-delà de 32 GiB n'est pas un événement de déchiffrement, et les premiers 32 GiB ne sont pas certifiés sûrs.

Les chercheurs de Sweet32 ont démontré en 2016 des attaques pratiques contre les chiffrements à blocs de 64 bits, dont un scénario OpenVPN, dans des conditions exigeant l'observation et la génération de trafic. Leurs valeurs par défaut et versions logicielles publiées relèvent du contexte historique, pas d'une description de votre déploiement.

Déterminez si la réutilisation de CBC compte ici

En CBC, un bloc de texte chiffré répété signifie que les deux blocs de texte clair diffèrent selon une relation connue, car le XOR de chaînage s'annule. Un attaquant capable d'observer le texte chiffré et qui connaît ou peut influencer l'un des textes clairs peut récupérer des informations sur l'autre. La clé Blowfish n'est jamais nécessaire pour cela.

Les questions pertinentes sont donc la durée de service d'une clé, le volume de trafic qui passe sous elle et la possibilité pour quelqu'un d'observer et d'orienter ce trafic. Le renouvellement de clé réduit le nombre de blocs par clé, mais un intervalle de temps n'est pas une limite en octets : un tunnel actif peut transporter bien plus de données qu'un tunnel inactif dans la même heure. Si vous conservez un chiffrement hérité, déduisez la limite de la construction et du volume réel, pas d'un chiffre rond.

Si le volume mesuré par clé reste bien en dessous de l'échelle d'anniversaire, l'exposition est plus faible. Elle n'est toujours pas nulle et reste une raison de planifier une migration plutôt que de cesser de s'inquiéter.

Remplacez le chiffrement, pas la clé

Migrez le service vers un chiffrement AEAD pris en charge et confirmez que les deux pairs, leurs versions et leurs backends cryptographiques peuvent le négocier. Allonger la clé Blowfish ne change rien qui compte, et deviner une nouvelle directive sur un client est la façon dont un tunnel fonctionnel devient cassé. Testez le changement sur un client et un serveur avant de toucher au reste du parc. Gardez l'ancien profil disponible pour un retour arrière jusqu'à ce que le nouveau chiffrement ait passé un cycle de connexion complet.

Maintenez la vérification des certificats et l'authentification des comptes pendant le changement. Elles répondent à des questions différentes : une connexion réussie ne peut pas élargir un bloc, et un meilleur chiffrement de données ne dispense pas de faire confiance au bon serveur.

Terminez la vérification en relisant le chiffrement négocié sur une nouvelle connexion, puis confirmez que l'ancien chiffrement n'est plus accepté. Si un pair le propose encore, la migration n'est pas terminée, quoi que dise le profil de l'autre côté.