Quatre millions d’échanges de clés par seconde — Adrien Guinet, Carlos Aguilar, Serge Guelton, Tancrède Lepoint
Date : 04 June 2015 à 10:00 — 30 min.
Cet article présente une bibliothèque cryptographique : NFLlib. Nous décrivons les performances qu’elle permet d’atteindre au niveau des échanges de clés, ainsi que les optimisations qui ont mené à ces résultats. La cryptographie à clé publique est réputée pour le surcoût important engendré tant au niveau de l’implémentation (calculs sur les grands nombres, manipulation de points dans une courbe elliptique, etc.) qu’au niveau calculatoire. Un des principaux usages de la cryptographie à clé publique est l’échange de clés lors de la mise en place d’une communica- tion sécurisée (par exemple pour une connexion TLS). Cette opération, gourmande en temps de calcul, permet au mieux (en utilisant ECDH avec un Core i7-4770) de gérer de l’ordre de vingt mille connexions entrantes par seconde à 128 bits de sécurité ou six mille connexions à 256 bits de sécurité. La cryptographie basée sur les réseaux est entrée en scène en force depuis quelques années, en particulier grâce aux fonctionnalités avancées, de type chiffrement complètement homomorphe, qu’elle permet d’atteindre. Notre bibliothèque, NFLlib, permet d’implémenter simplement des algo- rithmes cryptographiques basés sur les réseaux euclidiens, le tout avec des performances supérieures à l’état de l’art connu. Pour illustrer cela, nous implémentons, en une dizaine de lignes de code, un système de chiffrement standard avec une estimation conservatrice du niveau de sécurité. Cette implémentation permet de gérer quatre millions d’échanges de clés de type TLS par seconde à 128 bits de sécurité et deux millions à 256 bits de sécurité. Si nous partons sur un proxy web utilisé pour du partage de charge et pouvant gérer les connexions TLS, il est possible de traiter jusqu’à 70 000 requêtes par seconde sur un unique serveur (voir [?]). L’utilisation de ECDH demandera trois Core i7-4770 à 100% rien que pour les échanges de clés, alors que notre bibliothèque permet d’utiliser uniquement 2% d’un unique CPU libérant ainsi les processeurs pour traiter les requêtes.