Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Criptologie RSA, déchiffrage par table.
39 views
Skip to first unread message
jujul3p
Jan 8, 2013, 5:42:00 AM1/8/13
to
Bonjour � tous,
Suite � quelques recherches sur le net, je me suis renseign� sur la criptologie
RSA.
Je pense en avoir relativement bien saisi les tenants et aboutissants mais je me
pose une question :
Les clefs publiques permettent de cr�er quasi instantan�ment le message chiffr�
; pourquoi, plut�t que de chercher � retrouver la clef priv�e, ne pas cr�er une
table de correspondance entre messages clairs et messages chiffr�s ?
En rentrant toutes les valeurs possibles entre 0 et la clef publique dans
l'algoritme de criptage et en en enregistrant les valeurs cript�es en sortie, on
obtiendrait donc tr�s rapidement un tableau de correspondance entre les valeurs
claires et cript�es.
D�cripter un message en partant des valeurs cript�es en utilisant le tableau de
correspondance serait alors possible et relativement facile non ?
Merdi d'�clairer ma lanterne !
Jujul3p
Suite � quelques recherches sur le net, je me suis renseign� sur la criptologie
RSA.
Je pense en avoir relativement bien saisi les tenants et aboutissants mais je me
pose une question :
Les clefs publiques permettent de cr�er quasi instantan�ment le message chiffr�
; pourquoi, plut�t que de chercher � retrouver la clef priv�e, ne pas cr�er une
table de correspondance entre messages clairs et messages chiffr�s ?
En rentrant toutes les valeurs possibles entre 0 et la clef publique dans
l'algoritme de criptage et en en enregistrant les valeurs cript�es en sortie, on
obtiendrait donc tr�s rapidement un tableau de correspondance entre les valeurs
claires et cript�es.
D�cripter un message en partant des valeurs cript�es en utilisant le tableau de
correspondance serait alors possible et relativement facile non ?
Merdi d'�clairer ma lanterne !
Jujul3p
Christophe HENRY
Jan 11, 2013, 9:48:49 AM1/11/13
to
Le Tue, 08 Jan 2013 04:42:00 -0600, jujul3p a écrit :
> (...)
> Suite à quelques recherches sur le net, je me suis renseigné sur la
> criptologie RSA.
> (...)
> Les clefs publiques permettent de créer quasi instantanément le message
> chiffré ; pourquoi, plutôt que de chercher à retrouver la clef privée,
> ne pas créer une table de correspondance entre messages clairs et
> messages chiffrés ?
Parce que ça prendrait trop de temps et d'espace. À la louche, il
faudrait facilement plus que l'univers lui-même en espace et plus que le
temps qu'il existe. Mais il y a encore d'autres difficultés.
> En rentrant toutes les valeurs possibles entre 0 et la clef publique
> dans l'algoritme de criptage et en en enregistrant les valeurs criptées
> en sortie, on obtiendrait donc très rapidement un tableau de
> correspondance entre les valeurs claires et criptées.
Il y a une composante aléatoire dans le chiffrement. Ce qui fait que le
même message chiffré deux fois de suite, dans les mêmes conditions (lieu,
ordinateur, etc.) fournit deux chiffrés différents. Le déchiffrement, en
revanche, tombe toujours juste.
Ça signifie que pour un message chiffré donné, il faudrait retenir toutes
ses variantes. Et là aussi, même pour un seul message, l'univers n'y
suffirait sans doute pas.
> Décripter un message en partant des valeurs criptées en utilisant le
essayer de chiffrer une seule lettre en boucle pour voir jusqu'où ça va...
J'ai chiffré "texte clair" deux fois de suite. Par défaut, ça chiffre
pour ma clé. Les sommes de contrôles sont différentes. Ça veut dire que
même si tu connais la première version chiffrée de "texte clair", il est
calculatoirement improbable que lorsque je rechiffrerai "texte clair" je
retombe sur le chiffré que tu connais.
$ echo "texte clair"|gpg --encrypt |md5sum
97b9b648dd9f358140379880281f036d -
$ echo "texte clair"|gpg --encrypt |md5sum
f7df68bb6e513b527e1ecbd5bbb7dfc8 -
Idem pour la signature, avec Gnupg. À chaque fois la signature numérique
est différente pour le même texte. Par contre, on peut effectivement
rejouer un texte signé et se faire passer pour son légitime propriétaire.
Au plaisir :-)
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
> (...)
> Suite à quelques recherches sur le net, je me suis renseigné sur la
> criptologie RSA.
> (...)
> Les clefs publiques permettent de créer quasi instantanément le message
> chiffré ; pourquoi, plutôt que de chercher à retrouver la clef privée,
> ne pas créer une table de correspondance entre messages clairs et
> messages chiffrés ?
Parce que ça prendrait trop de temps et d'espace. À la louche, il
faudrait facilement plus que l'univers lui-même en espace et plus que le
temps qu'il existe. Mais il y a encore d'autres difficultés.
> En rentrant toutes les valeurs possibles entre 0 et la clef publique
> en sortie, on obtiendrait donc très rapidement un tableau de
> correspondance entre les valeurs claires et criptées.
Il y a une composante aléatoire dans le chiffrement. Ce qui fait que le
même message chiffré deux fois de suite, dans les mêmes conditions (lieu,
ordinateur, etc.) fournit deux chiffrés différents. Le déchiffrement, en
revanche, tombe toujours juste.
Ça signifie que pour un message chiffré donné, il faudrait retenir toutes
ses variantes. Et là aussi, même pour un seul message, l'univers n'y
suffirait sans doute pas.
> Décripter un message en partant des valeurs criptées en utilisant le
> tableau de correspondance serait alors possible et relativement facile
> non ?
Je confirme, à la nuance près de la taille du tableau. Il faudrait
> non ?
essayer de chiffrer une seule lettre en boucle pour voir jusqu'où ça va...
J'ai chiffré "texte clair" deux fois de suite. Par défaut, ça chiffre
pour ma clé. Les sommes de contrôles sont différentes. Ça veut dire que
même si tu connais la première version chiffrée de "texte clair", il est
calculatoirement improbable que lorsque je rechiffrerai "texte clair" je
retombe sur le chiffré que tu connais.
$ echo "texte clair"|gpg --encrypt |md5sum
97b9b648dd9f358140379880281f036d -
$ echo "texte clair"|gpg --encrypt |md5sum
f7df68bb6e513b527e1ecbd5bbb7dfc8 -
Idem pour la signature, avec Gnupg. À chaque fois la signature numérique
est différente pour le même texte. Par contre, on peut effectivement
rejouer un texte signé et se faire passer pour son légitime propriétaire.
Au plaisir :-)
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
jujul3p
Jan 15, 2013, 10:25:44 AM1/15/13
to
Le mardi 08 Janvier 2013 à 11:41 par jujul3p :
> Bonjour à tous,
>
> Suite à quelques recherches sur le net, je me suis renseigné sur
> correspondance entre messages clairs et messages chiffrés ?
> sortie, on obtiendrait donc très rapidement un tableau de correspondance
> entre les valeurs claires et criptées.
>
> Décripter un message en partant des valeurs criptées en utilisant
>
> Jujul3p
Merci de ta réponse.
En effet, la création d'une table serait trop consommatrice en temps et en
espace.
Pour la composante aléatoire dans le chiffrement dans le RSA, je suis plus
sceptique. As tu utilisé un algorithme RSA ?
En tout cas encore merci.
> Bonjour à tous,
>
> Suite à quelques recherches sur le net, je me suis renseigné sur
> la criptologie RSA.
>
> Je pense en avoir relativement bien saisi les tenants et aboutissants mais je
> me pose une question :
>
>
> Je pense en avoir relativement bien saisi les tenants et aboutissants mais je
> me pose une question :
>
> Les clefs publiques permettent de créer quasi instantanément le
> message chiffré ; pourquoi, plutôt que de chercher à
> retrouver la clef privée, ne pas créer une table de
> message chiffré ; pourquoi, plutôt que de chercher à
> correspondance entre messages clairs et messages chiffrés ?
>
> En rentrant toutes les valeurs possibles entre 0 et la clef publique dans
> l'algoritme de criptage et en en enregistrant les valeurs criptées en
> En rentrant toutes les valeurs possibles entre 0 et la clef publique dans
> sortie, on obtiendrait donc très rapidement un tableau de correspondance
> entre les valeurs claires et criptées.
>
> Décripter un message en partant des valeurs criptées en utilisant
> le tableau de correspondance serait alors possible et relativement facile non
> ?
>
> Merdi d'éclairer ma lanterne !
> ?
>
>
> Jujul3p
Merci de ta réponse.
En effet, la création d'une table serait trop consommatrice en temps et en
espace.
Pour la composante aléatoire dans le chiffrement dans le RSA, je suis plus
sceptique. As tu utilisé un algorithme RSA ?
En tout cas encore merci.
Erwann Abalea
Jan 15, 2013, 10:52:21 AM1/15/13
to
Le mardi 15 janvier 2013 16:25:44 UTC+1, jujul3p a écrit :
> Pour la composante aléatoire dans le chiffrement dans le RSA, je suis plus
> sceptique. As tu utilisé un algorithme RSA ?
On ne fait jamais de RSA pur, on ajoute du padding.
> Pour la composante aléatoire dans le chiffrement dans le RSA, je suis plus
> sceptique. As tu utilisé un algorithme RSA ?
Lire PKCS#1 (http://www.rsa.com/rsalabs/node.asp?id=2125) qui en définit 2:
- RSAES-PKCS1-V1_5, l'historique massivement utilisé qu'il faudrait arriver à virer
- RSAES-OAEP, le joli avec une preuve de sécurité qui devrait remplacer le précédent
Dans ces 2 schémas de chiffrement, on met de l'aléa, pour de bonnes raisons. Résister à ce que vous proposez de faire est une de ces raisons.
Christophe HENRY
Jan 16, 2013, 11:18:14 AM1/16/13
to
Le Tue, 15 Jan 2013 09:25:44 -0600, jujul3p a écrit :
> Merci de ta réponse.
> En effet, la création d'une table serait trop consommatrice en temps et
> en espace.
>
> Pour la composante aléatoire dans le chiffrement dans le RSA, je suis
> plus sceptique. As tu utilisé un algorithme RSA ?
Les implémentations que je connais le font. D'une part, parce que le RSA
> Merci de ta réponse.
> En effet, la création d'une table serait trop consommatrice en temps et
> en espace.
>
> Pour la composante aléatoire dans le chiffrement dans le RSA, je suis
> plus sceptique. As tu utilisé un algorithme RSA ?
(et autres) n'est pas utilisé directement et d'autre part pour résister à
une attaque telle que tu l'as décrit.
Il y a des exceptions. Bitcoin permet de signer des messages par un
compte. La signature est toujours la même pour un message donné et un
compte donné.
Voilà un exemple approximatif de ce qui se passe lorsqu'on chiffre avec
Gnupg :
1/ Une clé de session aléatoire est générée.
2/ Le clair est bourré (padding) aléatoirement pour atteindre une
longueur convenue.
3/ Le clair est chiffré avec la clé de session.
4/ La clé de session est chiffrée avec le RSA.
Pour le déchiffrement :
1/ La clé de session est déchiffrée avec le RSA.
2/ Le clair est déchiffré avec la clé de session.
Cela permet d'utiliser le chiffrement symétrique de session qui est bien
plus rapide que le chiffrement asymétrique du RSA. Cela a encore un autre
intérêt, celui de chiffrer le message pour plusieurs destinataires. On
évite d'avoir X fois le même message, chiffré pour X destinataires
différents. On préfère avoir 1 seule fois le message chiffré avec la clé
de session et X fois la clé de session chiffrée pour X destinataires.
0 new messages