4. Security Considerations
4. Considérations de sécurité
Le chiffrement ChaCha20 est conçu pour fournir une sécurité de 256 bits.
L'authentificateur Poly1305 est conçu pour garantir que les messages forgés sont rejetés avec une probabilité de 1-(n/(2^102)) pour un message de 16n octets, même après l'envoi de 2^64 messages légitimes ; il est donc SUF-CMA (strong unforgeability against chosen-message attacks, forte infalsifiabilité face aux attaques à messages choisis) selon la terminologie de [AE].
Prouver la sécurité de l'un ou l'autre dépasse le cadre de ce document. De telles preuves figurent dans les articles académiques cités ([ChaCha], [Poly1305], [LatinDances], [LatinDances2], et [Zhenqing2012]).
La considération de sécurité la plus importante pour la mise en œuvre de ce document est l'unicité du nonce utilisé dans ChaCha20. Les compteurs et les LFSR (linear feedback shift registers, registres à décalage à rétroaction linéaire) sont tous deux des moyens acceptables de générer des nonces uniques, de même que le chiffrement d'un compteur au moyen d'un chiffrement par blocs avec une taille de bloc de 64 bits tel que DES. Il n'est pas acceptable d'utiliser une troncature d'un compteur chiffré avec des chiffrements par blocs à blocs de 128 ou 256 bits, car une telle troncature peut se répéter après peu de temps.
Conséquences de la répétition d'un nonce : si un nonce est répété, la clé Poly1305 à usage unique et le flux de clés sont identiques entre les messages. Cela révèle le XOR des textes clairs, car le XOR des textes clairs est égal au XOR des textes chiffrés.
La clé Poly1305 DOIT être imprévisible pour un attaquant. Une génération aléatoire de la clé satisferait cette exigence, sauf que Poly1305 est souvent utilisé dans des protocoles de communication, de sorte que le récepteur doit connaître la clé. Une génération de nombres pseudo-aléatoires, par exemple en chiffrant un compteur, est acceptable. L'utilisation de ChaCha avec une clé secrète et un nonce est également acceptable.
Les algorithmes présentés ici ont été conçus pour être faciles à implémenter en temps constant afin d'éviter les vulnérabilités par canaux auxiliaires. Les opérations utilisées dans ChaCha20 sont toutes des additions, des XOR et des rotations fixes. Toutes peuvent et devraient être implémentées en temps constant. L'accès aux décalages dans l'état ChaCha et le nombre d'opérations ne dépendent d'aucune propriété de la clé, ce qui élimine le risque de fuite d'informations sur la clé via le timing des défauts de cache.
Pour Poly1305, les opérations sont l'addition, la multiplication et le modulo, sur des nombres de plus de 128 bits. Cela peut être fait en temps constant, mais une implémentation naïve (par exemple avec une bibliothèque multiprécision générique) ne sera pas à temps constant. Par exemple, si la multiplication est effectuée séparément du modulo, le résultat sera parfois inférieur à 2^256 et parfois supérieur à 2^256. Les implémentateurs doivent veiller aux canaux auxiliaires de timing pour Poly1305 en utilisant une implémentation appropriée de ces opérations.
Valider l'authenticité d'un message implique une comparaison bit à bit de l'étiquette calculée avec l'étiquette reçue. Dans la plupart des cas d'usage, les nonces et le contenu AAD (associated authenticated data, données authentifiées associées) ne sont pas « consommés » tant qu'un message valide n'est pas reçu. Cela permet à un attaquant d'envoyer plusieurs messages identiques avec des étiquettes différentes jusqu'à ce qu'une passe la comparaison d'étiquette. C'est difficile si l'attaquant doit essayer les 2^128 étiquettes possibles une par une. Toutefois, si le timing de la comparaison d'étiquette révèle la longueur d'un préfixe commun entre l'étiquette calculée et l'étiquette reçue, le nombre de messages peut être réduit de façon significative. Pour cette raison, avec les protocoles en ligne, l'implémentation DOIT utiliser une fonction de comparaison à temps constant plutôt que de s'appuyer sur des fonctions de bibliothèque optimisées mais non sûres telles que memcmp() du langage C.
De plus, tout protocole utilisant cet algorithme DOIT inclure l'étiquette complète afin de minimiser les possibilités de forge. La troncature d'étiquette NE DOIT PAS être pratiquée.