7. Security Considerations
7. Considérations de sécurité
Le niveau de sécurité (c'est-à-dire le nombre d'« opérations » nécessaires pour une attaque par force brute contre une primitive) de curve25519 est légèrement inférieur au niveau standard de 128 bits. Cela est acceptable parce que les niveaux de sécurité usuels sont surtout dictés par des primitives symétriques beaucoup plus simples pour lesquelles le niveau de sécurité se situe naturellement sur une puissance de deux. Pour les primitives asymétriques, imposer rigidement une puissance de deux exigerait des compromis sur d'autres aspects de la conception, que nous refusons. Qui plus est, comparer les niveaux de sécurité entre types de primitives peut induire en erreur dans des modèles de menace courants où plusieurs cibles peuvent être attaquées en parallèle [bruteforce].
Le niveau de sécurité d'environ 224 bits de curve448 est un compromis entre performance et prudence accrue. De grands ordinateurs quantiques, s'ils voyaient le jour, briseraient à la fois curve25519 et curve448, et des estimations raisonnables des capacités des ordinateurs classiques conduisent à considérer curve25519 comme parfaitement sûre. En revanche, certaines conceptions assouplissent les contraintes de performance et souhaitent se prémunir contre une avancée analytique partielle contre les courbes elliptiques ; curve448 est donc également proposée.
Les concepteurs de protocoles qui emploient Diffie-Hellman sur les courbes définies dans ce document ne doivent pas présupposer un « comportement contributif ». Plus précisément, le comportement contributif signifie que les clés privées des deux parties contribuent toutes deux à la clé partagée obtenue. Comme curve25519 et curve448 ont pour cofacteurs 8 et 4 respectivement, un point d'entrée d'ordre faible annihile toute contribution de la clé privée de l'autre partie. Cette situation peut être détectée en vérifiant si la sortie est entièrement nulle ; les implémentations PEUVENT le faire, comme indiqué à la section 6. Or un grand nombre d'implémentations existantes ne le font pas.
Les concepteurs qui utilisent ces courbes doivent savoir qu'à chaque clé publique correspondent plusieurs clés publiques calculables publiquement qui lui sont équivalentes, c'est-à-dire produisent les mêmes secrets partagés. Utiliser une clé publique comme identifiant et la connaissance d'un secret partagé comme preuve de possession (sans inclure les clés publiques dans la dérivation de clé) peut donc entraîner des vulnérabilités subtiles.
Les concepteurs doivent également savoir que les implémentations de ces courbes peuvent ne pas recourir à l'échelle de Montgomery décrite ici, mais à des bibliothèques génériques de courbes elliptiques. De telles implémentations peuvent rejeter les points situés sur la courbe tordue quadratique et rejeter les éléments de corps non minimaux. Bien que déconseillé, ce comportement reste interopérable avec l'échelle de Montgomery spécifiée ici, mais peut permettre de les distinguer trivialement. Par exemple, l'envoi d'une valeur non canonique ou d'un point sur la courbe tordue quadratique peut provoquer une erreur observable dans ces implémentations, alors qu'une implémentation conforme au présent texte aboutirait à une clé partagée valide.