Lors de la préparation de la méthodologie de calcul de l'indice de fiabilité HTTPS, nous avons fouillé dans de nombreuses publications thématiques et sommes tombés plus d'une fois sur une recommandation de prendre en charge des suites de chiffrement basées sur l'algorithme de chiffrement CHACHA20 sur un serveur Web afin de réduire la charge sur les clients mobiles. qui ne peut pas utiliser le matériel AES. Dans ce contexte, les processeurs Mediatek et les «anciens processeurs mobiles à petit budget» ont généralement été mentionnés.
CHACHA20 avec son fidèle compagnon POLY1305 maintient-il vraiment les clients mobiles au frais et vaut-il la peine de le supporter sur un serveur Web? Discutons-en!
CHACHA20 a été créé par le célèbre cryptographe Daniel Bernstein, que nous aimons en particulier pour son Curve25519, et pour ses efforts de plaidoyer pour que seuls les oldfags se souviennent de ce que _EXPORT_ représentait dans une suite de chiffrement. L'algorithme est bien étudié, fonctionne en mode AEAD, n'a aucune faiblesse ou vulnérabilité connue et est l'un des deux algorithmes de cryptage approuvés par l'IETF pour une utilisation dans TLS 1.3 (l'autre est immortel AES).
Sa force cryptographique théorique lorsqu'elle est utilisée en TLS est estimée différemment, dans l'intervalle entre AES-128 et AES-256 en mode GCM, ce qui est considéré comme suffisant par les normes d'aujourd'hui et dans un avenir prévisible. En même temps, il est notéque CHACHA20 est "plus rapide" que AES, c'est-à-dire "Consomme moins de ressources processeur pour fournir le même niveau de puissance cryptographique." Cette formulation ne sent pas seulement le télémarketing (avec tout le respect que je dois à son auteur), mais manque également un détail important: sur les processeurs sans support matériel AES.
Et nous revenons enfin aux «processeurs mobiles à petit budget» qui surchauffent sous AES, commencent à étrangler et demandent de l'azote liquide (sarcasme). Les fabricants de processeurs sont conscients du problème et l'ont résolu en ajoutant un jeu d'instructions approprié. Dans les processeurs compatibles x86, c'est AES-NI, dans d'autres - leurs noms (et leur propre ensemble). Et nous arrivons ici à la partie la plus intéressante: le support AES par les processeurs.
Intel a introduit le support d'AES-NI en 2010 dans les processeurs Westmere, et pas du tout: Atom, Celeron, Pentium et Core i3 sur lesquels il ne s'appuyait pas depuis longtemps. Vous pouvez être sûr du support AES-NI sans creuser dans les spécifications à partir de l'architecture Goldmont (Apollo Lake et Denverton), et c'est déjà 2016.
Pour AMD, ce sont les architectures Bulldozer (2011) et Jaguar (2013), avec ARM tout est plus compliqué: le support des instructions AES est fourni dans l'architecture ARMv8-A (2011, le premier appareil est 2013), mais la mise en œuvre réelle d'entre eux en silicium dépend du processeur du fabricant et personnellement je ne sifflerais pas avec autant de confiance sur les "processeurs mobiles à vieux budget", mais il vaut la peine de parler de "processeurs mobiles non phares" en général, incl. produit à ce jour.
En termes simples, il n'est pas si difficile de trouver un processeur sans prise en charge matérielle AES. Alors CHACHA20 est vraiment une excellente alternative à AES? Jetons un coup d'œil aux résultats de cette étude , par exemple . Sur les processeurs sans prise en charge AES, CHACHA20 est nettement en avance sur ses performances, souvent plusieurs fois. Malheureusement, on ne nous a pas montré les mesures de température, mais si nous parlons d'un processeur serveur, il est évident que la différence dans les ressources processeur consommées est significative.
La situation est inversée en ce qui concerne les processeurs compatibles AES. Cela ne vaut guère la peine de blâmer CHACHA20 pour cela, à qui personne n'a offert un ensemble d'instructions personnelles dans le processeur, et ce qui se passe lorsque les deux joueurs jouent selon les mêmes règles que celles que nous avons vues sur les anciens processeurs (rappelez-vous: AES fusionne).
Alors, c'est parti pour le support CHACHA20 sur les serveurs web? Pourquoi pas, ne serait-ce que pour la raison que tous les œufs ne sont pas mis dans le même panier, et si soudainement demain un trou est trouvé dans AES lui-même ou son implémentation dans une bibliothèque cryptographique particulière, nous pouvons l'éteindre "jusqu'à clarification" avec un léger mouvement de notre main, rester sur CHACHA20, et ne pas chercher frénétiquement quelque chose pour remplacer AES, mais comment il s'allume.
La question de la place de CHACHA20 dans
Rappelons-nous comment la suite de chiffrement est généralement négociée lors de l'établissement d'une connexion HTTPS: le client envoie au serveur la liste des suites de chiffrement qu'il prend en charge, dans l'ordre "à partir du bulldozer" et cet ordre ne peut être modifié que via les stratégies de groupe Windows et uniquement pour Navigateurs
La priorité des suites de chiffrement sur le serveur est généralement définie sur la base du principe de sécurité maximale disponible: les suites de chiffrement les plus puissantes sont répertoriées en premier, moins - la dernière. Un client moderne tombe sur une suite de chiffrement solide et l'accepte, un client "obsolète" saute plus bas dans la liste vers une suite de chiffrement moins puissante et l'accepte. Tout le monde est content, tout fonctionne, de chacun selon ses capacités, à chacun utilisant HTTPS.
Et ici une suite de chiffrement basée sur CHACHA20 s'inscrit dans cette image harmonieuse du monde, que nous ajoutons pour des raisons de réduire la charge sur les clients «faibles» du point de vue matériel, sans rien savoir s'ils sont simultanément «obsolètes» ou non (c'est-à-dire le produit phare de cette année d'une société chinoise de troisième rang, ou un enfant de milieu de gamme de cinq ans d'une marque de premier plan). Le client informe qu'il prend en charge TLS 1.3 et une suite complète de suites de chiffrement associées, à la fois AES et CHACHA20. Votre solution, administrateur, quelle suite de chiffrement acceptons-nous le client? Ici, je suis à peu près le même ... Je
résume ce qui précède à propos de l'algorithme de cryptage CHACHA20.
- L'algorithme est assez bon pour lui-même et convient à une utilisation dans TLS.
- Les suites de chiffrement basées sur celui-ci ne sont prises en charge que par des navigateurs assez modernes , il n'y a donc pas du tout besoin d'AES.
- Le gain de performances résultant de son utilisation peut être obtenu non seulement sur les "processeurs mobiles à vieux budget", mais également sur les ordinateurs de bureau et les serveurs. Sur les processeurs avec support matériel AES, la situation est inversée.
- Lors de l'établissement d'une connexion HTTPS, il n'y a aucun moyen de savoir si le processeur du client prend en charge AES dans le matériel. En conséquence, il n'y a aucun moyen de savoir quelle suite de chiffrement sera "plus rapide" dans chaque cas.