je m'amuse a penser a des systèmes crypto marrants
et j'ai pensé a un cas ou il faudrait cacher la clé publique
RSA comme la clé privé
l'idée c'est d'avoir 3 populations,
ceux qui savent rien,
ceux qui connaissent la clé publique
et peuvent produire des messages cryptés et les comparer
(parler et reconnaitre les messages qu'il ont imaginés),
et ceux qui peuvent les décrypter aussi
(écouter les messages même pas imaginés)
mais je me pose une question sur la clé publique...
déjà l'exposant "e" associé est connu (il y en a 3 ou 4 de classiques,
genre 3 ou 65535)
mais peut t'on retrouver le modulo "n" aussi avec pleins de couple
clair/chiffre "m/c" et l'exposant "e"...
trouver n connaissant e et plein de cas m/c
c=m^e mod n
ou même simplement
c=m^3 mod n
mais si un attaquant dispose d'un tas de clair et du chiffré associé,
et souhaite simplement découvrir la clé publique pour pouvoir chiffrer
(et donc retrouver des chiffrés correspondant a des clairs connus)
[...]. Certaines applications utilisent des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Francois Grieu
Dans l'article <dg9lc4$m9m$, Jean-Marc Desperrier a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par par le règlement (CE) 1360/2002, appendice 11, sous-sous-section 2.2.1 telle qu'ammendée par le Règlement (CE) 432/2004. http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html ou pour ceux qui veulent la trahison Française http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé de test utilisait un exposant public aléatoire, le bon sens et/ou la tradition a prévalu, et la clé réelle a pour exposant public 65537. Les deux se trouvent sur http://dtc.jrc.it
François Grieu
Dans l'article <dg9lc4$m9m$1@reader1.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu
pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par
par le règlement (CE) 1360/2002, appendice 11, sous-sous-section
2.2.1 telle qu'ammendée par le Règlement (CE) 432/2004.
http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html
ou pour ceux qui veulent la trahison Française
http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé de test utilisait un exposant public
aléatoire, le bon sens et/ou la tradition a prévalu, et la clé
réelle a pour exposant public 65537. Les deux se trouvent sur
http://dtc.jrc.it
Dans l'article <dg9lc4$m9m$, Jean-Marc Desperrier a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par par le règlement (CE) 1360/2002, appendice 11, sous-sous-section 2.2.1 telle qu'ammendée par le Règlement (CE) 432/2004. http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html ou pour ceux qui veulent la trahison Française http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé de test utilisait un exposant public aléatoire, le bon sens et/ou la tradition a prévalu, et la clé réelle a pour exposant public 65537. Les deux se trouvent sur http://dtc.jrc.it
François Grieu
Francois Grieu
Dans l'article <dg9lc4$m9m$, Jean-Marc Desperrier a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par le règlement (CE) 1360/2002, appendice 11, sous-section 3.2 http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html ou pour ceux qui veulent la trahison Française http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé européenne de test utilisait un exposant public aléatoire, le bon sens et/ou la tradition a prévalu, et la clé réelle a pour exposant public 65537. Les deux se trouvent sur http://dtc.jrc.it
François Grieu
Dans l'article <dg9lc4$m9m$1@reader1.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu
pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par
le règlement (CE) 1360/2002, appendice 11, sous-section 3.2
http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html
ou pour ceux qui veulent la trahison Française
http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé européenne de test utilisait un exposant public
aléatoire, le bon sens et/ou la tradition a prévalu, et la clé
réelle a pour exposant public 65537. Les deux se trouvent sur
http://dtc.jrc.it
Dans l'article <dg9lc4$m9m$, Jean-Marc Desperrier a écrit:
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Bingo ! Règlement (CEE) 3821/85, Annexe 1B instituée par le règlement (CE) 1360/2002, appendice 11, sous-section 3.2 http://europa.eu.int/eur-lex/en/consleg/main/1985/en_1985R3821_index.html ou pour ceux qui veulent la trahison Française http://europa.eu.int/eur-lex/fr/consleg/main/1985/fr_1985R3821_index.html
Noter que si la clé européenne de test utilisait un exposant public aléatoire, le bon sens et/ou la tradition a prévalu, et la clé réelle a pour exposant public 65537. Les deux se trouvent sur http://dtc.jrc.it
François Grieu
Francois Grieu
Dans l'article , (Erwann Abalea) a écrit:
In article <dg9lc4$m9m$, Jean-Marc Desperrier wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant publique était de 160 bits... J'avais d'ailleurs testé les capacités de nos tokens crypto à générer et mettre en oeuvre une telle clé...
Oui je confirme, la taille maximale de l'exposant public a été réduite de 160 à "seulement" 64 bits; cela réduit d'autant la taille de la clé racine et des deux certificats, soit tout de même 36 octets/carte.
François Grieu
Dans l'article <5cbKDtU3qTfH092yn@abalea.com>,
erwann@abalea.com (Erwann Abalea) a écrit:
In article <dg9lc4$m9m$1@reader1.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent
des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un
truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant
publique était de 160 bits... J'avais d'ailleurs testé les capacités de
nos tokens crypto à générer et mettre en oeuvre une telle clé...
Oui je confirme, la taille maximale de l'exposant public a été
réduite de 160 à "seulement" 64 bits; cela réduit d'autant la
taille de la clé racine et des deux certificats, soit tout de même
36 octets/carte.
In article <dg9lc4$m9m$, Jean-Marc Desperrier wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant publique était de 160 bits... J'avais d'ailleurs testé les capacités de nos tokens crypto à générer et mettre en oeuvre une telle clé...
Oui je confirme, la taille maximale de l'exposant public a été réduite de 160 à "seulement" 64 bits; cela réduit d'autant la taille de la clé racine et des deux certificats, soit tout de même 36 octets/carte.
François Grieu
erwann
In article <dg9lc4$m9m$, Jean-Marc Desperrier wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant publique était de 160 bits... J'avais d'ailleurs testé les capacités de nos tokens crypto à générer et mettre en oeuvre une telle clé...
-- Erwann Abalea , RSA PGP Key Id: 0x2D0EABD5 --- The wrong way always seems the more reasonable.
In article <dg9lc4$m9m$1@reader1.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent
des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un
truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant
publique était de 160 bits... J'avais d'ailleurs testé les capacités de
nos tokens crypto à générer et mettre en oeuvre une telle clé...
--
Erwann Abalea <erwann@abalea.com>, RSA PGP Key Id: 0x2D0EABD5
---
The wrong way always seems the more reasonable.
In article <dg9lc4$m9m$, Jean-Marc Desperrier wrote:
Francois Grieu wrote:
[...]. Certaines applications utilisent des exposants e aléatoires de 64 bits (impairs et >2).
Ca m'évoque vaguement quelque chose. Qui peut-être assez tordu pour un truc de ce genre ... Chronotachygraphes numériques ?
Ah? Ils ont changé? Quand j'ai vu passer l'appel d'offre, l'exposant publique était de 160 bits... J'avais d'ailleurs testé les capacités de nos tokens crypto à générer et mettre en oeuvre une telle clé...
-- Erwann Abalea , RSA PGP Key Id: 0x2D0EABD5 --- The wrong way always seems the more reasonable.
Alain
merci pour la solution... une idee de plus à la poubelle...
la clé publique a tendance à le devenir rapidement 8>
Francois Grieu wrote:
Dans l'article <432735af$0$5369$, Alain demande:
peut t'on retrouver le modulo "n" aussi avec pleins de couple clair/chiffre "m/c" et l'exposant "e" Oui. En effet n divise (m^e)-c. Et en prenant le PGCD de
plusieurs (m^e)-c on retrouve n. François Grieu
merci pour la solution...
une idee de plus à la poubelle...
la clé publique a tendance à le devenir rapidement 8>
Francois Grieu wrote:
Dans l'article <432735af$0$5369$8fcfb975@news.wanadoo.fr>,
Alain <none@none.org> demande:
peut t'on retrouver le modulo "n" aussi avec pleins de couple
clair/chiffre "m/c" et l'exposant "e"
Oui. En effet n divise (m^e)-c. Et en prenant le PGCD de
merci pour la solution... une idee de plus à la poubelle...
la clé publique a tendance à le devenir rapidement 8>
Francois Grieu wrote:
Dans l'article <432735af$0$5369$, Alain demande:
peut t'on retrouver le modulo "n" aussi avec pleins de couple clair/chiffre "m/c" et l'exposant "e" Oui. En effet n divise (m^e)-c. Et en prenant le PGCD de
plusieurs (m^e)-c on retrouve n. François Grieu
Francois Grieu
Dans l'article <4329fe94$0$992$, Alain a écrit
la clé publique a tendance à le devenir rapidement 8>
Noter que plutôt que de maintenir n secret, on peut envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux niveaux de secret: un secret "faible" e, un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir de paires clair/chiffré et de n. Si e fuit, le déchiffrement (ou la génération de signature) reste non affecté.
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
François Grieu
Dans l'article <4329fe94$0$992$8fcfb975@news.wanadoo.fr>,
Alain <none@none.org> a écrit
la clé publique a tendance à le devenir rapidement 8>
Noter que plutôt que de maintenir n secret, on peut
envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux
niveaux de secret: un secret "faible" e,
un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir
de paires clair/chiffré et de n. Si e fuit, le
déchiffrement (ou la génération de signature) reste
non affecté.
Je suis affirmatif que cela fonctionne avec un e
aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1,
et que les message chiffrés ou signés soient formattés
dans les règles de l'art.
Je ne vois pas immédiatement pourquoi cela ne
fonctionnerais pas si e est réduit à disons 160 bits.
la clé publique a tendance à le devenir rapidement 8>
Noter que plutôt que de maintenir n secret, on peut envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux niveaux de secret: un secret "faible" e, un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir de paires clair/chiffré et de n. Si e fuit, le déchiffrement (ou la génération de signature) reste non affecté.
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
François Grieu
Erwan David
Francois Grieu écrivait :
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une attaque efficace quand e est de l'ordre de sqrt(n)
-- Il n'y a pas besoin d'être riche, il suffit d'avoir de l'argent (Chambre de commerce de Palau)
Francois Grieu <fgrieu@francenet.fr> écrivait :
Je suis affirmatif que cela fonctionne avec un e
aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1,
et que les message chiffrés ou signés soient formattés
dans les règles de l'art.
Je ne vois pas immédiatement pourquoi cela ne
fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une
attaque efficace quand e est de l'ordre de sqrt(n)
--
Il n'y a pas besoin d'être riche, il suffit d'avoir de l'argent
(Chambre de commerce de Palau)
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une attaque efficace quand e est de l'ordre de sqrt(n)
-- Il n'y a pas besoin d'être riche, il suffit d'avoir de l'argent (Chambre de commerce de Palau)
Francois Grieu
Dans l'article , Erwan David a écrit:
Francois Grieu écrivait :
Noter que plutôt que de maintenir n secret, on peut envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux niveaux de secret: un secret "faible" e, un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir de paires clair/chiffré et de n. Si e fuit, le déchiffrement (ou la génération de signature) reste non affecté.
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une attaque efficace quand e est de l'ordre de sqrt(n)
Au risque de paraitre idiot: qu'est-ce que "Le misc" ?
Oui il y a des attaques sur les variantes de RSA à d petit, mais elles présupposent que l'exposant e est public. Dans le cas que j'évoque, d est suposé secret et inutilisable pour celui qui cherche e ; donc je ne vois pas le danger à choisir e "assez petit" (je n'affirme rien).
Par contre, si on voulais symétriser d et e complètement, et faire que l'on ne puisse déduire e de d, alors effectivement il ne faut pas réduire la taille de e autant que je le propose.
François Grieu
Dans l'article <87mzmdck5e.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> a écrit:
Francois Grieu <fgrieu@francenet.fr> écrivait :
Noter que plutôt que de maintenir n secret, on peut
envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux
niveaux de secret: un secret "faible" e,
un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir
de paires clair/chiffré et de n. Si e fuit, le
déchiffrement (ou la génération de signature) reste
non affecté.
Je suis affirmatif que cela fonctionne avec un e
aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1,
et que les message chiffrés ou signés soient formattés
dans les règles de l'art.
Je ne vois pas immédiatement pourquoi cela ne
fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une
attaque efficace quand e est de l'ordre de sqrt(n)
Au risque de paraitre idiot: qu'est-ce que "Le misc" ?
Oui il y a des attaques sur les variantes de RSA à d petit,
mais elles présupposent que l'exposant e est public.
Dans le cas que j'évoque, d est suposé secret et inutilisable
pour celui qui cherche e ; donc je ne vois pas le danger à
choisir e "assez petit" (je n'affirme rien).
Par contre, si on voulais symétriser d et e complètement,
et faire que l'on ne puisse déduire e de d, alors effectivement
il ne faut pas réduire la taille de e autant que je le propose.
Noter que plutôt que de maintenir n secret, on peut envisager de choisir e secret.
On obtient un cryptosystème asymétrique à deux niveaux de secret: un secret "faible" e, un secret "fort" d; n peut être public.
On ne peut trouver ni e ni d (ni équivalent) à partir de paires clair/chiffré et de n. Si e fuit, le déchiffrement (ou la génération de signature) reste non affecté.
Je suis affirmatif que cela fonctionne avec un e aléatoire de la taille de n, pourvu que gcd(e, phi(n))=1, et que les message chiffrés ou signés soient formattés dans les règles de l'art. Je ne vois pas immédiatement pourquoi cela ne fonctionnerais pas si e est réduit à disons 160 bits.
Le dernier misc a un article (que je n'ai pas encore lu) sur une attaque efficace quand e est de l'ordre de sqrt(n)
Au risque de paraitre idiot: qu'est-ce que "Le misc" ?
Oui il y a des attaques sur les variantes de RSA à d petit, mais elles présupposent que l'exposant e est public. Dans le cas que j'évoque, d est suposé secret et inutilisable pour celui qui cherche e ; donc je ne vois pas le danger à choisir e "assez petit" (je n'affirme rien).
Par contre, si on voulais symétriser d et e complètement, et faire que l'on ne puisse déduire e de d, alors effectivement il ne faut pas réduire la taille de e autant que je le propose.
François Grieu
Erwan David
Francois Grieu écrivait :
Le dernier misc a un article (que je n'ai pas encore lu) sur une attaque efficace quand e est de l'ordre de sqrt(n)
Au risque de paraitre idiot: qu'est-ce que "Le misc" ?
"MISC" c'est une revue de sécurité.
-- Il n'y a pas besoin d'être riche, il suffit d'avoir de l'argent (Chambre de commerce de Palau)
Francois Grieu <fgrieu@francenet.fr> écrivait :
Le dernier misc a un article (que je n'ai pas encore lu) sur une
attaque efficace quand e est de l'ordre de sqrt(n)
Au risque de paraitre idiot: qu'est-ce que "Le misc" ?
"MISC" c'est une revue de sécurité.
--
Il n'y a pas besoin d'être riche, il suffit d'avoir de l'argent
(Chambre de commerce de Palau)
