aléa dans RSA ?

Le
kermit l'assureur
Bonjour, j'ai une petite question de compréhension.

Si je chiffre un même message deux fois de suite avec une même clé
(RSA) j'obtiens deux résultats différents.
Pareil pour une signature d'un document.
J'en ai déduis, peut-être abusivement, que c'était à cause du paddi=
ng
qui était ajouté quand le message en clair n'a pas la bonne taille par
rapport à la clé. Mais en essayant avec de nombreuses tailles de
messages, j'ai toujours ce comportement.
Est-ce qu'il y a un truc que je n'ai pas compris ? Normalement si on a
un même message en clair et une même clé, on devrait avoir le même
résultat, non ?

Pour chiffrer et déchiffrer, j'utilise gnupg, mais aussi openssl et
CryptoServices (framework .NET)
Mon but c'est de faire du test unitaire, et du coup ça ne marche pas.

Merci pour ton aide, ami lecteur.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mehdi Tibouchi
Le #21444411
"kermit l'assureur" wrote in message

Normalement si on a un même message en clair et une même clé, on
devrait avoir le même résultat, non ?



Non, un algorithme de chiffrement déterministe n'est jamais
sémantiquement sûr, ce qu'on considère comme une très mauvaise chose.
L'aléa joue un rôle essentiel (observation historique de Goldwasser et
Micali au début des années 80). Si je chiffre mon bulletin de vote, je
n'ai pas envie que quelqu'un puisse vérifier si j'ai voté Trucmuche en
chiffrant le bulletin Trucmuche dans son coin et en comparant les
chiffrés.

Bien entendu, ça dépend ensuite de ce qu'on appelle « chiffrer avec une
clef RSA ». RSA, c'est plus une fonction à sens unique qu'un algorithme
de chiffrement en tant que tel. Si on l'utilise telle quelle pour
chiffrer, on obtient quelque chose qui ne vérifie pas la plupart des
notions de sécurité qu'on associe à un système de chiffrement; les
logiciels le permettent souvent (par exemple openssl rsautl -raw), mais
c'est une très mauvaise idée.

Mon but c'est de faire du test unitaire, et du coup ça ne marche pas.



Pour tester qu'un chiffrement est correct, la bonne méthode consiste à
déchiffrer et à vérifier que ce qu'on obtient coïncide avec le clair
prévu.
Thomas Pornin
Le #21448671
According to kermit l'assureur
Est-ce qu'il y a un truc que je n'ai pas compris ? Normalement si on a
un même message en clair et une même clé, on devrait avoir le même
résultat, non ?



On n'a vraiment pas envie d'avoir cette propriété, en fait. RSA est un
chiffrement à clé publique, ce qui veut dire que tout le monde peut
chiffrer (la clé de chiffrement est publique, justement). Si le
chiffrement est déterministe alors ça ouvre la voie à une attaque par
recherche exhaustive, non pas sur la clé mais sur le texte chiffré :
un attaquant pourrait essayer de deviner le message, et vérifier,
simplement en le chiffrant, s'il a deviné juste.

L'exemple extrême, c'est si le message chiffré est soit "oui", soit
"non". Si le chiffrement est déterministe, alors il n'y a que deux
messages chiffrés possibles. L'attaquant n'a qu'à chiffrer lui aussi
"oui" et "non" pour voir duquel des deux il s'agit...

Donc on _veut_ qu'il y ait de l'aléa injecté dans le processus. Or,
justement, on doit avoir un peu de "padding" puisque le message est une
suite d'octets, et que RSA veut un grand nombre. Il y a une
transformation quelque part, donc une occasion de faire rentrer cet
aléa. Dans PKCS#1 (le principal standard sur RSA), le padding "ancienne
version" (dit "v1.5") indique que cet aléa doit faire au moins 8 octets
(non nuls). Dans le padding "nouvelle version" (dit "OAEP"), la
transformation est un peu plus complexe (ça aide pour faire des preuves
de sécurité) mais le principe demeure.

En bref, en chiffrement, on obtient un message chiffré différent à chaque
fois et c'est à la fois normal et souhaité.


En signature, on n'a pas forcément besoin d'aléa. Ça peut aider pour
faire des preuves de sécurité, et le padding de signatures "nouvelle
version" de PKCS#1 (dit "PSS") injecte de l'aléa. Le padding "ancienne
version" (v1.5) pour signatures, lui, n'injecte pas d'aléa, et avec
celui-là le calcul d'une signature est déterministe.


Mon but c'est de faire du test unitaire, et du coup ça ne marche pas.



On peut le faire de plusieurs manières :

1. On peut déchiffrer des messages chiffrés donnés. L'aléa est injecté
lors du chiffrement, mais le déchiffrement, lui, est déterministe. Donc
on essaye de déchiffrer des messages fixés, et on compare le résultat
avec le message chiffré attendu.

2. Une fois que le déchiffrement fonctionne (il est testé à l'étape
d'avant), on s'en sert pour tester le chiffrement. On chiffre des
messages aléatoires, chaque chiffrement injecte une dose d'aléa, et on
utilise le code de déchiffrement pour voir si on a bien chiffré.

3. Éventuellement, on paramétrise l'aléa. Autrement dit, on prévoit un
paramètre supplémentaire dans la fonction de chiffrement, paramètre qui
est l'ensemble des octets aléatoires à utiliser. Ça permet de rendre à
nouveau le processus déterministe, dans le cadre d'un test.

En signature, pareil : on commence par tester la vérification (avec
des signatures "correctes" précalculées) puis on se sert du code de
vérification pour tester le code de génération de signatures.


--Thomas Pornin
kermit l'assureur
Le #21453191
On 27 mar, 16:28, Thomas Pornin
According to kermit l'assureur

On n'a vraiment pas envie d'avoir cette propriété, en fait. RSA est u n
chiffrement à clé publique, ce qui veut dire que tout le monde peut
chiffrer (la clé de chiffrement est publique, justement). Si le
chiffrement est déterministe alors ça ouvre la voie à une attaque p ar
recherche exhaustive, non pas sur la clé mais sur le texte chiffré :
un attaquant pourrait essayer de deviner le message, et vérifier,
simplement en le chiffrant, s'il a deviné juste.




Merci à vous deux pour ces explications et pour les conseils, je
comprend mieux.
Publicité
Poster une réponse
Anonyme