http://www.apprendre-en-ligne.net/crypto/rsa/267_104_108.pdf
je me demande quelles sont les consequences pour la societe civile
si rsa tombe
la premiere chose qui me vient a l'esprit c'est la carte bancaire
mais bon ce n'est pas tres grave un vol restera un vol
quels sont les resaux informatiques qui sont proteges par rsa ??
l'aviation ,les satellites ,... ???
a+ remy
"remy" a écrit dans le message de news: cclga9$thb$
"Roland" a écrit dans le message de news: 40edbaf2$0$18116$
Bonjour
J'imagine que ceci a déjà été discuté 10000 fois, mais je n'en trouve pas de trace: Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ? Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
a en binaire a+1 bit=2*a
donc tu double l'espace de factorisation
pour etre completement honnete la difference entre deux nombres premier consecutifs est egale en gros desole on n'a pas mieux a log(n)
donc
p*q=m sqrt(m) +/- log (sqrt(m)) si p!=q
a+ remy
A+ Roland
remy wrote:
bonjour
apres la lecture de
http://www.apprendre-en-ligne.net/crypto/rsa/267_104_108.pdf je me demande quelles sont les consequences pour la societe civile si rsa tombe la premiere chose qui me vient a l'esprit c'est la carte bancaire mais bon ce n'est pas tres grave un vol restera un vol
quels sont les resaux informatiques qui sont proteges par rsa ?? l'aviation ,les satellites ,... ??? a+ remy
"remy" <remy@fctpas.fr> a écrit dans le message de news:
cclga9$thb$1@news-reader5.wanadoo.fr...
"Roland" <x-kane@hotmail.com> a écrit dans le message de news:
40edbaf2$0$18116$626a14ce@news.free.fr...
Bonjour
J'imagine que ceci a déjà été discuté 10000 fois, mais je n'en trouve
pas de trace:
Avez vous une estimation du besoin CPU (en MIPS par exemple) pour
factoriser un nombre de n bits ?
Au moins une idée de la progression : double-t-elle quand on ajoute
quelques bits, quand on double la longueur n, etc.
a en binaire
a+1 bit=2*a
donc tu double l'espace de factorisation
pour etre completement honnete
la difference entre deux nombres premier consecutifs
est egale en gros desole on n'a pas mieux a log(n)
donc
p*q=m
sqrt(m) +/- log (sqrt(m))
si p!=q
a+ remy
A+
Roland
remy wrote:
bonjour
apres la lecture de
http://www.apprendre-en-ligne.net/crypto/rsa/267_104_108.pdf
je me demande quelles sont les consequences pour la societe civile
si rsa tombe
la premiere chose qui me vient a l'esprit c'est la carte bancaire
mais bon ce n'est pas tres grave un vol restera un vol
quels sont les resaux informatiques qui sont proteges par rsa ??
l'aviation ,les satellites ,... ???
a+ remy
"remy" a écrit dans le message de news: cclga9$thb$
"Roland" a écrit dans le message de news: 40edbaf2$0$18116$
Bonjour
J'imagine que ceci a déjà été discuté 10000 fois, mais je n'en trouve pas de trace: Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ? Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
a en binaire a+1 bit=2*a
donc tu double l'espace de factorisation
pour etre completement honnete la difference entre deux nombres premier consecutifs est egale en gros desole on n'a pas mieux a log(n)
donc
p*q=m sqrt(m) +/- log (sqrt(m)) si p!=q
a+ remy
A+ Roland
remy wrote:
bonjour
apres la lecture de
http://www.apprendre-en-ligne.net/crypto/rsa/267_104_108.pdf je me demande quelles sont les consequences pour la societe civile si rsa tombe la premiere chose qui me vient a l'esprit c'est la carte bancaire mais bon ce n'est pas tres grave un vol restera un vol
quels sont les resaux informatiques qui sont proteges par rsa ?? l'aviation ,les satellites ,... ??? a+ remy
Francois Grieu
Roland demande:
Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de calcul utilisée n'est pas publiée pour l'instant, que je sache. <http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999 <http://db.cwi.nl/rapporten/abstract.php?abstractnri0> S'il faut résumer l'effort en quelques chiffres 8400 MIPS.an; 36 CPU.an (criblage) 224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS) évolue sensiblement en e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3))) avec k = (64/9)^(1/3) = 1,923.. et il y a une piste pour descendre à k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté est moins qu'exponentielle, mais pas tant que ça. La formule (avec le k le plus prudent) prédit que passer de 512 à 576 bits multiple l'effort par 10,6 passer de 576 à 640 bits multiple l'effort par 9,1 passer de 640 à 704 bits multiple l'effort par 8,0 passer de 704 à 768 bits multiple l'effort par 7,2 passer de 768 à 832 bits multiple l'effort par 6,5 passer de 832 à 896 bits multiple l'effort par 6,0 passer de 896 à 960 bits multiple l'effort par 5,6 passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an pour les records de factorisation est bien moindre que ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans à venir est selon moi de l'ordre de 32 bits par an, progrès techniques et théoriques confondus, sans prendre de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les progrès techniques et théoriques ralentissent un peu, ce qui est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour l'hypothèse que d'ici à 2016, la plus grande clé RSA dont la factorisation sera effectuée dans un contexte académique l'année A portera sur un nombre d'au plus (A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag. <http://citeseer.ist.psu.edu/287428.html>
Roland <x-kane@hotmail.com> demande:
Avez vous une estimation du besoin CPU (en MIPS par exemple)
pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de
calcul utilisée n'est pas publiée pour l'instant, que je sache.
<http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999
<http://db.cwi.nl/rapporten/abstract.php?abstractnri0>
S'il faut résumer l'effort en quelques chiffres
8400 MIPS.an; 36 CPU.an (criblage)
224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand
on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS)
évolue sensiblement en
e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3)))
avec k = (64/9)^(1/3) = 1,923..
et il y a une piste pour descendre à
k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté
est moins qu'exponentielle, mais pas tant que ça.
La formule (avec le k le plus prudent) prédit que
passer de 512 à 576 bits multiple l'effort par 10,6
passer de 576 à 640 bits multiple l'effort par 9,1
passer de 640 à 704 bits multiple l'effort par 8,0
passer de 704 à 768 bits multiple l'effort par 7,2
passer de 768 à 832 bits multiple l'effort par 6,5
passer de 832 à 896 bits multiple l'effort par 6,0
passer de 896 à 960 bits multiple l'effort par 5,6
passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an
pour les records de factorisation est bien moindre que
ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans
à venir est selon moi de l'ordre de 32 bits par an,
progrès techniques et théoriques confondus, sans prendre
de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les
progrès techniques et théoriques ralentissent un peu, ce qui
est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une
taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour
l'hypothèse que d'ici à 2016, la plus grande clé RSA
dont la factorisation sera effectuée dans un contexte
académique l'année A portera sur un nombre d'au plus
(A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic
Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag.
<http://citeseer.ist.psu.edu/287428.html>
Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de calcul utilisée n'est pas publiée pour l'instant, que je sache. <http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999 <http://db.cwi.nl/rapporten/abstract.php?abstractnri0> S'il faut résumer l'effort en quelques chiffres 8400 MIPS.an; 36 CPU.an (criblage) 224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS) évolue sensiblement en e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3))) avec k = (64/9)^(1/3) = 1,923.. et il y a une piste pour descendre à k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté est moins qu'exponentielle, mais pas tant que ça. La formule (avec le k le plus prudent) prédit que passer de 512 à 576 bits multiple l'effort par 10,6 passer de 576 à 640 bits multiple l'effort par 9,1 passer de 640 à 704 bits multiple l'effort par 8,0 passer de 704 à 768 bits multiple l'effort par 7,2 passer de 768 à 832 bits multiple l'effort par 6,5 passer de 832 à 896 bits multiple l'effort par 6,0 passer de 896 à 960 bits multiple l'effort par 5,6 passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an pour les records de factorisation est bien moindre que ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans à venir est selon moi de l'ordre de 32 bits par an, progrès techniques et théoriques confondus, sans prendre de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les progrès techniques et théoriques ralentissent un peu, ce qui est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour l'hypothèse que d'ici à 2016, la plus grande clé RSA dont la factorisation sera effectuée dans un contexte académique l'année A portera sur un nombre d'au plus (A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag. <http://citeseer.ist.psu.edu/287428.html>
Roland
Ca s'appelle une réponse précise. Merci
Francois Grieu wrote:
Roland demande:
Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de calcul utilisée n'est pas publiée pour l'instant, que je sache. <http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999 <http://db.cwi.nl/rapporten/abstract.php?abstractnri0> S'il faut résumer l'effort en quelques chiffres 8400 MIPS.an; 36 CPU.an (criblage) 224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS) évolue sensiblement en e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3))) avec k = (64/9)^(1/3) = 1,923.. et il y a une piste pour descendre à k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté est moins qu'exponentielle, mais pas tant que ça. La formule (avec le k le plus prudent) prédit que passer de 512 à 576 bits multiple l'effort par 10,6 passer de 576 à 640 bits multiple l'effort par 9,1 passer de 640 à 704 bits multiple l'effort par 8,0 passer de 704 à 768 bits multiple l'effort par 7,2 passer de 768 à 832 bits multiple l'effort par 6,5 passer de 832 à 896 bits multiple l'effort par 6,0 passer de 896 à 960 bits multiple l'effort par 5,6 passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an pour les records de factorisation est bien moindre que ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans à venir est selon moi de l'ordre de 32 bits par an, progrès techniques et théoriques confondus, sans prendre de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les progrès techniques et théoriques ralentissent un peu, ce qui est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour l'hypothèse que d'ici à 2016, la plus grande clé RSA dont la factorisation sera effectuée dans un contexte académique l'année A portera sur un nombre d'au plus (A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag. <http://citeseer.ist.psu.edu/287428.html>
Ca s'appelle une réponse précise. Merci
Francois Grieu wrote:
Roland <x-kane@hotmail.com> demande:
Avez vous une estimation du besoin CPU (en MIPS par exemple)
pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de
calcul utilisée n'est pas publiée pour l'instant, que je sache.
<http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999
<http://db.cwi.nl/rapporten/abstract.php?abstractnri0>
S'il faut résumer l'effort en quelques chiffres
8400 MIPS.an; 36 CPU.an (criblage)
224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand
on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS)
évolue sensiblement en
e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3)))
avec k = (64/9)^(1/3) = 1,923..
et il y a une piste pour descendre à
k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté
est moins qu'exponentielle, mais pas tant que ça.
La formule (avec le k le plus prudent) prédit que
passer de 512 à 576 bits multiple l'effort par 10,6
passer de 576 à 640 bits multiple l'effort par 9,1
passer de 640 à 704 bits multiple l'effort par 8,0
passer de 704 à 768 bits multiple l'effort par 7,2
passer de 768 à 832 bits multiple l'effort par 6,5
passer de 832 à 896 bits multiple l'effort par 6,0
passer de 896 à 960 bits multiple l'effort par 5,6
passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an
pour les records de factorisation est bien moindre que
ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans
à venir est selon moi de l'ordre de 32 bits par an,
progrès techniques et théoriques confondus, sans prendre
de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les
progrès techniques et théoriques ralentissent un peu, ce qui
est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une
taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour
l'hypothèse que d'ici à 2016, la plus grande clé RSA
dont la factorisation sera effectuée dans un contexte
académique l'année A portera sur un nombre d'au plus
(A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic
Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag.
<http://citeseer.ist.psu.edu/287428.html>
Avez vous une estimation du besoin CPU (en MIPS par exemple) pour factoriser un nombre de n bits ?
L'état de l'art est 576 bits en 2003, mais la puissance de calcul utilisée n'est pas publiée pour l'instant, que je sache. <http://www.loria.fr/~zimmerma/records/rsa576>
La référence précédente est 512 bits en 1999 <http://db.cwi.nl/rapporten/abstract.php?abstractnri0> S'il faut résumer l'effort en quelques chiffres 8400 MIPS.an; 36 CPU.an (criblage) 224 CPU.h, 2 Go de mémoire sur Cray C916 (système linéaire)
Au moins une idée de la progression : double-t-elle quand on ajoute quelques bits, quand on double la longueur n, etc.
Le coût pour factoriser n par cette méthode (GNFS) évolue sensiblement en e^(k*(Log(n)^(1/3))*(Log(Log(n))^(2/3))) avec k = (64/9)^(1/3) = 1,923.. et il y a une piste pour descendre à k = ((92+26*(13^(1/2)))/27)^(1/3) = 1,902..
La progression entre la taille en bit et la difficulté est moins qu'exponentielle, mais pas tant que ça. La formule (avec le k le plus prudent) prédit que passer de 512 à 576 bits multiple l'effort par 10,6 passer de 576 à 640 bits multiple l'effort par 9,1 passer de 640 à 704 bits multiple l'effort par 8,0 passer de 704 à 768 bits multiple l'effort par 7,2 passer de 768 à 832 bits multiple l'effort par 6,5 passer de 832 à 896 bits multiple l'effort par 6,0 passer de 896 à 960 bits multiple l'effort par 5,6 passer de 960 à 1024 bits multiple l'effort par 5,2
Historiquement la progression de l'effort en MIPS.an pour les records de factorisation est bien moindre que ne le donne cette formule, du fait de progrès théoriques.
Très à la hache, le progrès prévisible dans les 10 ans à venir est selon moi de l'ordre de 32 bits par an, progrès techniques et théoriques confondus, sans prendre de marge de sécurité.
Note: cette hypothèse est fondée sur la conjecture que les progrès techniques et théoriques ralentissent un peu, ce qui est une opinion personelle et mal étayée.
Note: Ne pas utiliser cette hypothèse pour choisir une taille de clé: se reporter à [1] quand le contexte le permet.
Malgré ces réserves, à 50/50, je parie cependant pour l'hypothèse que d'ici à 2016, la plus grande clé RSA dont la factorisation sera effectuée dans un contexte académique l'année A portera sur un nombre d'au plus (A-2000)*32+512 bits.
François Grieu
[1] Arjen K. Lenstra, Eric R. Verheul: "Selecting Cryptographic Key Sizes", Public Key Cryptography, LNCS 1751, Springer-Verlag. <http://citeseer.ist.psu.edu/287428.html>
Pierre Vandevenne
Francois Grieu wrote in news:fgrieu- :
Ce résultat est à prendre avec des pincettes, pour plein de raisons:
Merci pour ta réponse (que je vois seulement aoujourd'hui). En la relisant je me rends compte que ma question était n'était pas super intelligente puisque les deux facteurs - si j'ose dire - sont étroitement liés: certaines avancées théoriques ne deviennent possibles que parce qu'on devient capable d'adresser des quantités de plus en plus importantes de mémoire...
Francois Grieu <fgrieu@francenet.fr> wrote in news:fgrieu-
D03875.17502408072004@individual.net:
Ce résultat est à prendre avec des pincettes, pour plein de
raisons:
Merci pour ta réponse (que je vois seulement aoujourd'hui). En la relisant
je me rends compte que ma question était n'était pas super intelligente
puisque les deux facteurs - si j'ose dire - sont étroitement liés:
certaines avancées théoriques ne deviennent possibles que parce qu'on
devient capable d'adresser des quantités de plus en plus importantes de
mémoire...
Ce résultat est à prendre avec des pincettes, pour plein de raisons:
Merci pour ta réponse (que je vois seulement aoujourd'hui). En la relisant je me rends compte que ma question était n'était pas super intelligente puisque les deux facteurs - si j'ose dire - sont étroitement liés: certaines avancées théoriques ne deviennent possibles que parce qu'on devient capable d'adresser des quantités de plus en plus importantes de mémoire...
pornin
According to Pierre Vandevennne :
Faut savoir que si RSA est aussi populaire aujourd'hui c'est parce que les méthodes d'attaque sont équivalentes à des problèmes étudiés depuis des millénaires et qu'on ne peut s'attendre à des progrès majeurs subits.
De mon point de vue, RSA est populaire parce qu'il a existé relativement tôt une société nommée "RSA" qui a eu la bonne idée de publier des "standards". Que RSA soit relativement simple dans son principe (des calculs modulaires -- rien de bien sorcier, comparativement à, par exemple, des calculs sur courbes elliptiques), soit. Mais entre une exponentiation modulaire et un système de chiffrement interopérable, il y a une nuance importante, qu'on a trop souvent coutume de balayer d'un revers de main dans les milieux académiques. Du point de vue industriel, pour faire tourner le machin, il faut avoir une définition précise de quel octet va où. PKCS#1, "standard" défini et publié par RSA Labs, dit précisément comment tout ça se passe. Il est aisé, pour un implémenteur, de faire un système "RSA" qui pourra interagir avec des systèmes RSA d'autres implémenteurs.
Maintenant, supposons qu'on veuille faire pareil avec El-Gamal. Ou Rabin-Williams. Ou Diffie-Hellman. C'est là qu'on voit que ça plante, parce qu'il n'y a pas de standard établi. Mention spéciale pour Diffie-Hellman, qui a pourtant un standard (américain) le décrivant, payant, et qui vient avec des vecteurs de test faux !
Si c'était juste une histoire de progrès scientifique et de compréhension du problème de la factorisation, on ferait du Rabin-Williams, pas du RSA (RW est un poil plus efficace que RSA, et en plus il est prouvé équivalent à la factorisation, donc RW est au moins aussi solide que RSA pour une même taille de clé). RSA est très répandu parce qu'il a bénéficié d'un marketing de qualité.
--Thomas Pornin
According to Pierre Vandevennne <pierre@datarescue_ns.com>:
Faut savoir que si RSA est aussi populaire aujourd'hui c'est parce
que les méthodes d'attaque sont équivalentes à des problèmes étudiés
depuis des millénaires et qu'on ne peut s'attendre à des progrès
majeurs subits.
De mon point de vue, RSA est populaire parce qu'il a existé relativement
tôt une société nommée "RSA" qui a eu la bonne idée de publier des
"standards". Que RSA soit relativement simple dans son principe (des
calculs modulaires -- rien de bien sorcier, comparativement à, par
exemple, des calculs sur courbes elliptiques), soit. Mais entre une
exponentiation modulaire et un système de chiffrement interopérable, il
y a une nuance importante, qu'on a trop souvent coutume de balayer d'un
revers de main dans les milieux académiques. Du point de vue industriel,
pour faire tourner le machin, il faut avoir une définition précise de
quel octet va où. PKCS#1, "standard" défini et publié par RSA Labs, dit
précisément comment tout ça se passe. Il est aisé, pour un implémenteur,
de faire un système "RSA" qui pourra interagir avec des systèmes RSA
d'autres implémenteurs.
Maintenant, supposons qu'on veuille faire pareil avec El-Gamal. Ou
Rabin-Williams. Ou Diffie-Hellman. C'est là qu'on voit que ça plante,
parce qu'il n'y a pas de standard établi. Mention spéciale pour
Diffie-Hellman, qui a pourtant un standard (américain) le décrivant,
payant, et qui vient avec des vecteurs de test faux !
Si c'était juste une histoire de progrès scientifique et de
compréhension du problème de la factorisation, on ferait du
Rabin-Williams, pas du RSA (RW est un poil plus efficace que RSA, et en
plus il est prouvé équivalent à la factorisation, donc RW est au moins
aussi solide que RSA pour une même taille de clé). RSA est très répandu
parce qu'il a bénéficié d'un marketing de qualité.
Faut savoir que si RSA est aussi populaire aujourd'hui c'est parce que les méthodes d'attaque sont équivalentes à des problèmes étudiés depuis des millénaires et qu'on ne peut s'attendre à des progrès majeurs subits.
De mon point de vue, RSA est populaire parce qu'il a existé relativement tôt une société nommée "RSA" qui a eu la bonne idée de publier des "standards". Que RSA soit relativement simple dans son principe (des calculs modulaires -- rien de bien sorcier, comparativement à, par exemple, des calculs sur courbes elliptiques), soit. Mais entre une exponentiation modulaire et un système de chiffrement interopérable, il y a une nuance importante, qu'on a trop souvent coutume de balayer d'un revers de main dans les milieux académiques. Du point de vue industriel, pour faire tourner le machin, il faut avoir une définition précise de quel octet va où. PKCS#1, "standard" défini et publié par RSA Labs, dit précisément comment tout ça se passe. Il est aisé, pour un implémenteur, de faire un système "RSA" qui pourra interagir avec des systèmes RSA d'autres implémenteurs.
Maintenant, supposons qu'on veuille faire pareil avec El-Gamal. Ou Rabin-Williams. Ou Diffie-Hellman. C'est là qu'on voit que ça plante, parce qu'il n'y a pas de standard établi. Mention spéciale pour Diffie-Hellman, qui a pourtant un standard (américain) le décrivant, payant, et qui vient avec des vecteurs de test faux !
Si c'était juste une histoire de progrès scientifique et de compréhension du problème de la factorisation, on ferait du Rabin-Williams, pas du RSA (RW est un poil plus efficace que RSA, et en plus il est prouvé équivalent à la factorisation, donc RW est au moins aussi solide que RSA pour une même taille de clé). RSA est très répandu parce qu'il a bénéficié d'un marketing de qualité.
--Thomas Pornin
Jean-Marc Desperrier
Thomas Pornin wrote:
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même chose. Et point presque aussi important, gratuite, tous les PKCS disponibles en ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il faut payer pour avoir, comme par hasard personne ne l'implémente correctement.
Thomas Pornin wrote:
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même chose.
Et point presque aussi important, gratuite, tous les PKCS disponibles en
ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui
n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il faut
payer pour avoir, comme par hasard personne ne l'implémente correctement.
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même chose. Et point presque aussi important, gratuite, tous les PKCS disponibles en ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il faut payer pour avoir, comme par hasard personne ne l'implémente correctement.
Pierre Vandevennne
Jean-Marc Desperrier wrote in news:cdj3tj$i0a$:
Thomas Pornin wrote:
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même chose. Et point presque aussi important, gratuite, tous les PKCS disponibles en ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il faut payer pour avoir, comme par hasard personne ne l'implémente correctement.
En fait, la conclusion de ce fil est que RSA est populaire pour... des tas de raisons ;-)
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in
news:cdj3tj$i0a$1@reader1.imaginet.fr:
Thomas Pornin wrote:
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même
chose. Et point presque aussi important, gratuite, tous les PKCS
disponibles en ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui
n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il
faut payer pour avoir, comme par hasard personne ne l'implémente
correctement.
En fait, la conclusion de ce fil est que RSA est populaire pour... des tas
de raisons ;-)
parce qu'il a bénéficié d'un marketing de qualité.
Plutôt *documentation* de qualité, ce n'est pas tout à fait la même chose. Et point presque aussi important, gratuite, tous les PKCS disponibles en ligne.
Comparativement dès qu'un des éléments fait référence à un truc qui n'est *que* dans un standard ANSI Xnnn, pas dans les pkcs et qu'il faut payer pour avoir, comme par hasard personne ne l'implémente correctement.
En fait, la conclusion de ce fil est que RSA est populaire pour... des tas de raisons ;-)
