>Tout cela est lourd mais c'est la seule solution pour un maximum de transparence. >Toutes ces données seront mise sur ma page le 18/06.
ok
>En final, je ne peux pas être plus honnête et transparent dans ma démarche.
ok pour la transparance.
L'ennui c'est que pour reproduire exactement l'attaque avec les même graine, il m'aurai fallu en effet faire les 100 cryptanalyses sur la même machine.
Je suis partie du principe que l'attaque doit marcher quelque soit le seed (tu en conviendra), mais c'est vrai que ca ne reproduit pas parfaitement le code donné sur ton site.
>C'est pourquoi je "coince" un peu. >Ce n'est pas comme cela que l'on saura.
certe,
je te comprends.
>Que mon code source soit lui-même examiné.
si ca peu aider, j'ai lu une remarque interessante à ce sujet sur sci.crypt:
>Personne ne sera assez idiot pour conserver une clef sur 2ドル^{31}$ blocs.
et ben si justement,
c'est pourquoi je suis autant interessée par la "veracité" du résultat.
Les algo de chiffrement par block comme l'AES (ou ses copains) ne sont pas exclusivement utilisé pour le chiffrement.
Prends par exemple un protocole tout con d'authentification sur une carte à puce (c'est très simplifié dans mon exemple):
une carte dispose d'une clé secrete que le verifieur connait.
pour vérifier qu'il cause à la bonne carte, le verifieur envoie un challenge, cad un message aléatoire chiffré avec la clé que la carte va déchiffrer et véfrifie que la carte à utilisé la bonne clé.
içi, il ne s'agit plus de chiffrer des données
ce type de protocole permet à un attaquant d'obtenir autant de couples claire chiffré qu'il le souhaite.
bien sur tu va me dire que l'a carte n'est pas assez rapide pour me sortire 2^31 chifferements en un temps réaliste ou bien que je n'ai qu'a implementer un compteur .... tout comme on me répondait tout à l'heure que je n'avais qu'a compresser mon texte à chiffrer.
Il n'en reste pas moins que le choix de l'algo pour ce type de protocole se fait en fonction de critères très stricts, comme par exemple la resistance à la cryptanalyse à clair ou chiffré connu.
Et quand je dis résistance, je pense complexité équivalente à une attaque en brute force.
C'est pourquoi on ne peu se satisfaire d'arguments de sécurité comme :
->2^31 c'est beaucoup quand même...
->il suffit de compresser ses messages...
...
-> il suffit de ne pas chiffrer les messages commencent par "a" aussi?
ca me rappelle cette fois les arguments d'un célèbre trolleur sur fr.misc.cryptologie...
les algo de chiffrement par blocks utilisés aujourd'hui sont conçu pour résister aux attaques à claire ou chiffrés connus.
or si il s'avère que ce n'est pas le cas, beaucoup de protocoles, courament utilisé aujourd'hui et dont la sécurité repose sur cette hypothese se retrouveront faibles.
C'est pourquoi je refuse de relativiser l'improtance du résulat !
j'attendrai donc le 18 avec impatience pour relancer mes petits calculs. Je te tiendrai informé des résultats si tu y tiens.
[^] # Re: [HS] C'était comment SSTIC ?
Posté par ODE . En réponse à la dépêche Inquiètude sur l'indépendance informatique du pays. Évalué à 2.
>Toutes ces données seront mise sur ma page le 18/06.
ok
>En final, je ne peux pas être plus honnête et transparent dans ma démarche.
ok pour la transparance.
L'ennui c'est que pour reproduire exactement l'attaque avec les même graine, il m'aurai fallu en effet faire les 100 cryptanalyses sur la même machine.
Je suis partie du principe que l'attaque doit marcher quelque soit le seed (tu en conviendra), mais c'est vrai que ca ne reproduit pas parfaitement le code donné sur ton site.
>C'est pourquoi je "coince" un peu.
>Ce n'est pas comme cela que l'on saura.
certe,
je te comprends.
>Que mon code source soit lui-même examiné.
si ca peu aider, j'ai lu une remarque interessante à ce sujet sur sci.crypt:
http://groups.google.fr/groups?q=Grieu+PDRC&hl=fr&lr=&i(...)
>Personne ne sera assez idiot pour conserver une clef sur 2ドル^{31}$ blocs.
et ben si justement,
c'est pourquoi je suis autant interessée par la "veracité" du résultat.
Les algo de chiffrement par block comme l'AES (ou ses copains) ne sont pas exclusivement utilisé pour le chiffrement.
Prends par exemple un protocole tout con d'authentification sur une carte à puce (c'est très simplifié dans mon exemple):
une carte dispose d'une clé secrete que le verifieur connait.
pour vérifier qu'il cause à la bonne carte, le verifieur envoie un challenge, cad un message aléatoire chiffré avec la clé que la carte va déchiffrer et véfrifie que la carte à utilisé la bonne clé.
içi, il ne s'agit plus de chiffrer des données
ce type de protocole permet à un attaquant d'obtenir autant de couples claire chiffré qu'il le souhaite.
bien sur tu va me dire que l'a carte n'est pas assez rapide pour me sortire 2^31 chifferements en un temps réaliste ou bien que je n'ai qu'a implementer un compteur .... tout comme on me répondait tout à l'heure que je n'avais qu'a compresser mon texte à chiffrer.
Il n'en reste pas moins que le choix de l'algo pour ce type de protocole se fait en fonction de critères très stricts, comme par exemple la resistance à la cryptanalyse à clair ou chiffré connu.
Et quand je dis résistance, je pense complexité équivalente à une attaque en brute force.
C'est pourquoi on ne peu se satisfaire d'arguments de sécurité comme :
->2^31 c'est beaucoup quand même...
->il suffit de compresser ses messages...
...
-> il suffit de ne pas chiffrer les messages commencent par "a" aussi?
ca me rappelle cette fois les arguments d'un célèbre trolleur sur fr.misc.cryptologie...
les algo de chiffrement par blocks utilisés aujourd'hui sont conçu pour résister aux attaques à claire ou chiffrés connus.
or si il s'avère que ce n'est pas le cas, beaucoup de protocoles, courament utilisé aujourd'hui et dont la sécurité repose sur cette hypothese se retrouveront faibles.
C'est pourquoi je refuse de relativiser l'improtance du résulat !
j'attendrai donc le 18 avec impatience pour relancer mes petits calculs. Je te tiendrai informé des résultats si tu y tiens.
ode