AES-256 ou OFB : choisir une construction de chiffrement VPN complète

AES-256 et OFB répondent à des questions différentes, et c’est ici que les revues de chiffrement se trompent quand elles les traitent comme des options concurrentes. L’un nomme un chiffrement par blocs avec une taille de clé ; l’autre décrit comment un chiffrement par blocs devient un flux pour un message plus long. Un guide de choix de protection doit regarder la construction entière, y compris la façon dont le récepteur détecte un paquet modifié.

Nommez les quatre parties de la construction

Chaque revue se ramène à quatre questions : quelle primitive et quelle taille de clé, comment les messages sont traités avec elle, comment le récepteur rejette une modification non autorisée et comment le protocole gère les entrées, les clés et leur durée de vie. Une liste de noms familiers ne répond qu’à la première. La deuxième et la troisième sont là où vivent les vraies différences, et la quatrième là où les implémentations divergent en silence. Posez-les dans cet ordre et écrivez les réponses.

OFB figure parmi les modes de confidentialité dans la publication du NIST sur les modes de chiffrement par blocs, et la confidentialité est tout ce qu’il offre. Un protocole qui associe un mode de chiffrement à un MAC séparé doit les composer correctement, et le nom d’un algorithme ne prouve pas cette composition. C’est pourquoi le nom du mode seul ne peut pas trancher une décision de déploiement.

La quatrième question est celle qu’un exploitant peut réellement vérifier sur le système en marche.

Préférez une construction authentifiée

Le chiffrement authentifié apporte confidentialité et intégrité ensemble, et les constructions AEAD protègent aussi les données associées contre les modifications sans les chiffrer. C’est une propriété de la protection des paquets, sans rapport avec le fait qu’une personne se soit connectée avec succès.

Le Guide Netgate des réglages cryptographiques d’OpenVPN pointe vers des options AEAD, dont AES-GCM, pour le canal de données, et c’est le type de politique prise en charge qu’il faut suivre. Utilisez les choix que la version installée et les clients pairs prennent en charge, au lieu de copier un classement historique des modes dans un nouveau déploiement. La compatibilité héritée, les backends cryptographiques et la prise en charge de l’offload limitent ce qui est réellement disponible.

Une construction prise en charge bat une composition astucieuse à chaque fois.

Lisez le résultat négocié, pas l’offre

Un chiffrement qui figure dans une liste acceptée ne dit rien de la session en cours. Lisez la protection négociée du canal de données chez le client ou sur la passerelle, puis comparez-la à la politique que vous vouliez appliquer. Une configuration qui liste encore une option héritée pour un pair ancien est une décision de compatibilité, pas une affirmation sur la session devant vous.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Sur une passerelle, la sortie équivalente est l’association de sécurité ou le détail cryptographique de la connexion, selon la plateforme. Dans les deux cas, l’offre et le résultat sont des faits différents. Une liste qui inclut une option héritée pour un pair ancien ne signifie pas que chaque session l’utilise, et la session qui l’utilise est ce que vous aviez besoin de savoir.

Consignez les deux faits ensemble, avec la date et la version du client.

Ne mesurez que ce qui est comparable

Le débit dépend du matériel des extrémités, de l’implémentation, de l’accélération, des tailles de paquets et de la configuration choisie. Ni la longueur de clé ni le mot OFB ne vous disent quel déploiement sera plus rapide. C’est pourquoi un banc d’essai venu d’un autre site est au mieux un indice sur le matériel que possède quelqu’un d’autre. Vos propres chiffres commencent par vos propres extrémités.

Pour une comparaison autorisée, gardez constantes les extrémités, la charge de travail et la politique requise, et consignez la protection négociée ainsi que les versions d’implémentation. Jugez ensuite le résultat selon que l’application a terminé, combien elle a perdu et ce que faisaient les extrémités, au lieu de déduire un coût cryptographique d’un seul test de vitesse. Un chiffre produit dans d’autres conditions est une histoire, pas une mesure.

Si un pair ancien ne peut pas respecter la politique, c’est une décision de compatibilité pour son propriétaire.

Gardez l’intégrité hors du compromis

Désactiver les contrôles d’intégrité ou accepter un serveur non vérifié n’est pas une optimisation de performance et n’est pas un correctif de compatibilité. Cela change la propriété de sécurité pour laquelle la construction a été choisie. Il en va de même pour l’élargissement de la liste de chiffrements acceptés jusqu’à ce qu’un pair ancien se connecte : la connexion réussit et la politique n’existe plus.

Écrivez la construction acceptée et son propriétaire dans le guide, afin que le prochain changement parte d’une décision plutôt que d’une préférence.

Ce que vous voulez, c’est une politique que les deux extrémités peuvent appliquer. Affirmer qu’un nom est le plus fort est une autre conversation, et elle se termine généralement sans décision.