Le (on) jeudi 31 juillet 2008 16:50, Emile a écrit (wrote) :
> On 31 juil, 00:09, mpg <m...@elzevir.fr> wrote:
>>Donc en gros que quand on chiffre avec une clef de 128 bits avec SED,
>>c'est au mieux comme si on chiffrait avec un clé de 64 bits avec un bon
>>algo. C'est pas brillant. En fait, SED est censé avoir quoi de plus qu'un
>>bon vieil AES des familles ?
>
> Comment expliquer encore une fois de plus que le test des 2^64 steps
> de Kula qui permettrait de casser le SED, c'est de la foutaise de A à
> Z !!!
On va dire que ma phrase était à précéder d'un « d'après Kula », pour
essayer de ne pas prendre parti.
Mais tu ne réponds pas à ma deuxième question : en contrepartie, qu'est-ce
que SED est censé avoir de plus que AES ? Cette fameuse implémentation en
hardware ? Je ne suis pas spécialiste, mais je pense qu'AES en hardware, ça
doit exister aussi, non ?
J'ai bien compris l'intérêt que tu penses voir au reste de ton système
(autorité « de confiance » et tout), même si en tant que « consommateur »
de crypto elle correspond pas du tout à ma « demande », c'est un autre
débat. Bref, tu veux créer une architecture basée sur de la crypto
symétrique et un tiers qui détient et gère les clés (si je comprends
bien) : pourquoi ne pas utiliser un truc fiable et éprouvé comme AES pour
la partie chiffrage.
(Au passage, pour la partie « autorité centralisée de contrôle et gestion
des clés », sache que le concept n'est pas nouveau, et qu'il y a peut-être
de bonnes raisons pour qu'il n'ait pas été larguement adopté jusqu'à
présent.)
> Je n'ai pas su mettre le doigt sur l'erreur de Kula, je ne suis
> pas mathématicien de formation. Toutefois, je pense que les relations
> d'isomorphisme dont Kula fait état ne sont pas applicables pour
> évaluer le SED. L'avis d'un matheux serait souhaitable.
>
En tant que matheux, je n'ai pas le temps et sans doute pas les compétences
d'étudier l'article, mais je peux te dire par expérience que les articles
parus dans des revues avec comité de lecture ne sont pas si souvent bidons
et te conseiller de revoir tes propres calculs en essayant faire preuve de
beaucoup de rigueur.
>>En fait, SED est censé avoir quoi de plus qu'un bon
>>vieil AES des familles ?
>
Ah désolé pour ma remarque ci-dessus, je n'avais pas encore vu que tu
répondais plus bas. Pas habitué à ta façon de double-citer, mais c'est pas
grave :-)
> Le DES et l'AES doivent être considérés comme étant des algorithmes
> de première et de deuxième génération. [...]
Donc si je comprends bien ton idée est que SED est plus résistant à la
cryptanalyse linéaire et différentielle (et probablement plus résitant en
général) que les algos classiques comme AES ?
Si je peux me permettre, d'une part je ne suis pas sûr qu'il y ait besoin de
ça pour les applications que tu considères : à tort ou à raison, j'estime
mes mails privés suffisamment protégés par de l'AES-256 actuellement.
D'autre part, le mieux est souvent l'ennemi du bien, et si ton algo est
vraiment intéressant ou pas, on ne le saura qu'après pas mal de temps, s'il
résiste aux différentes attaques que les gens essayeront éventuellement
d'inventer contre lui. En crypto, il faut mieux rester sur des trucs
classiques donc bien éprouvés que de se jeter sur la dernière nouveauté.
>>Mettre en place une expérience pour casser en 2^{64} opérations un
>>clé SED de 128 bits, mine de rien ça doit prendre du temps et des
>>ressources et si personne ne le fait, c'est peut-être parce que ça n'en
>>vaut pas la peine.
>
> Faut-il encore rappeler que les 2^64 opérations de Kula qui pourrait
> casser le SED, c'est de la foutaise. Si le test de Kula n'a pas pu
> fonctionner avec 7 bits, contrairement à ce que l'auteur prétend, le
> test des 2^64 opérations ne fonctionnera non plus.
>
Ah non, là je t'arrête. Tu demandais toi-même qu'on fasse l'expérience comme
façon décisive de voir qui avait raison, ne viens pas dire après que ça
sert à rien parce que de toutes façons c'est toi qui a raison !
> avoir entre un RSA qui permet des petits et des grands nombres et le
> SED qui n'aurait pas cette possibilité. La réduction du SED avec n=17
> bits confirme en mieux les résultats déjà obtenus avec n=7.
>
Bah déjà RSA c'est de l'asymétrique et SED du symétrique, on vit pas dans le
même monde. Et puis qu'est-ce que tu entends par « fonctionne » ? C'est
tout le problème en crypto : on ne peut pas « voir » qu'un truc est bon. On
peut juste voir qu'il n'était pas bon, après coup, quand on l'a cassé, ou
au contraire croire qu'il n'est pas si mauvais, quand au bout de pas mal
d'années ont est toujours bien loin de l'avoir cassé.
> L'avantage premier du chiffrement généralisé pour la messagerie
> électronique est certes la confidentialité, mais il y a un autre
> avantage tout aussi important, c'est la possibilité d'une vérification
> de l'origine du message. Si l'Organisme de Confiance applique la
> consigne d'attribuer des clefs de session qu'aux correspondants
> enregistrés, on pourrait de cette manière éradiquer tous les virus et
> spams.
>
Oui, mais ça ça n'a rien à voir avec la comparaison de SED avec d'autres
alog de chiffrement. C'est une question de choix d'infrastructure,
ton « Organisme de Confiance », AES ou SED c'est un moyen (plus ou moins
bon) de mettre en oeuvre cette infrastructure (ou d'autres).
Manuel.