fll a écrit 3 commentaires

  • [^] # Re: [HS] C'était comment SSTIC ?

    Posté par  . En réponse à la dépêche Inquiètude sur l'indépendance informatique du pays. Évalué à 2.

    OK je suis intéressé par toute personne qui pourra refaire l'expérience. Bien sur la contribution de ces personnes sera mentionnée chaque fois que j'en aurai l'occasion. J'indiquerai comment faire sur ma page.

    Pour la remarque de Grieu, elle est correcte et en fait je me suis aperçu que la version (pas encore changée) de l'algo d'attaque sur ma page n'est pas la bonne mais une version temporaire, dans laquelle je testai un autre seuil. Effectivement, ce seuil n'est pas le bon. Cela a été corrigé depuis et les 200 cryptanalyses utilisent le bon seuil. Je reconnais que cela a pu embrouiller les gens qui ont tenté de refaire l'expérience. Tout cela sera actualisé le 18.
    D'où à mon sens l'importance de publier le code source car cela permet la vérification par des tiers.

    Il faut savoir que d'autres algorithmes par blocs sont tombés (en fait 12 sur les 15 candidats AES), ce que j'expliquai lors de la présentation à SSTIC (au passage, il s'agissait d'une conf de sauvetage, elle ne figure pas dans les actes). Mais avant de publier quoi que ce soit, il faut d'abord confirmer les résultats de l'AES.

    Quoi qu'il en soit merci pour ta proposition, ton aide, ainsi que tous ceux qui m'ont aidé par leurs critiques constructives (si si ,il y en a eu : Grieu, Coppersmith, Niederreiter,.....)

    Fll
  • [^] # Re: [HS] C'était comment SSTIC ?

    Posté par  . En réponse à la dépêche Inquiètude sur l'indépendance informatique du pays. Évalué à 4.

    Le choix du code C AES que j'ai choisi (version C non optimisée) a été motivé par le fait qu'il est plus facile de vérifier si il s'agit de la bonne implémentation (en particulier vérification des vecteurs de tests fournis par les concepteurs de l'AES). La version optimisée est si compliquée que le risque est grand de ne pas travailler sur la version correcte si elle n'est pas correctement implémentée.
    Je cherche avant tout à permettre sans trop d'effort une vérification par des tiers.

    Pour les expériences produites par les auteurs de 2003/022 (version C optimisée), les résultats sont inexploitables car non reproductibles (juste les résultats sans les valeurs de départ), pas de code source donné, rien qui permette de se faire véritable idée.
    Les 200 cryptanalyses ont été générées sur 2 PC, chacun d'entre eux ayant effectués 100 cryptanalyses en continu (cad une graine initiale générant 100 clefs, un générateur d'aléa différent pour le clair, chaque graine de clair étant sauvegardée; le choix de 100 clefs générées selon un processus continu à partir de la même graine est peut-être long mais il assure que je n'ai pas gardé les clefs intéressantes et rejeté celles qui ne confirmaient pas le résultat). 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.

    Concernant la portée du résultat, il faut relativiser. Personne ne sera assez idiot pour conserver une clef sur $2^{31}$ blocs. Aussi, si le résultat est intéressant (mais il est général et concerne tous les systèmes par blocs, pas seulement l'AES et là j'ai commis l'erreur de valider cette nouvelle cryptanalyse sur un algo encore trop "à la mode"; l'approche théorique est validée et à été acceptée pour publication) mais sans plus, car non opérationnel. J'attends que d'autres personnes refassent l'expérience pour confirmer mes résultats avec mes codes source
    et selon le même protocole (pour pouvoir comparer). Que mon code source soit lui-même examiné. Alors seulement on saura si je me suis trompé ou pas mais j'en doute; et je pourrai publier les autres équations trouvées.

    En particulier, la valeur exacte du biais des équations étant non connue (Vauban ne peut qu'indiquer son signe et s'il est non nul), il est nécessaire de refaire un grand nombre de fois 100 cryptanalyses pour avoir une idée de la moyenne du taux de succès. Si ce dernier reste (en moyenne) supérieur à 50 % alors cela confirme mes résultats. Mais il faut du temps.

    En final, je ne peux pas être plus honnête et transparent dans ma démarche. Or personne, ayant critiqué mes travaux n'a pris la peine d'adopter la même transparence et la même honneteté et de publier des résultats détaillés avec le code source. C'est pourquoi je "coince" un peu. Ce n'est pas comme cela que l'on saura.

    Fll
  • [^] # Re: [HS] C'était comment SSTIC ?

    Posté par  . En réponse à la dépêche Inquiètude sur l'indépendance informatique du pays. Évalué à 5.

    Bonjour,

    Quand vous dites que vous avez tenté (en vain) de reproduire cette attaque, vous avez donc (bien entendu) effectué 100 cryptanalyses complétes et constaté le taux de succès observé.
    Parce que si ce n'est pas le cas, désolé, vous ne pouvez rien dire.
    Je signale au passage que l'expérience (100 cryptanalyses) nécessite 3 mois de calcul sur un PC puissant.

    Je suis en peu fatigué de toutes ces personnes qui affirment tout et n'importe quoi sur un sujet qu'elles n'ont pas creusé. Les résultats détaillés de cette expérience (200 cryptanalyses qui confirment le résultat) réalisées selon un protocole extrêmement rigoureux, seront disponibles (clefs, graines aléatoires pour le clair et la clé, description du protocole expérimental,...) sur la page de l'auteur ainsi que les codes sources de cette attaque (en date du 18/06).
    La démarche de son auteur ne peut pas être plus transparente et bien des critiques (certaines agressives et scientifiquement douteuses; les expériences prétendues du preprint 2003/022 sont à mon sens contestables car non reproductibles) récentes ne trouvent leur inspiration que dans
    une certaine peur de la concurrence, vis-à-vis d'une cryptanalyse encore plus contestée scientifiquement (notamment par B. Schneier) et qui n'a connue AUCUNE expérimentation. ALors où est le sérieux ? Ce n'est pas mon problème et je regrette toute cette hystérie qui n'est scientifiquement pas souhaitable.

    Je signale que l'attaque PDRC des systèmes par blocs a été acceptée pour publication dans une conférence internationale.
    Affirmer que cette approche est fausse (sans autres preuves) ne manque pas d'une certaine prétention : des scientifiques internationalement reconnus comme ceux du comité scientifique
    de programme de la conférence CCC 03 seraient ils moins crédibles que tous ceux qui donnent leur avis sans être du domaine.

    Enfin, si la technique est transposable effectivement à n'importe quel sous-ensemble clair, pour le moment elle ne permet pas de dire que l'AES est cassé (encore un effet d'hystérie). Seuls trois bits sont retrouvés avec une quantité de textes chiffrés encore importante, trop pour être opérationnelle. Mais ces résultats datent déjà de près d'un an et depuis d'autres résultats ont été obtenus, qui sont en cours d'évaluation. Le résultat, qui lui ne peut être remis en cause, est le fait que la réutilisation de la clef de bloc en bloc est une faiblesse assez importante. Je pose seulement une question, pour terminer : pourquoi les algorithmes par blocs, dont on nous vante tant la sécurité, sont ils interdits d'emploi pour la protection des données sensibles aux USA (voir le FIPS 146 pour le DES, et le FIPS 196 pour l'AES) ?

    fll (concepteur de la cryptanalyse PDRC)