L'exposant public RSA doit-il être uniquement dans {3, 5, 17, 257 ou 65537} pour des raisons de sécurité?
Dans mon projet, j'utilise la valeur d'exposant public de 4451h. Je pensais que c'était sûr et correct jusqu'à ce que je commence à utiliser une bibliothèque de chiffrement RSA commerciale. Si j'utilise cet exposant avec cette bibliothèque, il lève une exception.
J'ai contacté les développeurs de cette bibliothèque et j'ai obtenu la réponse suivante: "Cette fonctionnalité permet d'éviter certaines attaques sur les clés RSA. La conséquence est que la valeur de l'exposant est limitée à {3, 5, 17, 257 ou 65537}. La désactivation de cette vérification est toujours à l’étude, car les risques peuvent être importants. "
C'est la première fois de ma vie que j'entends que des valeurs autres que {3, 5, 17, 257 ou 65537} sont utilisées pour rompre le RSA. Je savais seulement utiliser 3 avec un rembourrage incorrect étant vulnérable.
En est-il vraiment ainsi? Je peux sûrement utiliser une autre bibliothèque, mais après une telle réponse, je m'inquiétais de la sécurité de ma solution.
Il n'y a pas de faiblesse connue pour un exposant public court ou long pour RSA, tant que l'exposant public est "correct" (c'est-à-dire relativement premier à p-1 pour tous les nombres premiers p qui divisent le module).
Si vous utilisez un petit exposant et vous n'utilisez pas de remplissage pour le cryptage et vous cryptez exactement le même message avec plusieurs clés publiques distinctes, alors votre message est en danger: si e = 3, et vous cryptez le message m avec les clés publiques n1, n2 et n3, alors vous avez cje = m3 mod nje pour i = 1 à 3. Par le théorème des restes chinois , vous pouvez alors reconstruire m3 mod n1n2n3, qui se révèle être m3 (sans aucun module) car n1n2n3 est un entier plus grand. Une extraction de racine de cube (non modulaire) suffit alors pour extraire m.
La faiblesse, ici, n'est pas pas le petit exposant; c'est plutôt l'utilisation d'un remplissage incorrect (à savoir, pas de remplissage du tout) pour le chiffrement. Le remplissage est très important pour la sécurité de RSA, qu'il s'agisse de chiffrement ou de signature; si vous n'utilisez pas un rembourrage approprié (comme ceux décrits dans PKCS # 1 ), vous avez de nombreuses faiblesses, et celle décrite dans le paragraphe ci-dessus n'est pas de loin la plus importante. Néanmoins, chaque fois que quelqu'un fait référence à une faiblesse liée à la taille de l'exposant, il se réfère plus ou moins directement à cet événement. C'est un peu de tradition ancienne et incorrecte, qui est parfois inversée en une interdiction contre gros exposants (car c'est un mythe, le mythe inverse est aussi un mythe et n'est plus - et non moins - justifié); Je crois que c'est ce que vous observez ici.
Cependant, on peut trouver quelques raisons pour lesquelles un grand exposant public doit être évité:
Les petits exposants publics favorisent l'efficacité (pour les opérations à clé publique).
Il y a des problèmes de sécurité avec un petit exposant privé; une attaque par récupération de clé a été décrite lorsque la longueur de l'exposant privé ne dépasse pas 29% de la longueur de l'exposant public. Lorsque vous voulez forcer l'exposant privé à être court (par exemple pour accélérer les opérations de clé privée), vous devez plus ou moins utiliser un grand exposant public (aussi grand que le module); exiger que l'exposant public soit court peut alors être considéré comme une sorte de contre-mesure indirecte.
Certaines implémentations RSA largement déployées étouffent les grands exposants publics RSA. Par exemple. le code RSA dans Windows (CryptoAPI, utilisé par Internet Explorer pour HTTPS) insiste sur le codage de l'exposant public dans un seul mot 32 bits; il ne peut pas traiter une clé publique avec un exposant public plus grand.
Pourtant, "les risques peuvent être grands" ressemble à la justification générique ("c'est un problème de sécurité" est la façon habituelle de dire "nous ne l'avons pas mis en œuvre mais nous ne voulons admettre aucune paresse").
Les développeurs sont tout simplement incorrects. Il n'y a rien de mal avec l'exposant 0x4451 (décimal 17489); cela ne crée aucun problème de sécurité.
Il y a longtemps, les gens pensaient que les petits exposants étaient un problème, à cause d'une attaque que Thomas Pornin a expliqué en envoyant le même message à plusieurs destinataires. Mais aujourd'hui, nous comprenons que les exposants n'avaient rien à voir avec cela; le problème était un rembourrage incorrect. Ces attaques sont empêchées par une utilisation appropriée du rembourrage. Toute bibliothèque de crypto qui vaut son sel ferait bien mieux d'utiliser un rembourrage approprié (sinon vous avez des problèmes bien pires).
Il n'y a donc aucune bonne raison pour qu'une bibliothèque de chiffrement interdise catégoriquement l'utilisation de cet exposant.
Cela dit, du point de vue des performances, plus l'exposant est petit, meilleures sont les performances. Le meilleur choix est e = 3, car cela donne les meilleures performances et n'a aucun problème de sécurité connu. (En fait, e = 2 est encore un peu meilleur. Il est également connu sous le nom de chiffrement Rabin. Cependant, ce schéma n'est pas aussi bien connu et nécessite un code légèrement différent, il n'est donc pas largement utilisé.)
Ces cinq nombres sont nombres premiers de Fermat .
Puisqu'ils sont de la forme 2 k + 1, le cryptage est m e = m · (( m2)2... k fois...)2, qui est plus simple et plus rapide que l'exponentiation avec un exposant de taille similaire dans le cas général .
Puisqu'ils sont des nombres premiers, le test qui e est coprime à ( p - 1) ( q - 1) est juste un test qui e ne le divise pas.
Il s'agit donc plus de vitesse ou de convention que de sécurité. Pas qu'il n'y ait rien de mal à être efficace. Mais pour être sûr, demandez une référence comme autre réponse suggérée.
Voir aussi ce post .
Je ne connais aucune raison pour laquelle l'exposant public d'une clé RSA ne devrait être que dans l'ensemble {3,5,17,257,65537}. Comme vous le mentionnez, les petits exposants tels que 3 ou 5 sont plus risqués à utiliser, car les effets négatifs des erreurs d'implémentation (tels qu'un remplissage incorrect) peuvent être plus importants. Le NIST n'autorise que les exposants publics supérieurs à 2 ^ 16, mais je ne connais pas de raison pour leur décision.
Vous ne devriez pas être satisfait de la réponse donnée par les développeurs de la bibliothèque que vous utilisez et demander une référence concrète. Trop souvent, il s'avère que certains papiers ont été mal compris. Je pourrais par exemple imaginer que certains développeurs lisent la section 4 du document "Pouvons-nous faire confiance au logiciel cryptographique? Failles cryptographiques dans GNU Privacy Guard v1.2.3" de Phong Nguyen et arrive à une conclusion incorrecte, tel que celui ci-dessus. Ce document note que lorsque la clé publique générée par GnuPG se révèle être une valeur inhabituelle telle que 65539, l'attaquant apprend un peu d'informations sur la clé secrète. La conclusion est que l'algorithme de génération de clé GnuPG pourrait être amélioré, mais pas que 65539 est une mauvaise clé publique.
Je n'ai trouvé aucune référence indiquant que d'autres valeurs pour l'exposant public sont vulnérables. Il est conseillé d'utiliser un exposant public proche d'une puissance de 2 pour des raisons de performances, selon le Guide RSA.com de l'algorithme RSA
Selon Wikipedia , le NIST ne permet pas un exposant public inférieur à 65537, car les exposants plus petits sont un problème s'ils ne sont pas correctement remplis.