Confiance en AES

pornin

18/10/2003 à 15:16

According to Jean-Marc Desperrier :

Il y a des gens qui ont appliqué ce raisonnement sur le DES, et tenté de
changer les paramètres pour obtenir une version pas truquée par la NSA.
Et effectivement la NSA avait de meilleurs chercheurs.

Oui mais non. DES n'a pas été modifié par la NSA. La NSA a inspecté le
design et simplement constaté que les gars d'IBM en savaient déjà au
moins autant qu'eux. C'est IBM qui avait les meilleurs chercheurs.

--Thomas Pornin

Pierre Vandevenne

18/10/2003 à 22:12

Francois Grieu wrote in
news::

Un test expérimental détectant un biais quelconque dans TwoFish ?
Ou ce qui revient au même capable de le distinguer de Rijndael ?
Vraiment ??

Je cite, c'est direct du NIST (je suis sur que tu trouveras sur Google),
il y a une PDF à l'intention des "pros" qui va plus dans le détail, ceci
c'est l'executive summary.

Ton interprétation sera surement meilleure que la mienne, mais en lisant
le PDF, j'ai eu a nette impression que d'autres candidats avaient été
écartés pour des problèmes équivalents.

TWOFISH

Random Plaintext/Random 128-Bit Keys: Preliminary analysis suggests a
problem
given an excessive number of visits to the state x = +9 in the
random excursions

variant test. In this instance there were 4 rejections out of the
83 sequences processed

when the expected number should not exceed 3.

(b) Low Density Plaintext: Preliminary analysis seems to indicate
sensitivity to the

cumulative sums forward test. The total number of rejections was
7, which represents

over 5% of the sample. The expected number of rejections should
not exceed 4.

Pierre Vandevenne

18/10/2003 à 22:21

"AMcD" wrote in
news:3f902675$0$10410$:

Ouais. Celà dit, pour percer un système, une entreprise usant Windows
(ou quoi que ce soit d'autre),

Donc tout.

j'userai quand même plutôt de social engineering.

Pour obtenir mon mot de passe sur le serveur X, oui.

Stratégiquement, cela ne marche pas.

Cela étant, je discerne la faille volontaire de la faille heu, due au
processus industriel ;o). La première c'est l'éditeur du soft qui
cherche à te coincer. Là seconde, elle profite plutôt à ses clients.

C'est une propriété intrinsèque du processus de développement logiciel
actuel.

Francois Grieu

19/10/2003 à 11:46

Dans l'article ,
Pierre Vandevenne dit:

Je cite, c'est direct du NIST (tu trouveras sur Google)
"Preliminary analysis (of TwoFish) suggests a problem"

