Chiffrement symétrique: questions de performance

Question

Les performances d'un algorithme de chiffrement symétrique dépendent-elles de la quantité de données chiffrées? Supposons que j'ai environ 1000 octets que j'ai besoin d'envoyer rapidement sur le réseau, est-il préférable de crypter 50 octets de données 20 fois, ou 1000 octets à la fois? Qui sera le plus rapide? Cela dépend-il de l'algorithme utilisé? Si tel est le cas, quel est l'algorithme le plus performant et le plus sécurisé pour les quantités de données inférieures à 512 octets?

Answer 1

Les réponses courtes sont:

• Vous voulez crypter toutes vos données en une seule fois. Vous voulez réellement leur donner tous dans un appel de fonction au code de cryptage, de sorte qu'il puisse courir encore plus vite.

• Avec un algorithme de chiffrement approprié, le chiffrement sera sensiblement plus rapide que le réseau lui-même. Il faut une très mauvaise implémentation, un très vieux PC ou un réseau très rapide pour faire du chiffrement un goulot d'étranglement. En cas de doute, utilisez un protocole entièrement réalisé tel que SSL/TLS.Si vous avez le choix de l'algorithme de cryptage dans un protocole, utilisez AES.

Maintenant, les réponses plus:

Il y a chiffrements par bloc et chiffrement flux. Un chiffrement de flux commence par une phase d'initialisation, dans laquelle la clé est entrée dans le système (souvent appelée «programme clé»), puis crypte les octets de données «à la volée». Avec un chiffrement de flux, le message chiffré a la même longueur que le message d'entrée, et le temps de chiffrement est proportionnel à la longueur du message d'entrée, sauf pour le coût de calcul de la planification de clé. Nous ne parlons pas de grands nombres ici; Le temps de programmation des touches est inférieur à 1 microseconde sur un PC pas si récent. Pourtant, pour des performances optimales, vous voulez faire le programme principal une fois, pas 50 fois.

Les chiffrements par bloc ont également un programme clé. Lorsque la planification de clé a été effectuée, un chiffrement de bloc peut chiffrer des blocs, c'est-à-dire des blocs de données d'une longueur fixe. La longueur du bloc dépend de l'algorithme, mais elle est généralement de 8 ou 16 octets. AES est un chiffrement par bloc. Afin de crypter un "message" de longueur arbitraire, le chiffrement de bloc doit être invoqué plusieurs fois, et c'est plus compliqué qu'il n'y paraît (il y a beaucoup de problèmes de sécurité). La partie qui décide comment ces invocations sont assemblées est appelée le mode de chaînage. Un mode de chaînage bien connu s'appelle CBC. En fonction du mode de chaînage, il peut être nécessaire d'ajouter une étape supplémentaire appelée padding dans laquelle quelques octets supplémentaires sont ajoutés au message d'entrée, de sorte que sa longueur devienne compatible avec le chaînage choisi. Le rembourrage doit être tel que, lors du décryptage, il puisse être enlevé sans ambiguïté. Un schéma de remplissage commun est appelé "PKCS # 5".

Il existe un mode de chaînage appelé "CTR" qui transforme efficacement un chiffrement par blocs en un chiffrement de flux. Il a quelques bons points; en particulier, le mode CTR ne nécessite pas de remplissage, et la longueur du message crypté aura la même longueur que le message d'entrée. AES avec le mode CTR est bon. La vitesse de cryptage sera d'environ 100 Mo/s sur un PC type (par exemple un processeur Intel Core2 de 2,4 GHz utilisant un seul cœur).

