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 ?
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
Christophe HENRY
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 tableau de correspondance serait alors possible et relativement facile non ?
Je confirme, à la nuance près de la taille du tableau. Il faudrait 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.
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
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
tableau de correspondance serait alors possible et relativement facile
non ?
Je confirme, à la nuance près de la taille du tableau. Il faudrait
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.
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
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 tableau de correspondance serait alors possible et relativement facile non ?
Je confirme, à la nuance près de la taille du tableau. Il faudrait 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.
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
Le mardi 08 Janvier 2013 à 11:41 par jujul3p :
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
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.
Le mardi 08 Janvier 2013 à 11:41 par jujul3p :
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
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 ?
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
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
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 p lus sceptique. As tu utilisé un algorithme RSA ?
On ne fait jamais de RSA pur, on ajoute du padding. Lire PKCS#1 (http://www.rsa.com/rsalabs/node.asp?id!25) qui en défini t 2: - RSAES-PKCS1-V1_5, l'historique massivement utilisé qu'il faudrait arri ver à virer - RSAES-OAEP, le joli avec une preuve de sécurité qui devrait remplace r le précédent
Dans ces 2 schémas de chiffrement, on met de l'aléa, pour de bonnes rai sons. Résister à ce que vous proposez de faire est une de ces raisons.
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 p lus
sceptique. As tu utilisé un algorithme RSA ?
On ne fait jamais de RSA pur, on ajoute du padding.
Lire PKCS#1 (http://www.rsa.com/rsalabs/node.asp?id=2125) qui en défini t 2:
- RSAES-PKCS1-V1_5, l'historique massivement utilisé qu'il faudrait arri ver à virer
- RSAES-OAEP, le joli avec une preuve de sécurité qui devrait remplace r le précédent
Dans ces 2 schémas de chiffrement, on met de l'aléa, pour de bonnes rai sons. Résister à ce que vous proposez de faire est une de ces raisons.
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 p lus sceptique. As tu utilisé un algorithme RSA ?
On ne fait jamais de RSA pur, on ajoute du padding. Lire PKCS#1 (http://www.rsa.com/rsalabs/node.asp?id!25) qui en défini t 2: - RSAES-PKCS1-V1_5, l'historique massivement utilisé qu'il faudrait arri ver à virer - RSAES-OAEP, le joli avec une preuve de sécurité qui devrait remplace r le précédent
Dans ces 2 schémas de chiffrement, on met de l'aléa, pour de bonnes rai sons. Résister à ce que vous proposez de faire est une de ces raisons.
Christophe HENRY
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 (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.
-- Christophe HENRY FR EO EN - http://www.sbgodin.fr
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
(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.
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
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 (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.
-- Christophe HENRY FR EO EN - http://www.sbgodin.fr