Oui merci pour les extrait, j'ai trouvé ces rapports sur
<http://csrc.nist.gov/rng/rng5.html>
dont celui cité, daté 9/1999. Il est conclu que HPC est de la daube
(c'est déjà un beau succès pour ces tests), et qu'il a été rencontré
pour Twofish et RC6 des anomalies qui méritent contrôle sur plus de
données; le ton est très réservé (cf avant dernier paragraphe des
conclusions). D'ailleurs TwoFish n'a pas été éliminé, et le papier
suivant, daté 4/2000, a repris la même analyse avec plus de données,
et conclu: "the 12 rejections obtained from the original experiment
could be considered as an anomaly".

Pour ma part, j'interprète ces résultats de la façon suivante: il a
été effectué plusieur centaines de tests, apparemment avec un seuil
de confiance de l'ordre de 0,01, et SANS refaire sur d'autres
données les tests ayant donné un résultat positif. Il est donc normal
que plusieurs tests signalent une anomalie même en l'absence de
phénomène anormal. Par ailleurs, sur tant de méthodes de test, il a
pu se glisser des erreurs.

Aussi, ma position est que ce genre de test "en boite noire" d'un
algorithme ne peut espérer détecter que des problèmes majeurs;
de même que le test automatisé d'un programme (de portée plus
générale qu'un algorithme de chiffrement) en observant le résultat
de son exécution ne peut espérer détecter que les failles de sécurité
les plus béantes (au contraire de tests interractifs, de l'étude de
l'exécutable, du source, ou de l'analyse interne).
Une meilleure méthodologie (je n'ai pas dit sure) consiste a observer
les résultat intermédiaires. Cette analyse est l'essentiel du second
rapport. Elle conclu que TwoFish est indistinguable du hasard pour
les 189 (!) tests statistiques pratiqués, et ce dès le 2ème round.
[La encore Twofish n'a pas eu de chance puisqu'il a été relevé une
anomalie au 8ème round (bien que théoriquement, il soit inconcevable
que rajouter des rounds permette a un test empirique de mieux s'y
retrouver); le rapport note que l'analyse a révélé que le seuil a
appliquer avait été calculé de manière exagérément simplifiée, et
qu'il n'y a en fait pas d'anomalie]

Bref, Twofish a été un moment soupçonné par les tests statistiques
du NIST, mais tout indique que ç'est par pur hasard et/ou la faute
des tests. TwoFish est officiellement lavé de tout soupçon. Surtout,
il a été par ailleurs l'objet de tentatives d'attaque développées
sur mesure, bien plus fines que ces tests statistiques d'usage
général, et personne n'a rien rapporté de probant.

François Grieu

Dans l'article <Xns9418E1FF7B64pierredatarescuebe@195.238.3.180>,
Pierre Vandevenne <pierre@datarescue.be> dit:

Je cite, c'est direct du NIST (tu trouveras sur Google)
"Preliminary analysis (of TwoFish) suggests a problem"

Oui merci pour les extrait, j'ai trouvé ces rapports sur
<http://csrc.nist.gov/rng/rng5.html>
dont celui cité, daté 9/1999. Il est conclu que HPC est de la daube
(c'est déjà un beau succès pour ces tests), et qu'il a été rencontré
pour Twofish et RC6 des anomalies qui méritent contrôle sur plus de
données; le ton est très réservé (cf avant dernier paragraphe des
conclusions). D'ailleurs TwoFish n'a pas été éliminé, et le papier
suivant, daté 4/2000, a repris la même analyse avec plus de données,
et conclu: "the 12 rejections obtained from the original experiment
could be considered as an anomaly".

Pour ma part, j'interprète ces résultats de la façon suivante: il a
été effectué plusieur centaines de tests, apparemment avec un seuil
de confiance de l'ordre de 0,01, et SANS refaire sur d'autres
données les tests ayant donné un résultat positif. Il est donc normal
que plusieurs tests signalent une anomalie même en l'absence de
phénomène anormal. Par ailleurs, sur tant de méthodes de test, il a
pu se glisser des erreurs.

Aussi, ma position est que ce genre de test "en boite noire" d'un
algorithme ne peut espérer détecter que des problèmes majeurs;
de même que le test automatisé d'un programme (de portée plus
générale qu'un algorithme de chiffrement) en observant le résultat
de son exécution ne peut espérer détecter que les failles de sécurité
les plus béantes (au contraire de tests interractifs, de l'étude de
l'exécutable, du source, ou de l'analyse interne).
Une meilleure méthodologie (je n'ai pas dit sure) consiste a observer
les résultat intermédiaires. Cette analyse est l'essentiel du second
rapport. Elle conclu que TwoFish est indistinguable du hasard pour
les 189 (!) tests statistiques pratiqués, et ce dès le 2ème round.
[La encore Twofish n'a pas eu de chance puisqu'il a été relevé une
anomalie au 8ème round (bien que théoriquement, il soit inconcevable
que rajouter des rounds permette a un test empirique de mieux s'y
retrouver); le rapport note que l'analyse a révélé que le seuil a
appliquer avait été calculé de manière exagérément simplifiée, et
qu'il n'y a en fait pas d'anomalie]

Bref, Twofish a été un moment soupçonné par les tests statistiques
du NIST, mais tout indique que ç'est par pur hasard et/ou la faute
des tests. TwoFish est officiellement lavé de tout soupçon. Surtout,
il a été par ailleurs l'objet de tentatives d'attaque développées
sur mesure, bien plus fines que ces tests statistiques d'usage
général, et personne n'a rien rapporté de probant.

François Grieu

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article ,
Pierre Vandevenne dit:

Je cite, c'est direct du NIST (tu trouveras sur Google)
"Preliminary analysis (of TwoFish) suggests a problem"

Oui merci pour les extrait, j'ai trouvé ces rapports sur
<http://csrc.nist.gov/rng/rng5.html>
dont celui cité, daté 9/1999. Il est conclu que HPC est de la daube
(c'est déjà un beau succès pour ces tests), et qu'il a été rencontré
pour Twofish et RC6 des anomalies qui méritent contrôle sur plus de
données; le ton est très réservé (cf avant dernier paragraphe des
conclusions). D'ailleurs TwoFish n'a pas été éliminé, et le papier
suivant, daté 4/2000, a repris la même analyse avec plus de données,
et conclu: "the 12 rejections obtained from the original experiment
could be considered as an anomaly".

Pour ma part, j'interprète ces résultats de la façon suivante: il a
été effectué plusieur centaines de tests, apparemment avec un seuil
de confiance de l'ordre de 0,01, et SANS refaire sur d'autres
données les tests ayant donné un résultat positif. Il est donc normal
que plusieurs tests signalent une anomalie même en l'absence de
phénomène anormal. Par ailleurs, sur tant de méthodes de test, il a
pu se glisser des erreurs.

Aussi, ma position est que ce genre de test "en boite noire" d'un
algorithme ne peut espérer détecter que des problèmes majeurs;
de même que le test automatisé d'un programme (de portée plus
générale qu'un algorithme de chiffrement) en observant le résultat
de son exécution ne peut espérer détecter que les failles de sécurité
les plus béantes (au contraire de tests interractifs, de l'étude de
l'exécutable, du source, ou de l'analyse interne).
Une meilleure méthodologie (je n'ai pas dit sure) consiste a observer
les résultat intermédiaires. Cette analyse est l'essentiel du second
rapport. Elle conclu que TwoFish est indistinguable du hasard pour
les 189 (!) tests statistiques pratiqués, et ce dès le 2ème round.
[La encore Twofish n'a pas eu de chance puisqu'il a été relevé une
anomalie au 8ème round (bien que théoriquement, il soit inconcevable
que rajouter des rounds permette a un test empirique de mieux s'y
retrouver); le rapport note que l'analyse a révélé que le seuil a
appliquer avait été calculé de manière exagérément simplifiée, et
qu'il n'y a en fait pas d'anomalie]

Bref, Twofish a été un moment soupçonné par les tests statistiques
du NIST, mais tout indique que ç'est par pur hasard et/ou la faute
des tests. TwoFish est officiellement lavé de tout soupçon. Surtout,
il a été par ailleurs l'objet de tentatives d'attaque développées
sur mesure, bien plus fines que ces tests statistiques d'usage
général, et personne n'a rien rapporté de probant.

François Grieu

Eric Razny

19/10/2003 à 18:47

"Emile Musyck" a écrit dans le message de
news:3f93fb13$0$3671$

D'abord :

si d'une
part on connaît une des deux clefs, on peut calculer la clef conjuguée, ce

Puis :

On pourrait croire à première vue que l'existence de deux clefs
différentes de l'algorithme constitue un handicap, mais, utilisé tel quel
dans le logiciel Classicsys, il se révèle être un plus, au point de vue
sécurité.

Je dois avouer que je n'ai pas eu le temps d'entrer dans les détails mais
ces deux extraits du post me paraissent curieux mis bout à bout.
En quoi "l'existence de deux clefs différentes" pourraient impliquer (ou
plus précisement se réveler) "un plus, au point de vue sécurité" quand
lesdites clefs se calculent l'une à partir de l'autre?

Eric.

Emile Musyck

20/10/2003 à 17:14

"Jean-Marc Desperrier" a écrit dans le message de
news: bmov6j$i4p$

Pierre Vandevenne wrote:
(Thomas Pornin) wrote in
news:bmol38$sbi$:

Cela dit, il n'y aurait rien d'illégitime à décider d'implémenter plutôt
que l'algo retenu par la méchante NSA (après un vote publique qui avait
favorisé le même algo) un des concurrents de rinjdael au concours AES,
un des ceux qui restaient présents dans la dernière phase de sélection,
qui ont reçu autant d'attention que rinjdael dans leur analyse, et qui
étaient aussi convaincants : Serpent, TwoFish ou MARS.
RC6 est à exclure pour des questions de droits, ceux-précités sont
libres d'utilisation.

En naviguant sur internet, j'ai pris connaissance tout récemment du news
group fr.misc.cryptologie et je marque un certain intérêt à lire les
échanges d'idées. Il est très louable de rechercher le meilleur des
algorithmes de chiffrement. Les plus connus parmi les freewares sont les
Rijndeal,
Twofish, Mars ou Serpent.

Je me permets de signaler aussi l'existence de l'algorithme SED (free)
dont je suis l'inventeur. En fait cet algorithme a été présenté à l'AES mais
retiré quelques jours avant la date limite d'acceptation car cet algorithme
n'est pas, à proprement parlé, un algorithme symétrique, en effet, il
utilise des clefs de chiffrement et de déchiffrement différentes et de ce
fait, certaines exigences de l'AES n'étaient pas remplies. Devrait-on le
classer parmi les asymétriques, la question est discutable car, si d'une
part on connaît une des deux clefs, on peut calculer la clef conjuguée, ce
serait dès lors un algorithme à clef privée, mais d'autre part d'un point de
vue fonctionnel, il se raccroche par ses structures aux algorithmes
asymétriques qui opèrent dans des groupes multiplicatifs. Je le qualifierais
d'algorithme asymétrique à clefs privées.

La version précédente du SED (1998), qui comprenait deux exponentiations
(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a conclu à
la possibilité de recalculer la clef en effectuant 2^64 tests sur la boîte
noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Les algorithmes RSA et SED présentent certaines similitudes. Tout deux
procèdent dans des groupes multiplicatifs cycliques. Le facteur
multiplicatif pour le RSA se compose d'un nombre entier qui effectue une
multiplication arithmétique modulaire tandis que pour le SED, le facteur est
une matrice carrée modulo-2 (127*127). Cependant, par d'autres aspects, le
SED offre aussi des similitudes avec les algorithmes symétriques. L'espace
des
clefs et des données correspond à la dimension 2^127, de plus la vitesse de
calcul est d'un même ordre de grandeur, alors que pour le RSA, la vitesse de
chiffrement est 1000 fois plus faible.

On pourrait croire à première vue que l'existence de deux clefs
différentes de l'algorithme constitue un handicap, mais, utilisé tel quel
dans le logiciel Classicsys, il se révèle être un plus, au point de vue
sécurité.

Vous trouvez sur le site www.ulb.ac.be/di/scsi/classicsys/ quelques
explications et des fichiers ou logiciels à télécharger;
classicdemo.exe -qui permet de chiffrer et déchiffrer en
introduisant clefs, data et XOR.
classicdemosource.zip -le fichier opensource qui a servi à réaliser
ClassicDemo;
A cryptosystem based on double discrete logaritm - Mieczislaw Kula
ClassicTit.zip - logiciel de Classicsys pour l'envoi et la réception
des mails chiffrés
classicvite.zip - logiciel pour le calcul de la vitesse de
chiffrement.

Je suis collaborateur scientifique à l'Université Libre de Bruxelles
(activité bénévole) et suis tout disposé à répondre à vos questions.

Emile Musyck
www.ulb.ac.be/di/scsi/emusyck

"Jean-Marc Desperrier" <jmdesp@alussinan.org> a écrit dans le message de
news: bmov6j$i4p$1@reader1.imaginet.fr...

Pierre Vandevenne wrote:

pornin@nerim.net (Thomas Pornin) wrote in
news:bmol38$sbi$1@biggoron.nerim.net:

Cela dit, il n'y aurait rien d'illégitime à décider d'implémenter plutôt
que l'algo retenu par la méchante NSA (après un vote publique qui avait
favorisé le même algo) un des concurrents de rinjdael au concours AES,
un des ceux qui restaient présents dans la dernière phase de sélection,
qui ont reçu autant d'attention que rinjdael dans leur analyse, et qui
étaient aussi convaincants : Serpent, TwoFish ou MARS.
RC6 est à exclure pour des questions de droits, ceux-précités sont
libres d'utilisation.

En naviguant sur internet, j'ai pris connaissance tout récemment du news
group fr.misc.cryptologie et je marque un certain intérêt à lire les
échanges d'idées. Il est très louable de rechercher le meilleur des
algorithmes de chiffrement. Les plus connus parmi les freewares sont les
Rijndeal,
Twofish, Mars ou Serpent.

Je me permets de signaler aussi l'existence de l'algorithme SED (free)
dont je suis l'inventeur. En fait cet algorithme a été présenté à l'AES mais
retiré quelques jours avant la date limite d'acceptation car cet algorithme
n'est pas, à proprement parlé, un algorithme symétrique, en effet, il
utilise des clefs de chiffrement et de déchiffrement différentes et de ce
fait, certaines exigences de l'AES n'étaient pas remplies. Devrait-on le
classer parmi les asymétriques, la question est discutable car, si d'une
part on connaît une des deux clefs, on peut calculer la clef conjuguée, ce
serait dès lors un algorithme à clef privée, mais d'autre part d'un point de
vue fonctionnel, il se raccroche par ses structures aux algorithmes
asymétriques qui opèrent dans des groupes multiplicatifs. Je le qualifierais
d'algorithme asymétrique à clefs privées.

La version précédente du SED (1998), qui comprenait deux exponentiations
(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a conclu à
la possibilité de recalculer la clef en effectuant 2^64 tests sur la boîte
noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Les algorithmes RSA et SED présentent certaines similitudes. Tout deux
procèdent dans des groupes multiplicatifs cycliques. Le facteur
multiplicatif pour le RSA se compose d'un nombre entier qui effectue une
multiplication arithmétique modulaire tandis que pour le SED, le facteur est
une matrice carrée modulo-2 (127*127). Cependant, par d'autres aspects, le
SED offre aussi des similitudes avec les algorithmes symétriques. L'espace
des
clefs et des données correspond à la dimension 2^127, de plus la vitesse de
calcul est d'un même ordre de grandeur, alors que pour le RSA, la vitesse de
chiffrement est 1000 fois plus faible.

On pourrait croire à première vue que l'existence de deux clefs
différentes de l'algorithme constitue un handicap, mais, utilisé tel quel
dans le logiciel Classicsys, il se révèle être un plus, au point de vue
sécurité.

Vous trouvez sur le site www.ulb.ac.be/di/scsi/classicsys/ quelques
explications et des fichiers ou logiciels à télécharger;
classicdemo.exe -qui permet de chiffrer et déchiffrer en
introduisant clefs, data et XOR.
classicdemosource.zip -le fichier opensource qui a servi à réaliser
ClassicDemo;
A cryptosystem based on double discrete logaritm - Mieczislaw Kula
ClassicTit.zip - logiciel de Classicsys pour l'envoi et la réception
des mails chiffrés
classicvite.zip - logiciel pour le calcul de la vitesse de
chiffrement.

Je suis collaborateur scientifique à l'Université Libre de Bruxelles
(activité bénévole) et suis tout disposé à répondre à vos questions.

Emile Musyck emilemusyck@skynet.be
www.ulb.ac.be/di/scsi/emusyck

Vous avez filtré cet utilisateur ! Consultez son message

"Jean-Marc Desperrier" a écrit dans le message de
news: bmov6j$i4p$

Pierre Vandevenne wrote:
(Thomas Pornin) wrote in
news:bmol38$sbi$:

Cela dit, il n'y aurait rien d'illégitime à décider d'implémenter plutôt
que l'algo retenu par la méchante NSA (après un vote publique qui avait
favorisé le même algo) un des concurrents de rinjdael au concours AES,
un des ceux qui restaient présents dans la dernière phase de sélection,
qui ont reçu autant d'attention que rinjdael dans leur analyse, et qui
étaient aussi convaincants : Serpent, TwoFish ou MARS.
RC6 est à exclure pour des questions de droits, ceux-précités sont
libres d'utilisation.

En naviguant sur internet, j'ai pris connaissance tout récemment du news
group fr.misc.cryptologie et je marque un certain intérêt à lire les
échanges d'idées. Il est très louable de rechercher le meilleur des
algorithmes de chiffrement. Les plus connus parmi les freewares sont les
Rijndeal,
Twofish, Mars ou Serpent.

Je me permets de signaler aussi l'existence de l'algorithme SED (free)
dont je suis l'inventeur. En fait cet algorithme a été présenté à l'AES mais
retiré quelques jours avant la date limite d'acceptation car cet algorithme
n'est pas, à proprement parlé, un algorithme symétrique, en effet, il
utilise des clefs de chiffrement et de déchiffrement différentes et de ce
fait, certaines exigences de l'AES n'étaient pas remplies. Devrait-on le
classer parmi les asymétriques, la question est discutable car, si d'une
part on connaît une des deux clefs, on peut calculer la clef conjuguée, ce
serait dès lors un algorithme à clef privée, mais d'autre part d'un point de
vue fonctionnel, il se raccroche par ses structures aux algorithmes
asymétriques qui opèrent dans des groupes multiplicatifs. Je le qualifierais
d'algorithme asymétrique à clefs privées.

La version précédente du SED (1998), qui comprenait deux exponentiations
(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a conclu à
la possibilité de recalculer la clef en effectuant 2^64 tests sur la boîte
noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Les algorithmes RSA et SED présentent certaines similitudes. Tout deux
procèdent dans des groupes multiplicatifs cycliques. Le facteur
multiplicatif pour le RSA se compose d'un nombre entier qui effectue une
multiplication arithmétique modulaire tandis que pour le SED, le facteur est
une matrice carrée modulo-2 (127*127). Cependant, par d'autres aspects, le
SED offre aussi des similitudes avec les algorithmes symétriques. L'espace
des
clefs et des données correspond à la dimension 2^127, de plus la vitesse de
calcul est d'un même ordre de grandeur, alors que pour le RSA, la vitesse de
chiffrement est 1000 fois plus faible.

On pourrait croire à première vue que l'existence de deux clefs
différentes de l'algorithme constitue un handicap, mais, utilisé tel quel
dans le logiciel Classicsys, il se révèle être un plus, au point de vue
sécurité.

Vous trouvez sur le site www.ulb.ac.be/di/scsi/classicsys/ quelques
explications et des fichiers ou logiciels à télécharger;
classicdemo.exe -qui permet de chiffrer et déchiffrer en
introduisant clefs, data et XOR.
classicdemosource.zip -le fichier opensource qui a servi à réaliser
ClassicDemo;
A cryptosystem based on double discrete logaritm - Mieczislaw Kula
ClassicTit.zip - logiciel de Classicsys pour l'envoi et la réception
des mails chiffrés
classicvite.zip - logiciel pour le calcul de la vitesse de
chiffrement.

Je suis collaborateur scientifique à l'Université Libre de Bruxelles
(activité bénévole) et suis tout disposé à répondre à vos questions.

Emile Musyck
www.ulb.ac.be/di/scsi/emusyck

Xavier Roche

20/10/2003 à 18:24

Emile Musyck wrote:

La version précédente du SED (1998), qui comprenait deux exponentiations
(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a conclu à
la possibilité de recalculer la clef en effectuant 2^64 tests sur la boîte
noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Oui, car dans le cas de "RSA for paranoïds" (Shamir, il me semble), les
petits ajouts pour sécuriser un peu plus RSA l'avait rendu.. plus faible.

Donc, oui, méfiance :)

Emile Musyck

20/10/2003 à 23:26

"Xavier Roche" a écrit dans le message de
news: bn127m$d7q$

Emile Musyck wrote:
La version précédente du SED (1998), qui comprenait deux
exponentiations

(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a
conclu à

la possibilité de recalculer la clef en effectuant 2^64 tests sur la
boîte

noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Oui, car dans le cas de "RSA for paranoïds" (Shamir, il me semble), les
petits ajouts pour sécuriser un peu plus RSA l'avait rendu.. plus faible.

Donc, oui, méfiance :)
Faut-il être méfiant par principe ou plutôt essayer de comprendre le

raisonnement de Kula et voir dans quelle mesure l'introduction de
l'application MAM pourrait être plutôt néfaste que constructive.
Je m'explique: supposons le cas d'un opposant qui recherche à recalculer
la clef en connaissant un grand nombre de couples textes clair et chiffré
dans l'ancienne version du SED (1998). Ces données sont en fait des
exponentielles dans des corps finis dont il est possible de calculer les
logarithmes discrets exprimés dans des bases logarithmiques différentes.
Avec une probabilité très faible (<2 exp -64), la clef peut être révélée par
suite d'une relation d'isomorphisme liant textes clair et chiffré. En
introduisant une application MAM entre les deux applications DLM (version
actuelle du SED), les textes clair et chiffré constituent toujours des
exponentielles dans les mêmes corps finis comme précédemment, mais
l'application MAM empêche d'établir les relations d'isomorphisme définies
par Kula.
L'étude de Kula "A cryptosystem based on double discrete logaritms" est
téléchargeable sur le site www.ulb.ac.be/di/scsi/classicsys/sed.htm
Bonne lecture

Emile

"Xavier Roche" <xroche@free.fr.NOSPAM.invalid> a écrit dans le message de
news: bn127m$d7q$1@s1.read.news.oleane.net...

Emile Musyck wrote:

La version précédente du SED (1998), qui comprenait deux
exponentiations

(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a
conclu à

la possibilité de recalculer la clef en effectuant 2^64 tests sur la
boîte

noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Oui, car dans le cas de "RSA for paranoïds" (Shamir, il me semble), les
petits ajouts pour sécuriser un peu plus RSA l'avait rendu.. plus faible.

Donc, oui, méfiance :)
Faut-il être méfiant par principe ou plutôt essayer de comprendre le

raisonnement de Kula et voir dans quelle mesure l'introduction de
l'application MAM pourrait être plutôt néfaste que constructive.
Je m'explique: supposons le cas d'un opposant qui recherche à recalculer
la clef en connaissant un grand nombre de couples textes clair et chiffré
dans l'ancienne version du SED (1998). Ces données sont en fait des
exponentielles dans des corps finis dont il est possible de calculer les
logarithmes discrets exprimés dans des bases logarithmiques différentes.
Avec une probabilité très faible (<2 exp -64), la clef peut être révélée par
suite d'une relation d'isomorphisme liant textes clair et chiffré. En
introduisant une application MAM entre les deux applications DLM (version
actuelle du SED), les textes clair et chiffré constituent toujours des
exponentielles dans les mêmes corps finis comme précédemment, mais
l'application MAM empêche d'établir les relations d'isomorphisme définies
par Kula.
L'étude de Kula "A cryptosystem based on double discrete logaritms" est
téléchargeable sur le site www.ulb.ac.be/di/scsi/classicsys/sed.htm
Bonne lecture

Emile

Vous avez filtré cet utilisateur ! Consultez son message

"Xavier Roche" a écrit dans le message de
news: bn127m$d7q$

Emile Musyck wrote:
La version précédente du SED (1998), qui comprenait deux
exponentiations

(DLM: Discrete Logaritms Multiplier) dans corps finis avec des bases
logarithmiques différentes, a été étudiée par Mieczislaw Kula qui a
conclu à

la possibilité de recalculer la clef en effectuant 2^64 tests sur la
boîte

noire contenant l'algorithme avec sa clef. Malgré ce nombre vertigineux,
j'ai introduit une multiplication arithmétique modulaire (MAM) entre les
deux DLM. Les hypothèses introduites par Kula n'étant plus d'application
dans la nouvelle version, tout porte à croire que l'algorithme doit être
très robuste, mais sait-on jamais...

Oui, car dans le cas de "RSA for paranoïds" (Shamir, il me semble), les
petits ajouts pour sécuriser un peu plus RSA l'avait rendu.. plus faible.

Donc, oui, méfiance :)
Faut-il être méfiant par principe ou plutôt essayer de comprendre le

raisonnement de Kula et voir dans quelle mesure l'introduction de
l'application MAM pourrait être plutôt néfaste que constructive.
Je m'explique: supposons le cas d'un opposant qui recherche à recalculer
la clef en connaissant un grand nombre de couples textes clair et chiffré
dans l'ancienne version du SED (1998). Ces données sont en fait des
exponentielles dans des corps finis dont il est possible de calculer les
logarithmes discrets exprimés dans des bases logarithmiques différentes.
Avec une probabilité très faible (<2 exp -64), la clef peut être révélée par
suite d'une relation d'isomorphisme liant textes clair et chiffré. En
introduisant une application MAM entre les deux applications DLM (version
actuelle du SED), les textes clair et chiffré constituent toujours des
exponentielles dans les mêmes corps finis comme précédemment, mais
l'application MAM empêche d'établir les relations d'isomorphisme définies
par Kula.
L'étude de Kula "A cryptosystem based on double discrete logaritms" est
téléchargeable sur le site www.ulb.ac.be/di/scsi/classicsys/sed.htm
Bonne lecture

Emile

Eric Pommateau

24/10/2003 à 18:44

Bonjour,

On Sat, 18 Oct 2003 13:16:52 +0000, Thomas Pornin wrote:

Oui mais non. DES n'a pas été modifié par la NSA. La NSA a inspecté le
design et simplement constaté que les gars d'IBM en savaient déjà au
moins autant qu'eux. C'est IBM qui avait les meilleurs chercheurs.

Il me semblait avoir lu dans le livre de Schneir que le DES était une
modification de Lucifer où la NSA avait :
1) divisé la taille de la clé par deux
2) modifier les S-Box pour que le tous soit résistant à
la cryptanalyse différentielle.

me serais-je trompé ?

--
Eric Pommateau

Pierre Vandevenne

24/10/2003 à 19:22

Eric Pommateau wrote in
news::

Bonjour,

On Sat, 18 Oct 2003 13:16:52 +0000, Thomas Pornin wrote:

Oui mais non. DES n'a pas été modifié par la NSA. La NSA a inspecté le
design et simplement constaté que les gars d'IBM en savaient déjà au
moins autant qu'eux. C'est IBM qui avait les meilleurs chercheurs.

Il me semblait avoir lu dans le livre de Schneir que le DES était une
modification de Lucifer où la NSA avait :
1) divisé la taille de la clé par deux
2) modifier les S-Box pour que le tous soit résistant à
la cryptanalyse différentielle.

me serais-je trompé ?

On peut jouer sur les mots en disant que l'algorithme n'a pas été modifié,
mais bien ses paramètres.

http://www.im.ntu.edu.tw/IM/Faculty/tsay/courses/is/Coppersmith1994.htm

Coppersmith affirme que la cryptanlyse différentielle était "well known"
d'IBM en 1974 mais aussi que "The National Security Agency (NSA) also
provided technical advice to IBM."

Comme Coppersmith (et les autres membres de l'équipe n'on ps touché mot de
la cryptanlyse différentielle) beaucoup de gens pensent que la NSA leur a
soufflé la réponse.

C'est ce que semblait penser Thomas Pornin en 2000, je le cite...

---
From: (Thomas Pornin)
Subject: Re: My Theory...
Date: 4 Oct 2000 10:10:19 GMT

<snip>

The NSA did bet, 25 years ago, on the fact that they could build a
DES-cracker before anyone else. On the other hand, they strengthened
DES with regards to other cryptanalysis, so that only brute-force would
be practical.

<snip>

On dirait qu'il a changé d'avis... ;-)

Confiance en AES

10 réponses

Veuillez sélectionner un problème