Attention: il y a des problèmes en ce qui concerne le cryptage plusieurs messages avec la même clé. Avec les modes de chaînage, ces problèmes se cachent sous le nom de "IV" (comme "valeur initiale"). Avec la plupart des modes de chaînage, l'IV est une valeur aléatoire de la même taille que le bloc de chiffrement. L'IV n'a pas besoin d'être secrète (elle est souvent transmise avec le message crypté, car la partie déchiffreuse doit aussi le savoir) mais elle doit être choisie de manière aléatoire et uniforme, et chaque message a besoin d'une nouvelle IV. Certains modes de chaînage (par exemple CTR) peuvent tolérer une IV non uniforme mais seulement pour le premier message avec une clé donnée. Avec CBC même le premier message a besoin d'un IV entièrement aléatoire. Si ce paragraphe n'a pas de sens pour vous, s'il vous plaît, n'essayez pas de concevoir un protocole de chiffrement, il est plus complexe que vous ne l'imaginez. Au lieu de cela, utilisez un protocole déjà spécifié, tel que SSL (pour un tunnel de cryptage) ou CMS (pour les messages cryptés). Le développement de tels protocoles a été une longue et pénible histoire d'attaques et de contre-mesures, avec beaucoup de grincements de dents. Ne pas reconstituer cette histoire ...

Avertissement 2: Si vous utilisez le cryptage, alors vous êtes préoccupé par la sécurité: il peut y avoir des entités adverses qui attaquent votre système. La plupart du temps, un simple cryptage ne les dissuadera pas complètement; par lui-même, le cryptage (correctement appliqué) ne détruit que les attaquants passifs, ceux qui observent les octets transmis mais ne les modifient pas. Un attaquant générique est également actif, c'est-à-dire qu'il supprime des octets de données, déplace et duplique d'autres, ou ajoute des octets supplémentaires de sa propre conception.Pour vaincre les pirates actifs, vous avez besoin de plus que du chiffrement, vous avez également besoin de contrôles d'intégrité. Là encore, des protocoles tels que SSL et CMS prennent déjà en charge les détails.

Answer 2

De toute évidence, les performances dépendent de la quantité de données car chaque partie des données doit être cryptée. Vous obtiendrez de bien meilleures informations en effectuant un test dans votre environnement spécifique (langage, plate-forme, implémentation de l'algorithme de cryptage) que personne ne pourrait fournir à l'improviste: je ne pense pas que cela prendra plus d'une demi-heure une mesure de performance de base. En ce qui concerne la sécurité, vous devriez vous contenter de Triple DES ou de AES.

Answer 3

Les algorithmes de chiffrement symétrique sont typiquement des chiffrements de bloc. Pour tout algorithme donné, la taille du bloc est fixe. Ensuite, vous choisissez parmi plusieurs méthodes différentes pour rendre les blocs suivants dépendants des blocs précédents (c'est-à-dire le chaînage de blocs de chiffrement) pour créer un chiffrement de flux. Mais le chiffrement de flux met systématiquement en cache les données entrantes et les soumet au chiffrement par blocs en blocs complets. Donc, en faisant 20 octets 20 fois, tout ce que vous faites est de battre votre logique de cache. Si vous n'utilisez pas le mode flux, les datagrammes plus petits que la taille de bloc native de votre chiffrement bénéficieront d'une protection nettement moindre que les blocs complets, car il y a moins de messages possibles pour un attaquant.

Answer 4

AES devrait être un bon choix.

De bonnes implémentations d'AES (par exemple celle incluse dans la bibliothèque openssl) nécessitent environ 10 à 20 cycles de processeur par octet pour crypter. Lorsque vous cryptez de petits messages, vous devez également tenir compte de l'heure de configuration de la clé. Par exemple, une implémentation typique de DES nécessite quelques milliers de cycles pour une configuration de clé. Par exemple, vous pouvez finir de chiffrer un petit message avec AES avant même de commencer à chiffrer avec d'autres chiffrements.

Les processeurs plus récents (par exemple, les processeurs basés à Westmere) ont un jeu d'instructions qui prend en charge AES, permettant de crypter à des vitesses de 1,5 à 4 cycles par octet. C'est presque impossible à battre par un autre chiffre.

Si possible, essayez de crypter des messages plus longs, plutôt que de les diviser en petits morceaux. La raison principale n'est pas la vitesse de cryptage, mais plutôt la sécurité. C'est-à-dire qu'un mode de cryptage sécurisé nécessite habituellement d'utiliser un vecteur d'initialisation et une authentification de message (MAC). Cela ajoutera environ 32 octets à chacune de vos parties chiffrées. C'est à dire. Si vous divisez votre message en petites parties, cette surcharge sera importante.