qui divise le module).

Si vous utilisez un petit exposant et vous n'utilisez aucun remplissage pour le chiffrement 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 des clés publiques n₁ , n₂ et n₃ , alors vous avez c _i = m ³ mod n_i pour i = 1 à 3 . Par le théorème du reste chinois, vous pouvez ensuite reconstruire m³ mod n ₁ n ₂ n ₃ , qui s'avère être m³ (sans aucun modulo) car n ₁n₂n₃ est un entier supérieur. Une extraction de racine cubique (non modulaire) suffit alors pour extraire m.

La faiblesse, ici, n'est pas le petit exposant; il s'agit plutôt de l'utilisation d'un rembourrage inapproprié (à savoir, aucun remplissage) pour le chiffrement. Le remplissage est très important pour la sécurité de RSA, que ce soit le cryptage ou la signature; si vous n'utilisez pas un rembourrage approprié (comme ceux décrits dans PKCS # 1), alors 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 se réfère à 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 une tradition ancienne et incorrecte, qui est parfois inversée en une interdiction contre les grands exposants (puisque c'est un mythe, le mythe inversé est aussi un mythe et n'est ni plus ni 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).

• Le fait d'avoir un petit exposant privé pose des problèmes de sécurité ; une attaque de 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 s'étouffent sur les grands exposants publics RSA. Par exemple. le code RSA sous Windows (CryptoAPI, utilisé par Internet Explorer pour HTTPS) insiste sur l'encodage de l'exposant public dans un seul mot de 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 le façon habituelle de dire "nous ne l'avons pas implémenté mais nous ne voulons admettre aucune sorte de 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 expliquait 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 inapproprié. Ces attaques sont évitées par une utilisation appropriée du rembourrage. Toute bibliothèque de crypto digne de ce nom 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 une bibliothèque de crypto d'interdire 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 ne présente aucun problème de sécurité connu. (En fait, e = 2 est encore un peu mieux. Il est également connu sous le nom de cryptage Rabin. Cependant, ce schéma n'est pas aussi connu et nécessite un code légèrement différent, il n'est donc pas largement utilisé.)

Ces cinq nombres sont des nombres premiers de Fermat.

Comme ils sont de la forme 2 ^k + 1, chiffrement est m^e = m · (( m ^{2 sup>) 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.}

Comme ce sont des nombres premiers, le test que e est coprime à ( p - 1) ( q - 1) est juste un test qui e ne le divise pas.

C'est donc plus probable sur la vitesse ou la convention que sur la sécurité. Non pas qu'il n'y ait rien de mal à être efficace. Mais pour être sûr, demandez une référence comme l ' autre réponse suggérée.

Voir également ce message.

Je ne connais aucune raison pour laquelle l'exposant public d'une clé RSA doit être uniquement dans l'ensemble {3,5,17,257,65537}. Comme vous l'avez mentionné, les petits exposants tels que 3 ou 5 sont plus risqués à utiliser, car les effets négatifs des erreurs d'implémentation (comme un remplissage incorrect) peuvent être plus importants. NIST n'autorise que les exposants publics supérieurs à 2 ^ 16, mais je ne connais pas la raison de 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 demandez pour une référence concrète. Trop souvent, il s'avère que certains papiers ont été mal compris. Je pourrais par exemple imaginer qu'un développeur lise la section 4 de l'article «Pouvons-nous faire confiance aux logiciels cryptographiques? Failles cryptographiques dans GNU Privacy Guard v1.2.3» de Phong Nguyen et parvient à une conclusion incorrecte, comme celle ci-dessus. Cet article remarque que lorsque la clé publique générée par GnuPG s'avère être une valeur inhabituelle telle que 65539, l'attaquant apprend alors un peu d'informations sur la clé secrète.La conclusion est que l'algorithme de génération de clé de GnuPG pourrait être amélioré, mais pas que 65539 est une mauvaise clé publique.

Je n'ai trouvé aucune référence indiquant que les autres valeurs de l'exposant public sont vulnérables. L'utilisation difficile d'un exposant public proche d'une puissance de 2 est recommandée pour des raisons de performances, selon le guide RSA.com de l'algorithme RSA

D'après Wikipedia, NIST n'autorise pas un exposant public inférieur à 65537, car les exposants plus petits posent problème s'ils ne sont pas correctement remplis.

Pour citer l'article de Don Coppersmith de 1997 "Petites solutions aux équations polynomiales et vulnérabilités RSA à faible exposant":

Le chiffrement RSA avec l'exposant 3 est vulnérable si l'adversaire connaît les deux tiers du message .

Bien que cela ne pose pas de problème si le schéma de remplissage RSA-OAEP est utilisé, le schéma de remplissage PKCS # 1 (qui est donné comme schéma de remplissage approprié dans les réponses ci-dessous) est vulnérable si l'exposant public 3 est utilisé.