Bonjour, j'ai une petite question de compr=E9hension.
Si je chiffre un m=EAme message deux fois de suite avec une m=EAme cl=E9
(RSA) j'obtiens deux r=E9sultats diff=E9rents.
Pareil pour une signature d'un document.
J'en ai d=E9duis, peut-=EAtre abusivement, que c'=E9tait =E0 cause du paddi=
ng
qui =E9tait ajout=E9 quand le message en clair n'a pas la bonne taille par
rapport =E0 la cl=E9. 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=EAme message en clair et une m=EAme cl=E9, on devrait avoir le m=EAme
r=E9sultat, non ?
Pour chiffrer et d=E9chiffrer, j'utilise gnupg, mais aussi openssl et
CryptoServices (framework .NET)
Mon but c'est de faire du test unitaire, et du coup =E7a ne marche pas.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mehdi Tibouchi
"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.
"kermit l'assureur" wrote in message
<4995ad62-b571-473c-bea2-6fe5a7dda1c6@b30g2000yqd.googlegroups.com>:
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.
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
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
According to kermit l'assureur <assureur.kermit@gmail.com>:
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.
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
On 27 mar, 16:28, Thomas Pornin wrote:
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.
On 27 mar, 16:28, Thomas Pornin <por...@bolet.org> wrote:
According to kermit l'assureur <assureur.ker...@gmail.com>:
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.
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.
