Ok, donc là si j'ai bien pigé, ils ont réussi à trouvé la clé privée à partir de la publique, donc tous les messages qui ont été chiffrés avec cette clé peuvent être déchiffrés.
Exactement.
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le produit des deux nombres premiers. En réussissant à factoriser le produit des nombres premiers, qui est inclus dans la clé publique, il est possible de calculer la clé secrète.
puisqu'il s'agit d'une attaque sur la clef elle-même, par recherche exhaustive, et non une attaque sur une faiblesse du protocole (si j'ai bien tout suivi du moins).
C'est effectivement une attaque sur la clé, il suffit de choisir une clé plus forte pour être protégé.
Mais si demain, un génie des mathématiques sort un algo qui permet de factoriser n'importe quel nombre en 1/4 d'heure, alors, le protocole deviendra faible.
La force de l'algo réside dan la difficulté rencontrée pour factoriser des grands nombres. Tant que les nombres choisis sont suffisamment grands et que la factorisation sera difficile, l'algo sera fort.
Là, l'algo n'a pas été cassé, mais l'attaque a augmenté la taille limite des nombres premiers à choisir pour que la clé soit sécurisée. Enfin, bon, il y a longtemps que personne ne préconise plus de clé de 768 bits comme limite minimum. Cette attaque a surtout montré l'avancée des capacités de calcul.
Bruno Tréguier wrote:
passage wrote:
il y a une espèce de "symétrie"
dans l'asymétrie,
J'aime bien la formule.
Ok, donc là si j'ai bien pigé, ils ont réussi à trouvé la clé privée à
partir de la publique, donc tous les messages qui ont été chiffrés avec
cette clé peuvent être déchiffrés.
Exactement.
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique
qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le
produit des deux nombres premiers. En réussissant à factoriser le
produit des nombres premiers, qui est inclus dans la clé publique, il
est possible de calculer la clé secrète.
puisqu'il s'agit d'une
attaque sur la clef elle-même, par recherche exhaustive, et non une
attaque sur une faiblesse du protocole (si j'ai bien tout suivi du moins).
C'est effectivement une attaque sur la clé, il suffit de choisir une clé
plus forte pour être protégé.
Mais si demain, un génie des mathématiques sort un algo qui permet de
factoriser n'importe quel nombre en 1/4 d'heure, alors, le protocole
deviendra faible.
La force de l'algo réside dan la difficulté rencontrée pour factoriser
des grands nombres. Tant que les nombres choisis sont suffisamment
grands et que la factorisation sera difficile, l'algo sera fort.
Là, l'algo n'a pas été cassé, mais l'attaque a augmenté la taille limite
des nombres premiers à choisir pour que la clé soit sécurisée. Enfin,
bon, il y a longtemps que personne ne préconise plus de clé de 768 bits
comme limite minimum. Cette attaque a surtout montré l'avancée des
capacités de calcul.
Ok, donc là si j'ai bien pigé, ils ont réussi à trouvé la clé privée à partir de la publique, donc tous les messages qui ont été chiffrés avec cette clé peuvent être déchiffrés.
Exactement.
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le produit des deux nombres premiers. En réussissant à factoriser le produit des nombres premiers, qui est inclus dans la clé publique, il est possible de calculer la clé secrète.
puisqu'il s'agit d'une attaque sur la clef elle-même, par recherche exhaustive, et non une attaque sur une faiblesse du protocole (si j'ai bien tout suivi du moins).
C'est effectivement une attaque sur la clé, il suffit de choisir une clé plus forte pour être protégé.
Mais si demain, un génie des mathématiques sort un algo qui permet de factoriser n'importe quel nombre en 1/4 d'heure, alors, le protocole deviendra faible.
La force de l'algo réside dan la difficulté rencontrée pour factoriser des grands nombres. Tant que les nombres choisis sont suffisamment grands et que la factorisation sera difficile, l'algo sera fort.
Là, l'algo n'a pas été cassé, mais l'attaque a augmenté la taille limite des nombres premiers à choisir pour que la clé soit sécurisée. Enfin, bon, il y a longtemps que personne ne préconise plus de clé de 768 bits comme limite minimum. Cette attaque a surtout montré l'avancée des capacités de calcul.
Benoit Izac
Bonjour,
le 11/01/2010 à 23:40, Stéphane CARPENTIER a écrit dans le message <4b4ba8cb$0$11227$ :
La faiblesse réside dans le fait que le produit des deux nombres premiers est public. Il ne faut donc pas que quelqu'un puisse factoriser la produit des nombres premiers, sinon, il peut faire les calculs pour trouver la clé privée. Par exemple, si ton produit est 35, tu dois réussir à trouver 5 et 7 de tête. si ton produit est 899, ça devient un peu plus dur de trouver 29 et 31, mais avec une calculatrice , ça se fait bien. Si ton produit fait 758 bits (donc 232 chiffres pour l'exemple donné par le boulet initial), alors, il faut de très gros moyens pour y arriver, mais c'est maintenant du domaine du possible.
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
-- Benoit Izac
Bonjour,
le 11/01/2010 à 23:40, Stéphane CARPENTIER a écrit dans le message
<4b4ba8cb$0$11227$426a74cc@news.free.fr> :
La faiblesse réside dans le fait que le produit des deux nombres
premiers est public. Il ne faut donc pas que quelqu'un puisse factoriser
la produit des nombres premiers, sinon, il peut faire les calculs pour
trouver la clé privée. Par exemple, si ton produit est 35, tu dois
réussir à trouver 5 et 7 de tête. si ton produit est 899, ça devient un
peu plus dur de trouver 29 et 31, mais avec une calculatrice , ça se
fait bien. Si ton produit fait 758 bits (donc 232 chiffres pour
l'exemple donné par le boulet initial), alors, il faut de très gros
moyens pour y arriver, mais c'est maintenant du domaine du possible.
Petite question en passant, ça représente environ combien de nombre
premiers 758 bits ? Et approximativement quel espace de stockage
faudrait-il pour tous les conserver sur un disque ?
le 11/01/2010 à 23:40, Stéphane CARPENTIER a écrit dans le message <4b4ba8cb$0$11227$ :
La faiblesse réside dans le fait que le produit des deux nombres premiers est public. Il ne faut donc pas que quelqu'un puisse factoriser la produit des nombres premiers, sinon, il peut faire les calculs pour trouver la clé privée. Par exemple, si ton produit est 35, tu dois réussir à trouver 5 et 7 de tête. si ton produit est 899, ça devient un peu plus dur de trouver 29 et 31, mais avec une calculatrice , ça se fait bien. Si ton produit fait 758 bits (donc 232 chiffres pour l'exemple donné par le boulet initial), alors, il faut de très gros moyens pour y arriver, mais c'est maintenant du domaine du possible.
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
-- Benoit Izac
Bruno Tréguier
Bonsoir,
Le 12/01/2010 à 23:19, Stéphane CARPENTIER a écrit :
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le produit des deux nombres premiers. En réussissant à factoriser le produit des nombres premiers, qui est inclus dans la clé publique, il est possible de calculer la clé secrète.
Oui, je vois ce que vous voulez dire, mais en fait tout dépend de ce que l'on appelle "clef privée". Stricto sensu, elle comprend aussi le produit des 2 nombres premiers, puisque ce produit est nécessaire, que ce soit pour chiffrer ou pour déchiffrer (pour l'opération modulo). Mais bon, je pinaille, nous sommes d'accord sur le fond de toute façon. ;-)
Cordialement,
Bruno
Bonsoir,
Le 12/01/2010 à 23:19, Stéphane CARPENTIER a écrit :
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique
qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le
produit des deux nombres premiers. En réussissant à factoriser le
produit des nombres premiers, qui est inclus dans la clé publique, il
est possible de calculer la clé secrète.
Oui, je vois ce que vous voulez dire, mais en fait tout dépend de ce que
l'on appelle "clef privée". Stricto sensu, elle comprend aussi le
produit des 2 nombres premiers, puisque ce produit est nécessaire, que
ce soit pour chiffrer ou pour déchiffrer (pour l'opération modulo). Mais
bon, je pinaille, nous sommes d'accord sur le fond de toute façon. ;-)
Le 12/01/2010 à 23:19, Stéphane CARPENTIER a écrit :
Disons qu'ils ont trouvé la clef privée correspondant à la clef publique qu'ils avaient (et pas "à partir de" ;-) )
Si, c'est quand même « à partir de » puisque la clé publique possède le produit des deux nombres premiers. En réussissant à factoriser le produit des nombres premiers, qui est inclus dans la clé publique, il est possible de calculer la clé secrète.
Oui, je vois ce que vous voulez dire, mais en fait tout dépend de ce que l'on appelle "clef privée". Stricto sensu, elle comprend aussi le produit des 2 nombres premiers, puisque ce produit est nécessaire, que ce soit pour chiffrer ou pour déchiffrer (pour l'opération modulo). Mais bon, je pinaille, nous sommes d'accord sur le fond de toute façon. ;-)
Cordialement,
Bruno
Erwan David
Erwann Abalea écrivait :
Bonjour,
Benoit Izac a écrit :
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend vers l'infini. Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que 2^768/ln(2^768) est égal à:
Petite question en passant, ça représente environ combien de nombre
premiers 758 bits ? Et approximativement quel espace de stockage
faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers
inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend
vers l'infini.
Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que
2^768/ln(2^768) est égal à:
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend vers l'infini. Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que 2^768/ln(2^768) est égal à:
Mais le nombre de nombres premiers de 768 bits est de Pi(2^768) - Pi(2^767)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Benoit Izac
Bonjour,
le 13/01/2010 à 17:28, Erwann Abalea a écrit dans le message <4b4df4c5$0$10146$ :
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend vers l'infini. Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que 2^768/ln(2^768) est égal à:
Mais le nombre de nombres premiers de 768 bits est de Pi(2^768) - Pi(2^767)
Pour les nombres de 768 bits exactement, tu as raison. Ce qui ne fait que diviser le tout par 2, grossièrement.
Ma question portait bien sur le nombre de nombres premiers qu'ils existent pour aller jusqu'à un nombre de 768 bits. Sauf erreur de calcul : % echo '2^768 / ( 2^768 / l(2^768) )' | bc -l 532.33703467003799763243
Ça ferait donc 1 nombre pour 532 qui seraient premiers pour 2^768. C'est effectivement énorme et j'aurais volontiers parié pour quelque chose de bien inférieur.
Merci. -- Benoit Izac
Bonjour,
le 13/01/2010 à 17:28, Erwann Abalea a écrit dans le message
<4b4df4c5$0$10146$426a74cc@news.free.fr> :
Petite question en passant, ça représente environ combien de nombre
premiers 758 bits ? Et approximativement quel espace de stockage
faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers
inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend
vers l'infini.
Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que
2^768/ln(2^768) est égal à:
Mais le nombre de nombres premiers de 768 bits est de Pi(2^768) - Pi(2^767)
Pour les nombres de 768 bits exactement, tu as raison. Ce qui ne fait que
diviser le tout par 2, grossièrement.
Ma question portait bien sur le nombre de nombres premiers qu'ils
existent pour aller jusqu'à un nombre de 768 bits. Sauf erreur de
calcul :
% echo '2^768 / ( 2^768 / l(2^768) )' | bc -l
532.33703467003799763243
Ça ferait donc 1 nombre pour 532 qui seraient premiers pour 2^768. C'est
effectivement énorme et j'aurais volontiers parié pour quelque chose de
bien inférieur.
le 13/01/2010 à 17:28, Erwann Abalea a écrit dans le message <4b4df4c5$0$10146$ :
Petite question en passant, ça représente environ combien de nombre premiers 758 bits ? Et approximativement quel espace de stockage faudrait-il pour tous les conserver sur un disque ?
Wikipedia te fournit un début de réponse. Le nombre de nombre premiers inférieurs ou égaux à x est Pi(x), qui tend vers x/ln(x) quand x tend vers l'infini. Considérons pour l'exemple que 2^768 représente l'infini; bc me dit que 2^768/ln(2^768) est égal à:
Mais le nombre de nombres premiers de 768 bits est de Pi(2^768) - Pi(2^767)
Pour les nombres de 768 bits exactement, tu as raison. Ce qui ne fait que diviser le tout par 2, grossièrement.
Ma question portait bien sur le nombre de nombres premiers qu'ils existent pour aller jusqu'à un nombre de 768 bits. Sauf erreur de calcul : % echo '2^768 / ( 2^768 / l(2^768) )' | bc -l 532.33703467003799763243
Ça ferait donc 1 nombre pour 532 qui seraient premiers pour 2^768. C'est effectivement énorme et j'aurais volontiers parié pour quelque chose de bien inférieur.
