info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Hashmask Lite ... futur Challenge.
41 views
Skip to first unread message
Philippe Lheureux
May 6, 2012, 12:01:56 PM5/6/12
to
Ca marche , ceci dit c'est tellement simple comme principe de chiffrement
que je me demande si ça n'existe pas déjà.
http://dimooz.free.fr/void/hashmask/v-0-1/index.php
Quelqu'un d'entre vous a-t-il connaissance d'un logiciel de chiffrement basé
sur le même principe ?
que je me demande si ça n'existe pas déjà.
http://dimooz.free.fr/void/hashmask/v-0-1/index.php
Quelqu'un d'entre vous a-t-il connaissance d'un logiciel de chiffrement basé
sur le même principe ?
Christophe HENRY
May 6, 2012, 12:36:37 PM5/6/12
to
commentaires, je voudrais qu'il publie l'implémentation de référence afin
que j'évite de poursuivre un algo métamorphe....
Grfgvphyr tnhpur 53te grfgvphyr qebvg 47te. Crfntr à yn fbegvr qrf ohearf.
#EnqvbYbaqerf
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
Philippe Lheureux
May 6, 2012, 4:15:42 PM5/6/12
to
Les amis, ne dites rien. Avant de se noyer dans les flots de
commentaires, je voudrais qu'il publie l'implémentation de référence afin
que j'évite de poursuivre un algo métamorphe....
http://dimooz.free.fr/void/hashmask/v-0-1/index.php
Le logiciel , son code source , son principe et les fichiers du Challenge.
A vous de jouer pour trouver une attaque capable de nuire au système
HashMask Lite.
Philippe Lheureux
May 7, 2012, 3:08:31 AM5/7/12
to
A propos des attaques possibles , le masque est complètement indépendant du
clair tout en étant totalement dépendant de la clé utilisée.
Le challenge revient en fait à casser le SHA-256 d'une seule et même clé
salée x fois avec le résultat du salage précédent. C'est la concaténation
des différents chiffrages d'une seule et même clé qui fournit le masque.
Si c'est possible , HashMask Lite est cassé ( et la protection de nombreux
mots de passe sur internet aussi... en plus vous pourrez vous vanter d'avoir
cassé le SHA-256 (*) :-)
Si cela ne l'est pas Hashmask Lite apporte une utilisation originale du
SHA-256 en plus d'apporter une sécurité au niveau chiffrement.
A vous de jouer .. ceci dit j'attends toujours une réponse à cette question
: Avez-vous connaissance d'un système de chiffrement existant utilisant la
même méthode que HashMask Lite ?
(*) SHA-256 est devenu le nouveau standard recommandé en matière de hachage
cryptographique après les attaques sur MD5 et SHA-1. Les autres membres de
la famille SHA ont été relativement peu cryptanalysés par rapport à SHA-0 et
SHA-1. En 2003, Helena Handschuh et Henri Gilbert ont publié une analyse de
SHA-256, 384 et 512. Leur étude montre que les autres membres de SHA ne sont
pas atteints par les attaques qui avaient fait leurs preuves sur les autres
fonctions de hachage (MD4, MD5 et SHA-1 entre autres). La cryptanalyse
linéaire et différentielle ne s’appliquent pas. ( Source Wikipédia )
Christophe HENRY
May 7, 2012, 3:38:01 PM5/7/12
to
Le Mon, 07 May 2012 09:08:31 +0200, Philippe Lheureux a écrit :
> A propos des attaques possibles , le masque est complètement indépendant
> du clair tout en étant totalement dépendant de la clé utilisée.
Je confirme.
> A propos des attaques possibles , le masque est complètement indépendant
> du clair tout en étant totalement dépendant de la clé utilisée.
> Le challenge revient en fait à casser le SHA-256 d'une seule et même clé
> salée x fois avec le résultat du salage précédent. C'est la
> concaténation des différents chiffrages d'une seule et même clé qui
> fournit le masque.
> Si c'est possible , HashMask Lite est cassé ( et la protection de
> nombreux mots de passe sur internet aussi... en plus vous pourrez vous
> vanter d'avoir cassé le SHA-256 (*) :-)
31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
correspond ?
Il suffit de le demander à google! (gbgb)
> Si cela ne l'est pas Hashmask Lite apporte une utilisation originale du
> SHA-256 en plus d'apporter une sécurité au niveau chiffrement.
> A vous de jouer .. ceci dit j'attends toujours une réponse à cette
> question : Avez-vous connaissance d'un système de chiffrement existant
> utilisant la même méthode que HashMask Lite ?
Oui. Ça a 50 ans d'âge. Mais ça va attendre demain, le temps de rédiger
mon article :-p
Philippe Lheureux
May 7, 2012, 5:01:05 PM5/7/12
to
> Le challenge revient en fait à casser le SHA-256 d'une seule et même clé
> salée x fois avec le résultat du salage précédent. C'est la
> concaténation des différents chiffrages d'une seule et même clé qui
> fournit le masque.
En fait, non ;-)
LP : J'ai oublié de préciser :
> salée x fois avec le résultat du salage précédent. C'est la
> concaténation des différents chiffrages d'une seule et même clé qui
> fournit le masque.
En fait, non ;-)
" qui fournit le masque après substitution de chaque paire de chiffres du
masque par un seul caractère ASCII."
En fait, SHA-256 est cassé au sens où tu l'entends. Par exemple, à quoi
31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
correspond ?
Il suffit de le demander à google! (gbgb)
> Si cela ne l'est pas Hashmask Lite apporte une utilisation originale du
> SHA-256 en plus d'apporter une sécurité au niveau chiffrement.
Utilisation intelligente, oui mais pas originale.
fois je serais le premier à y avoir pensé ... Youpi !
> A vous de jouer .. ceci dit j'attends toujours une réponse à cette
> question : Avez-vous connaissance d'un système de chiffrement existant
> utilisant la même méthode que HashMask Lite ?
> (...)
Oui. Ça a 50 ans d'âge. Mais ça va attendre demain, le temps de rédiger
mon article :-p
tranquille.
Ph. B.
May 8, 2012, 4:12:58 AM5/8/12
to
Philippe Lheureux a écrit :
Au lieu d'attendre tranquillement, pensez soit à changer de lecteur de
news, soit à le paramétrer correctement : vos interventions sont déjà de
par leur forme illisibles ; ce n'est pas votre pré-fixage qui
l'améliore... ;-)
--
Philippe.
news, soit à le paramétrer correctement : vos interventions sont déjà de
par leur forme illisibles ; ce n'est pas votre pré-fixage qui
l'améliore... ;-)
--
Philippe.
Stephane CARPENTIER
May 8, 2012, 8:11:25 AM5/8/12
to
Philippe Lheureux wrote:
>> Si cela ne l'est pas Hashmask Lite apporte une utilisation originale du
>> SHA-256 en plus d'apporter une sécurité au niveau chiffrement.
>
> Utilisation intelligente, oui mais pas originale.
>
> LP Si cela n'a pas été employé ailleurs , c'est assez étonnant ! Pour une
> fois je serais le premier à y avoir pensé ... Youpi !
Tu ne semble pas avoir compris ce qu'il a écrit. Pourtant, ça me semble
>> Si cela ne l'est pas Hashmask Lite apporte une utilisation originale du
>> SHA-256 en plus d'apporter une sécurité au niveau chiffrement.
>
> Utilisation intelligente, oui mais pas originale.
>
> LP Si cela n'a pas été employé ailleurs , c'est assez étonnant ! Pour une
> fois je serais le premier à y avoir pensé ... Youpi !
clair.
Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux de
la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
aucun article sur tes méthodes de chiffrement.
Erwann Abalea
May 8, 2012, 8:45:52 AM5/8/12
to
Le mardi 8 mai 2012 14:11:25 UTC+2, Stephane CARPENTIER a écrit :
[...]
[...]
> Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux de
> la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
> aucun article sur tes méthodes de chiffrement.
Le monde s'est toujours moqué des génies. Christophe Colomb, les frères Wright, Galilée, Bozo le clown...
> la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
> aucun article sur tes méthodes de chiffrement.
dimitri.mestdagh
May 8, 2012, 9:17:57 AM5/8/12
to
> En fait, SHA-256 est cassé au sens où tu l'entends. Par exemple, à quoi
> 31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
> correspond ?
>
> Il suffit de le demander à google! (gbgb)
Hmmm.... J'ai des doutes là dessus... ce qu'on trouve sur google ce
> 31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
> correspond ?
>
> Il suffit de le demander à google! (gbgb)
sont surtout des références de passwords classiques genre "toto",
"toto1", etc...
Là je teste dans google quelques hash SHA-256 générés par l'outil et
aucun ne ressort comme étant connu...
Il reste encore certainement les "rainbow tables" à exploiter mais il
faudra alors générer des tables de hash contenant toute (ou partie de)
la clé qui aura servi à saler ceux utilisés par l'outil.
D'après ce que j'en ai lu, les tables classiques utilisées par
Ophcrack (par exemple) sont générées à partir de passwords
(dictionnaires) n'excédant pas 13 ou 15 caractères. Ici on utilise 64
caractères + ceux de la clé...
Ca devrait suffire à compliquer assez le process de reverse
engineering de façon à ce que le cracking ne soit pas gérable à
l'échelle d'une vie humaine... non ?
Merci pour vos réponses :)
Philippe Lheureux
May 8, 2012, 10:16:24 AM5/8/12
to
Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux de
la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
aucun article sur tes méthodes de chiffrement.
LP : Tout est la : http://www.superlutin.net/cec.html
la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
aucun article sur tes méthodes de chiffrement.
et sur http://dimooz.free.fr/void/hashmask/v-0-1/index.php
Denis CAMUS
May 8, 2012, 12:07:49 PM5/8/12
to
Stephane CARPENTIER a formulé ce mardi :
--
Seuls les faucons volent.
Les vrais restent au sol.
>
> Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux de
> la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
> aucun article sur tes méthodes de chiffrement.
Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
> Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux de
> la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi, ni
> aucun article sur tes méthodes de chiffrement.
--
Seuls les faucons volent.
Les vrais restent au sol.
Erwan David
May 8, 2012, 12:14:39 PM5/8/12
to
Denis CAMUS <f6...@yopmail.com> écrivait :
> Stephane CARPENTIER a formulé ce mardi :
>>
>> Sinon, je suis surpris, le MISC hors série actuel fait un état des
>> lieux de la cryptographie moderne. Pourtant, je n'ai vu aucun
>> article de toi, ni aucun article sur tes méthodes de chiffrement.
>
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
C'est un journal (papier) qu'on trouve chez les bons marchands de
journaux, ou sur le site de l'éditeur (ÉDITIONS DIAMOND de mémoire)
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
> Stephane CARPENTIER a formulé ce mardi :
>>
>> Sinon, je suis surpris, le MISC hors série actuel fait un état des
>> lieux de la cryptographie moderne. Pourtant, je n'ai vu aucun
>> article de toi, ni aucun article sur tes méthodes de chiffrement.
>
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
journaux, ou sur le site de l'éditeur (ÉDITIONS DIAMOND de mémoire)
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Stephane CARPENTIER
May 8, 2012, 1:43:21 PM5/8/12
to
Denis CAMUS wrote:
> Stephane CARPENTIER a formulé ce mardi :
>>
>> Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux
>> de la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi,
>> ni aucun article sur tes méthodes de chiffrement.
>
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
Pour compléter la réponse d'Erwan, je dirais que c'est le magazine de
> Stephane CARPENTIER a formulé ce mardi :
>>
>> Sinon, je suis surpris, le MISC hors série actuel fait un état des lieux
>> de la cryptographie moderne. Pourtant, je n'ai vu aucun article de toi,
>> ni aucun article sur tes méthodes de chiffrement.
>
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
référence de sécurité informatique en français. C'est d'un autre niveau que
le virus informatique (je ne sais pas si ça existe encore).
Tu tapes MISC dans google et les trois premiers liens te donneront plus de
renseignements.
Il y existe aussi hakin9 qui est plus dur à trouver, et qui est la
traduction d'un magazine étranger.
Erwan David
May 8, 2012, 1:52:06 PM5/8/12
to
Philippe Lheureux
May 8, 2012, 1:55:31 PM5/8/12
to
Pour compléter la réponse d'Erwan, je dirais que c'est le magazine de
référence de sécurité informatique en français. C'est d'un autre niveau que
le virus informatique (je ne sais pas si ça existe encore).
Tu tapes MISC dans google et les trois premiers liens te donneront plus de
renseignements.
Il y existe aussi hakin9 qui est plus dur à trouver, et qui est la
traduction d'un magazine étranger.
LP : Je ne risque pas d'être dedans , a moins que Christophe HENRY prouve
référence de sécurité informatique en français. C'est d'un autre niveau que
le virus informatique (je ne sais pas si ça existe encore).
Tu tapes MISC dans google et les trois premiers liens te donneront plus de
renseignements.
Il y existe aussi hakin9 qui est plus dur à trouver, et qui est la
traduction d'un magazine étranger.
que Hashmask lite est totalement invulnérable à toute attaque connue sur ce
genre de principe.La crypto pour moi , ce n'est pas mon métier , ni même un
véritable loisir , c'est juste comme ça pour décompresser un peu entre
l'écriture de deux livres.
J'ai rencontré Dimitri à cause de ma théorie sur la pyramide de Chéops et
voila , on a enchainé sur des essais de chiffrement. D'abord CENA, puis CEC
puis HasMasK. Ca occupe l'esprit d'essayer de trouver un système simple et
ultra résistant.
Personnellement , je pense que pour casser HashMask ça risque d'être dur.
C'est peut être possible mais surement pas par n'importe qui.
Denis CAMUS
May 8, 2012, 2:14:13 PM5/8/12
to
Denis CAMUS a présenté l'énoncé suivant :
locale.
Denis
>
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
Merci à tous pour vos réponses. Je vais squatter la maison de la presse
> Question d'un béochien : c'est quoi le MISC et où le trouve-t-on ?
locale.
Denis
Christophe HENRY
May 8, 2012, 2:49:13 PM5/8/12
to
Le Tue, 08 May 2012 06:17:57 -0700, dimitri.mestdagh a écrit :
>> En fait, SHA-256 est cassé au sens où tu l'entends. Par exemple, à quoi
>> 31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
>> correspond ?
>>
>> Il suffit de le demander à google! (gbgb)
>
> Hmmm.... J'ai des doutes là dessus... ce qu'on trouve sur google ce sont
> surtout des références de passwords classiques genre "toto", "toto1",
> etc...
En effet. Donc l'utilisation de SHA256 seul ne garantit pas
>> En fait, SHA-256 est cassé au sens où tu l'entends. Par exemple, à quoi
>> 31f7a65e315586ac198bd798b6629ce4903d0899476d5741a9f32e2e521b6a66
>> correspond ?
>>
>> Il suffit de le demander à google! (gbgb)
>
> Hmmm.... J'ai des doutes là dessus... ce qu'on trouve sur google ce sont
> surtout des références de passwords classiques genre "toto", "toto1",
> etc...
l'invulnérabilité du procédé. C'est effectivement "toto" que j'avais
condensé.
> Là je teste dans google quelques hash SHA-256 générés par l'outil et
> aucun ne ressort comme étant connu...
Mais comme souvent les mots de passe sont prévisibles, du fait du manque
de vigilance, alors il est possible de remonter jusqu'au clair.
> Il reste encore certainement les "rainbow tables" à exploiter mais il
> faudra alors générer des tables de hash contenant toute (ou partie de)
> la clé qui aura servi à saler ceux utilisés par l'outil.
C'est l'idée, mais je pense que ça ne marchera pas ici. C'est intelligent
de réutiliser la clé pour générer la suite, dans l'algo.
> Ca devrait suffire à compliquer assez le process de reverse engineering
> de façon à ce que le cracking ne soit pas gérable à l'échelle d'une vie
> humaine... non ?
Je publierai mon article ce soir, comme promis.
Stephane CARPENTIER
May 8, 2012, 3:31:54 PM5/8/12
to
Erwan David wrote:
> Stephane CARPENTIER <s...@fiat-linux.fr> écrivait :
> Stephane CARPENTIER <s...@fiat-linux.fr> écrivait :
>
>> Il y existe aussi hakin9 qui est plus dur à trouver, et qui est la
>> traduction d'un magazine étranger.
>
> hakin9 est polonais si je ne m'abuse...
C'est très possible, si ce n'est pas le cas, c'est bien imité.
>> Il y existe aussi hakin9 qui est plus dur à trouver, et qui est la
>> traduction d'un magazine étranger.
>
> hakin9 est polonais si je ne m'abuse...
Stephane CARPENTIER
May 8, 2012, 3:46:24 PM5/8/12
to
Philippe Lheureux wrote:
> Personnellement , je pense que pour casser HashMask ça risque d'être dur.
> C'est peut être possible mais surement pas par n'importe qui.
Voilà, c'est bien ce qui t'es reproché. Que tu t'amuses à te créer tes algos
> Personnellement , je pense que pour casser HashMask ça risque d'être dur.
> C'est peut être possible mais surement pas par n'importe qui.
n'est pas un problème, loin de là.
Que tu affirmes qu'ils sont efficaces sans en comprendre leurs failles
(quand elles te sont expliquées) est lassant.
Je vais faire une analogie. Supposons que tu installes une porte blindée.
Quelqu'un la regarde et t'explique que la serrure est nulle. Au lieu de
remplacer la serrure, tu vas mettre du chatterton devant. La personne va
enlever le bout de chatterton, pour te montrer que la serrure est toujours
nulle.
Au lieu de remplacer la serrure, tu vas mettre 50 bouts de chatterton sur ta
porte. La personne va mettre plus de temps à trouver le bout de chatterton
qui cache la serrure. C'est vrai que ça retarde un attaquant, mais pas assez
pour dire que la serrure est bonne. L'attaquant trouvera que virer les 49
bouts de chatterton avant d'attaquer la serrure est chiant.
Au moment où tu auras mis 5000 bouts de chatterton sur ta porte, avec
toujours la même serrure, tout le monde se sera lassé. Si tu changes enfin
ta serrure, les gens voudrons savoir si tu as vraiment compris pourquoi ta
serrure initiale était mauvaise avant de se fatiguer à virer les 5000 bouts
de chatterton.
Pour ton algo, c'est pareil, les lecteurs veulent savoir pourquoi ton algo
est efficace avant de le regarder.
Philippe Lheureux
May 8, 2012, 4:29:43 PM5/8/12
to
Quelqu'un la regarde et t'explique que la serrure est nulle. Au lieu de
remplacer la serrure, tu vas mettre du chatterton devant. La personne va
enlever le bout de chatterton, pour te montrer que la serrure est toujours
nulle.
LP : Pour l'instant , en ce qui concerne HashMask , personne n'a dit que le
remplacer la serrure, tu vas mettre du chatterton devant. La personne va
enlever le bout de chatterton, pour te montrer que la serrure est toujours
nulle.
système était nul.
Au lieu de remplacer la serrure, tu vas mettre 50 bouts de chatterton sur ta
porte. La personne va mettre plus de temps à trouver le bout de chatterton
qui cache la serrure. C'est vrai que ça retarde un attaquant, mais pas assez
pour dire que la serrure est bonne. L'attaquant trouvera que virer les 49
bouts de chatterton avant d'attaquer la serrure est chiant.
tout le chatterton pour ne laisser que la serrure.
Au moment où tu auras mis 5000 bouts de chatterton sur ta porte, avec
toujours la même serrure, tout le monde se sera lassé. Si tu changes enfin
ta serrure, les gens voudrons savoir si tu as vraiment compris pourquoi ta
serrure initiale était mauvaise avant de se fatiguer à virer les 5000 bouts
de chatterton.
Pour ton algo, c'est pareil, les lecteurs veulent savoir pourquoi ton algo
est efficace avant de le regarder.
cas , personne ne me croirait. Je pense que l'avis d'une tierce personne
comme Christophe Henry serait plus crédible.
Philippe Lheureux
May 8, 2012, 4:38:52 PM5/8/12
to
En effet. Donc l'utilisation de SHA256 seul ne garantit pas
l'invulnérabilité du procédé. C'est effectivement "toto" que j'avais
condensé.
les gens ont eux même mis en ligne et rien de plus.
Si tu recherches d'ou provient le Hash
b13ecf9bc7ad95a7e2bdebc7329ed41b611a86c869c6a9e03fbea02901702ed3
Tu ne pourras jamais savoir que c'est
b3375df23412e94ffd956379801f6ee560637f31d1bd24952ad6c39f52fc13e3François et
Nicolas sont dans un bateau. Nicolas tombe à l'eau.
si je ne le met pas en ligne quelque part.
C'est l'idée, mais je pense que ça ne marchera pas ici. C'est intelligent
de réutiliser la clé pour générer la suite, dans l'algo.
, ce qui fait que même si par hasard tu tombes sur un bon hash , tu ne peux
pas avoir le hash suivant sans la clé.
> Ca devrait suffire à compliquer assez le process de reverse engineering
> de façon à ce que le cracking ne soit pas gérable à l'échelle d'une vie
> humaine... non ?
C'est vrai. Quand la porte est fermée, on passe par la fenêtre...
Je publierai mon article ce soir, comme promis.
Merci.
Stephane CARPENTIER
May 8, 2012, 5:33:38 PM5/8/12
to
Philippe Lheureux wrote:
> LP: Ce n'est pas à moi de dire s'il est efficace ou non
Bien sûr que si.
> LP: Ce n'est pas à moi de dire s'il est efficace ou non
> ... dans les deux
> cas , personne ne me croirait.
Christophe HENRY
May 8, 2012, 7:15:25 PM5/8/12
to
Bonjour à tous,
Comme annoncé, j'ai cryptanalysé Hashmask. Par construction, cet
algorithme est à clé à usage unique. Si une clé est utilisée deux fois,
alors la porte est grande ouverte à la cryptanalyse.
La faiblesse de l'algorithme est qu'il n'y a pas besoin de clé pour
rentrer. La fenêtre grande ouverte est le masque lui-même. Avec un clair
et un chiffré, on calcule le masque. Avec le masque, on peut alors
décrypter un fichier chiffré avec la même clé. La seule restriction est
que la taille du masque accessible est limité par la longueur du clair.
Ainsi, j'ai formellement démontré que le challenge proposé par Philippe
était faisable, mais pas pour la portion de fichier au-délà du masque
calculé. Et effectivement, le fichier à déchiffrer reprend le clair qu'il
complète ensuite. Cette partie supplémentaire m'est inacessible.
J'ai posté mon article ici :
[http://blog.sbgodin.fr/index.php?2012/05/09/00/29/56-cryptanalyse-de-
hashmask]
Les codes sources sont ici :
[https://sekur.sbgodin.fr/svn/hashmask/trunk/]
Comme annoncé, j'ai cryptanalysé Hashmask. Par construction, cet
algorithme est à clé à usage unique. Si une clé est utilisée deux fois,
alors la porte est grande ouverte à la cryptanalyse.
La faiblesse de l'algorithme est qu'il n'y a pas besoin de clé pour
rentrer. La fenêtre grande ouverte est le masque lui-même. Avec un clair
et un chiffré, on calcule le masque. Avec le masque, on peut alors
décrypter un fichier chiffré avec la même clé. La seule restriction est
que la taille du masque accessible est limité par la longueur du clair.
Ainsi, j'ai formellement démontré que le challenge proposé par Philippe
était faisable, mais pas pour la portion de fichier au-délà du masque
calculé. Et effectivement, le fichier à déchiffrer reprend le clair qu'il
complète ensuite. Cette partie supplémentaire m'est inacessible.
J'ai posté mon article ici :
[http://blog.sbgodin.fr/index.php?2012/05/09/00/29/56-cryptanalyse-de-
hashmask]
Les codes sources sont ici :
[https://sekur.sbgodin.fr/svn/hashmask/trunk/]
dimitri.mestdagh
May 8, 2012, 9:49:38 PM5/8/12
to
> Comme annoncé, j'ai cryptanalysé Hashmask.
Très belle démonstration de cryptanalyse, encore une fois. Merci pour
le temps passé à l'étude et à la rédaction.
> Par construction, cet
> algorithme est à clé à usage unique. Si une clé est utilisée deux fois,
> alors la porte est grande ouverte à la cryptanalyse.
chiffre...
Il me semble que c'est la même recommandation pour l'utilisation du
masque jetable classique, non ?
> La faiblesse de l'algorithme est qu'il n'y a pas besoin de clé pour
> rentrer. La fenêtre grande ouverte est le masque lui-même. Avec un clair
> et un chiffré, on calcule le masque. Avec le masque, on peut alors
> décrypter un fichier chiffré avec la même clé. La seule restriction est
> que la taille du masque accessible est limité par la longueur du clair.
>
> Ainsi, j'ai formellement démontré que le challenge proposé par Philippe
> était faisable, mais pas pour la portion de fichier au-délà du masque
> calculé. Et effectivement, le fichier à déchiffrer reprend le clair qu'il
> complète ensuite. Cette partie supplémentaire m'est inacessible.
Sinon, le fait d'encapsuler (si on peut dire) le nom du fichier
original dans le chiffrement pourrait effectivement être perçu comme
une faille à exploiter ; cependant un nom de fichier n'excédant
généralement pas les 32 caractères, il ne serait véritablement
possible de s'en servir pour que pour retrouver une partie (seulement)
du dernier segment du masque, ce qui semble difficilement exploitable
en réalité : il faudrait (à condition de connaitre le nom du fichier
original, évidemment) :
- compléter ce dernier segment du masque à hauteur de 32 caractères
- utiliser le dernier segment pour en déduire le précédent
- recommencer jusqu'à obtenir le premier segment du masque (et ainsi
le masque en intégralité)
Etant donné le sel utilisé pour la création des hash SHA-256, ces deux
derniers points semblent plus difficiles à réaliser aujourd'hui qu'une
simple brute-force sur la clé... Quant à la complétion initiale du
dernier segment, tout dépend de la longueur du nom de fichier bien
sûr, mais par exemple pour un nom de fichier de 12 caractères, il faut
encore en trouver/déduire 20 avant de pouvoir espérer en tirer quelque
chose d'éventuellement exploitable... même réflexion donc, il semble
plus judicieux d'attaquer directement la clé en brute force dans ce
cas.
Questions :
- Est-il possible de déduire la chaine commune (clé) concaténée
(successivement avec le hash précédent) à partir de tous les hash
utilisés ? par recoupement ou autres tables arc-en-ciel ?
- Le principe permettant de casser RC4 (ou le WEP) consiste à analyser
les flux de chiffrement générés afin de déterminer le vecteur commun
(la clé) par statistiques, cependant l'opération nécessite plusieurs
échanges (quelques millions) réalisés avec une même clé. Cela permet-
il d'affirmer qu'il est absolument impossible d'opérer une quelconque
analyse à partir du moment où on n'utilise jamais deux fois la même
clé ?
Pour conclure : si j'ai bien suivi la cryptanalyse, il semble possible
d'affirmer que :
- il est possible de reconstituer le masque uniquement si on dispose à
la fois du clair et du chiffré
- reconstituer le masque ne permet pas de retrouver la clé utilisée
- reconstituer le masque ne représente pas d'intérêt si l'utilisateur
change de clé à chaque utilisation comme prévu
- exploiter le nom du fichier encapsulé dans le chiffré semble moins
efficace qu'une brute-force sur la clé
(n'hésitez pas à me dire si je me trompe...)
On parle ici d'une version "allégée" de l'algo de Philippe. La version
originale comprenait une substitution (basée sur les valeurs de la
clé) de la table ascii (utilisée pour la conversion hexa/decimal/
ascii) lors de la création du masque, ainsi qu'une substitution des
caractères en sortie. Ce principe applicatif compliquerait grandement
l'obtention du masque original dans le processus de reverse, serait-il
pertinent de le réintroduire dans la méthode ou bien ne s'agit-il
encore ici que d'une rustine (chatterton) inutile à implémenter ?
Christophe HENRY
May 9, 2012, 1:12:30 AM5/9/12
to
Le Tue, 08 May 2012 18:49:38 -0700, dimitri.mestdagh a écrit :
>> (...)
jeu en vaut la chandelle. Hashmask n'est pas invulnérable et en plus il
ne faut pas utiliser deux fois la clé.
>> (...)
cela, il faudrait se rappeler quel endroit du masque on a déjà utilisé et
ne commencer à l'exploiter qu'à partir d'une certaine position. Cela
revient à utiliser une autre clé, puisqu'il faudrait quand même
transmettre une information supplémentaire à chaque chiffrement.
> Sinon, le fait d'encapsuler (si on peut dire) le nom du fichier original
> dans le chiffrement pourrait effectivement être perçu comme une faille à
> exploiter ; cependant un nom de fichier n'excédant généralement pas les
> 32 caractères, il ne serait véritablement possible de s'en servir pour
> que pour retrouver une partie (seulement)
> du dernier segment du masque, ce qui semble difficilement exploitable en
> réalité : il faudrait (à condition de connaître le nom du fichier
> original, évidemment) :
> (...)
Effectivement, si le nom de fichier est trop court, c'est mort pour le
dernier segment du masque. Mais je n'ai de toutes façons pas trouvé de
vraie utilité à connaître ce dernier segment. Par contre, on peut
extraire des informations *sans* connaître le masque. Par exemple, en XOR-
ant deux fichiers chiffrés, si on trouve trois caractères NULL à la fin
du XOR, alors on sait que les extensions de fichier sont identiques. En
plus, on sait que les derniers caractères clairs sont "doc", "DOC", "xls",
"XLS", etc. Sans compter la possibilité de décrypter le nom du fichier.
> (...)
> Quant à la complétion initiale du dernier segment, tout dépend de la
> longueur du nom de fichier bien sûr, mais par exemple pour un nom de
> fichier de 12 caractères, il faut encore en trouver/déduire 20 avant de
> pouvoir espérer en tirer quelque chose d'éventuellement exploitable...
> même réflexion donc, il semble plus judicieux d'attaquer directement la
> clé en brute force dans ce cas.
Je pense que non. En accumulant plusieurs chiffrés, avec la même clé, on
peut appliquer la cryptanalyse classique qui sert contre le chiffre de
Vernam. Hashmask hérite de ses défauts.
> Questions :
> - Est-il possible de déduire la chaine commune (clé) concaténée
> (successivement avec le hash précédent) à partir de tous les hash
> utilisés ? par recoupement ou autres tables arc-en-ciel ?
Je ne sais pas.
> - Le principe permettant de casser RC4 (ou le WEP) consiste à analyser
> les flux de chiffrement générés afin de déterminer le vecteur commun (la
> clé) par statistiques, cependant l'opération nécessite plusieurs
> échanges (quelques millions) réalisés avec une même clé. Cela permet-
> il d'affirmer qu'il est absolument impossible d'opérer une quelconque
> analyse à partir du moment où on n'utilise jamais deux fois la même clé
> ?
Le cassage de RC4 profite de la réutilisation de la clé (pour le WEP du
Wifi). Dans le cadre d'un chiffrement sans réutilisation de la clé, la
cryptanalyse ne s'applique pas à mon humble avis. Dans le cadre d'un
chiffrement avec réutilisation de la clé, la cryptanalyse du Vernam
s'applique.
> Pour conclure : si j'ai bien suivi la cryptanalyse, il semble possible
> d'affirmer que :
> - il est possible de reconstituer le masque uniquement si on dispose à
> la fois du clair et du chiffré
Non. On refait inconditionnellement le masque si on a un clair et un
chiffré. On sais le reconstituer si on a plusieurs chiffrés, en utilisant
la cryptanalyse du Vernam.
> - reconstituer le masque ne permet pas de retrouver la clé utilisée
En ce qui me concerne, c'est vrai. Et ça pose le problème de prolonger un
masque déjà découvert.
> - reconstituer le masque ne représente pas d'intérêt si l'utilisateur
> change de clé à chaque utilisation comme prévu
Si, parce qu'on peut découvrir si un utilisateur réutilise une clé. Cela
donne des informations à l'attaque, comme par exemple l'identité probable
d'une personne s'ils sont plusieurs à communiquer chacun avec sa clé, par
exemple.
> - exploiter le nom du fichier encapsulé dans le chiffré semble
> moins efficace qu'une brute-force sur la clé (n'hésitez pas à me dire si
> je me trompe...)
J'ai montré plus haut que c'était bien plus efficace. C'est une faille à
supprimer de toute urgence. Autre exemple, les extensions de fichier sont
souvent à 3 lettres dans le suffixe, la lettre précédente étant le point.
On connaît donc toujours, ou presque, le 4ème dernier caractère clair.
> On parle ici d'une version "allégée" de l'algo de Philippe. La version
> originale comprenait une substitution (basée sur les valeurs de la clé)
> de la table ascii (utilisée pour la conversion hexa/decimal/ ascii) lors
> de la création du masque, ainsi qu'une substitution des caractères en
> sortie. Ce principe applicatif compliquerait grandement l'obtention du
> masque original dans le processus de reverse, serait-il pertinent de le
> réintroduire dans la méthode ou bien ne s'agit-il encore ici que d'une
> rustine (chatterton) inutile à implémenter ?
Une rustine, assurément. Cela mettrait peut-être la cryptanalyse hors de
ma portée faute de compétence et de temps. L'algorithme CENA était plus
tortueux et a ralenti son analyse, cela ne l'a pas rendu plus fort pour
autant. Si on me donnait du temps (et beaucoup d'argent), mes compétences
actuelles feraient l'affaire... Mais ici, mon temps est épuisé. Et moi
aussi ;-)
Bonne journée/soirée !
>> (...)
>> Par construction, cet algorithme est à clé à usage unique. Si une clé
>> est utilisée deux fois,
>> alors la porte est grande ouverte à la cryptanalyse.
>
> Oui c'est la condition sine qua non pour assurer la sécurité du
> chiffre... Il me semble que c'est la même recommandation pour
> l'utilisation du masque jetable classique, non ?
Oui. Le masque jetable est le seul chiffre vraiment invulnérable, donc le
>> est utilisée deux fois,
>> alors la porte est grande ouverte à la cryptanalyse.
>
> Oui c'est la condition sine qua non pour assurer la sécurité du
> chiffre... Il me semble que c'est la même recommandation pour
> l'utilisation du masque jetable classique, non ?
jeu en vaut la chandelle. Hashmask n'est pas invulnérable et en plus il
ne faut pas utiliser deux fois la clé.
>> (...)
>> Ainsi, j'ai formellement démontré que le challenge proposé par Philippe
>> était faisable, mais pas pour la portion de fichier au-délà du masque
>> calculé. Et effectivement, le fichier à déchiffrer reprend le clair
>> qu'il complète ensuite. Cette partie supplémentaire m'est inacessible.
>
> C'est bien l'effet recherché.
Cela signifie que l'algorithme est inutilisable en pratique. Pour éviter
>> était faisable, mais pas pour la portion de fichier au-délà du masque
>> calculé. Et effectivement, le fichier à déchiffrer reprend le clair
>> qu'il complète ensuite. Cette partie supplémentaire m'est inacessible.
>
> C'est bien l'effet recherché.
cela, il faudrait se rappeler quel endroit du masque on a déjà utilisé et
ne commencer à l'exploiter qu'à partir d'une certaine position. Cela
revient à utiliser une autre clé, puisqu'il faudrait quand même
transmettre une information supplémentaire à chaque chiffrement.
> Sinon, le fait d'encapsuler (si on peut dire) le nom du fichier original
> dans le chiffrement pourrait effectivement être perçu comme une faille à
> exploiter ; cependant un nom de fichier n'excédant généralement pas les
> 32 caractères, il ne serait véritablement possible de s'en servir pour
> que pour retrouver une partie (seulement)
> du dernier segment du masque, ce qui semble difficilement exploitable en
> original, évidemment) :
> (...)
Effectivement, si le nom de fichier est trop court, c'est mort pour le
dernier segment du masque. Mais je n'ai de toutes façons pas trouvé de
vraie utilité à connaître ce dernier segment. Par contre, on peut
extraire des informations *sans* connaître le masque. Par exemple, en XOR-
ant deux fichiers chiffrés, si on trouve trois caractères NULL à la fin
du XOR, alors on sait que les extensions de fichier sont identiques. En
plus, on sait que les derniers caractères clairs sont "doc", "DOC", "xls",
"XLS", etc. Sans compter la possibilité de décrypter le nom du fichier.
> (...)
> Etant donné le sel utilisé pour la création des hash SHA-256, ces deux
> derniers points semblent plus difficiles à réaliser aujourd'hui qu'une
> simple brute-force sur la clé...
Je confirme, en ce qui me concerne.
> derniers points semblent plus difficiles à réaliser aujourd'hui qu'une
> simple brute-force sur la clé...
> Quant à la complétion initiale du dernier segment, tout dépend de la
> longueur du nom de fichier bien sûr, mais par exemple pour un nom de
> fichier de 12 caractères, il faut encore en trouver/déduire 20 avant de
> pouvoir espérer en tirer quelque chose d'éventuellement exploitable...
> même réflexion donc, il semble plus judicieux d'attaquer directement la
> clé en brute force dans ce cas.
peut appliquer la cryptanalyse classique qui sert contre le chiffre de
Vernam. Hashmask hérite de ses défauts.
> Questions :
> - Est-il possible de déduire la chaine commune (clé) concaténée
> (successivement avec le hash précédent) à partir de tous les hash
> utilisés ? par recoupement ou autres tables arc-en-ciel ?
> - Le principe permettant de casser RC4 (ou le WEP) consiste à analyser
> les flux de chiffrement générés afin de déterminer le vecteur commun (la
> clé) par statistiques, cependant l'opération nécessite plusieurs
> échanges (quelques millions) réalisés avec une même clé. Cela permet-
> il d'affirmer qu'il est absolument impossible d'opérer une quelconque
> analyse à partir du moment où on n'utilise jamais deux fois la même clé
> ?
Wifi). Dans le cadre d'un chiffrement sans réutilisation de la clé, la
cryptanalyse ne s'applique pas à mon humble avis. Dans le cadre d'un
chiffrement avec réutilisation de la clé, la cryptanalyse du Vernam
s'applique.
> Pour conclure : si j'ai bien suivi la cryptanalyse, il semble possible
> d'affirmer que :
> - il est possible de reconstituer le masque uniquement si on dispose à
> la fois du clair et du chiffré
chiffré. On sais le reconstituer si on a plusieurs chiffrés, en utilisant
la cryptanalyse du Vernam.
> - reconstituer le masque ne permet pas de retrouver la clé utilisée
masque déjà découvert.
> - reconstituer le masque ne représente pas d'intérêt si l'utilisateur
> change de clé à chaque utilisation comme prévu
donne des informations à l'attaque, comme par exemple l'identité probable
d'une personne s'ils sont plusieurs à communiquer chacun avec sa clé, par
exemple.
> - exploiter le nom du fichier encapsulé dans le chiffré semble
> moins efficace qu'une brute-force sur la clé (n'hésitez pas à me dire si
> je me trompe...)
supprimer de toute urgence. Autre exemple, les extensions de fichier sont
souvent à 3 lettres dans le suffixe, la lettre précédente étant le point.
On connaît donc toujours, ou presque, le 4ème dernier caractère clair.
> On parle ici d'une version "allégée" de l'algo de Philippe. La version
> originale comprenait une substitution (basée sur les valeurs de la clé)
> de la table ascii (utilisée pour la conversion hexa/decimal/ ascii) lors
> de la création du masque, ainsi qu'une substitution des caractères en
> sortie. Ce principe applicatif compliquerait grandement l'obtention du
> masque original dans le processus de reverse, serait-il pertinent de le
> réintroduire dans la méthode ou bien ne s'agit-il encore ici que d'une
> rustine (chatterton) inutile à implémenter ?
ma portée faute de compétence et de temps. L'algorithme CENA était plus
tortueux et a ralenti son analyse, cela ne l'a pas rendu plus fort pour
autant. Si on me donnait du temps (et beaucoup d'argent), mes compétences
actuelles feraient l'affaire... Mais ici, mon temps est épuisé. Et moi
aussi ;-)
Bonne journée/soirée !
Philippe Lheureux
May 9, 2012, 2:04:46 AM5/9/12
to
Bonjour à tous,
Comme annoncé, j'ai cryptanalysé Hashmask. Par construction, cet
algorithme est à clé à usage unique. Si une clé est utilisée deux fois,
alors la porte est grande ouverte à la cryptanalyse.
dit depuis le début qu'une même clé ne doit pas être utilisée deux fois. Le
but de Hashmask étant de coller le plus possible à la méthodologie employée
pour le masque jetable tout en ayant pas la contrainte d'une clé longue à
transmettre.
La faiblesse de l'algorithme est qu'il n'y a pas besoin de clé pour
rentrer. La fenêtre grande ouverte est le masque lui-même. Avec un clair
et un chiffré, on calcule le masque. Avec le masque, on peut alors
décrypter un fichier chiffré avec la même clé. La seule restriction est
que la taille du masque accessible est limité par la longueur du clair.
faible d'après toi :-)
Ainsi, j'ai formellement démontré que le challenge proposé par Philippe
était faisable, mais pas pour la portion de fichier au-délà du masque
calculé. Et effectivement, le fichier à déchiffrer reprend le clair qu'il
complète ensuite. Cette partie supplémentaire m'est inacessible.
de masque jetable ... impossible à déchiffrer si tu ne connais pas la clé.
J'ai posté mon article ici :
[http://blog.sbgodin.fr/index.php?2012/05/09/00/29/56-cryptanalyse-de-
hashmask]
laisses sous entendre une faiblesse dans HashMask qui en fait n'est rien
d'autre qu'une faiblesse propre à tous les masques jetables
Je cite Wikipédia :
Le chiffrement par la méthode du masque jetable consiste à combiner le
message en clair avec une clé présentant les caractéristiques très
particulières suivantes :
La clé doit être une suite de caractères au moins aussi longue que le
message à chiffrer.
Les caractères composant la clé doivent être choisis de façon totalement
aléatoire.
Chaque clé, ou « masque », ne doit être utilisée qu'une seule fois (d'où le
nom de masque jetable).
L'intérêt considérable de cette méthode de chiffrement, c'est que si les
trois règles ci-dessus sont respectées strictement, le système offre une
sécurité théorique absolue, comme l'a prouvé Claude Shannon en 19492.
Il est bien précisé qu'une clé ne doit être utilisée qu'une seule fois .
HashMask a justement été crée pour simplifier l'échange de clés. Au lieu de
transmettre un masque hyper long , on le reconstruit à partir d'une clé
hyper courte.
Philippe Lheureux
May 9, 2012, 2:34:31 AM5/9/12
to
> Oui c'est la condition sine qua non pour assurer la sécurité du
> chiffre... Il me semble que c'est la même recommandation pour
> l'utilisation du masque jetable classique, non ?
Oui. Le masque jetable est le seul chiffre vraiment invulnérable, donc le
jeu en vaut la chandelle. Hashmask n'est pas invulnérable et en plus il
ne faut pas utiliser deux fois la clé.
de tout masque jetable. On ne peut donc pas en déduire une vulnérabilité si
on utilise correctement la méthode.
Je pense que non. En accumulant plusieurs chiffrés, avec la même clé, on
peut appliquer la cryptanalyse classique qui sert contre le chiffre de
Vernam. Hashmask hérite de ses défauts.
utilisation. La synchro est facile car avec le SHA-256 , le moindre rajout
d'un caractère dans la clé change complètement le masque ..
Bref a partir d'une clé comme "Le lutin vert"
ec82ee4cc1dfadbbf1f7aa8d3964a868507d1e16aa186ccd7015cd5bed625ea2
si la clé d'après est
"Le lutin vert 1"
on aura
b7a92c53a5ea5884aedf7a502e247671dcde2c66c5a5c4506a5581c5c907e688
"Le lutin vert 2"
c03e426684b1c739dc0f08729fd2cd66905c562775200e7c4a467a9a270e3382
on voit bien qu'en incrémentant simplement la clé , le masque produit sera
complètement différent.
> Questions :
> - Est-il possible de déduire la chaine commune (clé) concaténée
> (successivement avec le hash précédent) à partir de tous les hash
> utilisés ? par recoupement ou autres tables arc-en-ciel ?
Je ne sais pas.
complètement différentes. Le calcul est vite fait
pour un fichier qui fait 5000 caractères a masquer , il faut 10000
caractères de sous masque
10000 / 64 caractères par clé = 157 clés différentes concaténées les unes
derrière les autres.
L'ordi lui ne connait pas la clé , il connait juste une chaine comme
"b7a92c53a5ea5884aedf7a502e247671dcde2c66c5a5c4506a5581c5c907e688Le lutin
vert 2" il ne fait pas la différence entre le hash et la clé quand il
recalcule un hash. On peut donc en déduire que les 157 clés sont différentes
.. même si elles ont une partie de chaine communes.
Non. On refait inconditionnellement le masque si on a un clair et un
chiffré. On sais le reconstituer si on a plusieurs chiffrés, en utilisant
la cryptanalyse du Vernam.
différentes .. j'attends toujours la partie manquante :-)
J'ai montré plus haut que c'était bien plus efficace. C'est une faille à
supprimer de toute urgence. Autre exemple, les extensions de fichier sont
souvent à 3 lettres dans le suffixe, la lettre précédente étant le point.
On connaît donc toujours, ou presque, le 4ème dernier caractère clair.
du texte et ou tu n'arrives pas à retrouver la suite.
Admettons que l'extension de fichier soit DOC .. tu vas trouver quoi .. le
masque de 3 lettres :-) genre 4F12e1 et alors ? en quoi cela va-t-il te
renseigner sur le numéro précédent cette partie de sous-masque ?
Une rustine, assurément. Cela mettrait peut-être la cryptanalyse hors de
ma portée faute de compétence et de temps. L'algorithme CENA était plus
tortueux et a ralenti son analyse, cela ne l'a pas rendu plus fort pour
autant. Si on me donnait du temps (et beaucoup d'argent), mes compétences
actuelles feraient l'affaire... Mais ici, mon temps est épuisé. Et moi
aussi ;-)
pas à grand chose au final puisque le hash SHA-256 ne permet pas de remonter
vers la clé.
dimitri.mestdagh
May 9, 2012, 2:39:38 AM5/9/12
to
> Oui. Le masque jetable est le seul chiffre vraiment invulnérable, donc le
> jeu en vaut la chandelle. Hashmask n'est pas invulnérable et en plus il
> ne faut pas utiliser deux fois la clé.
Ok. Il va falloir que Philippe retravaille le principe donc :)
> jeu en vaut la chandelle. Hashmask n'est pas invulnérable et en plus il
> ne faut pas utiliser deux fois la clé.
> Cela signifie que l'algorithme est inutilisable en pratique. Pour éviter
> cela, il faudrait se rappeler quel endroit du masque on a déjà utilisé et
> ne commencer à l'exploiter qu'à partir d'une certaine position. Cela
> revient à utiliser une autre clé, puisqu'il faudrait quand même
> transmettre une information supplémentaire à chaque chiffrement.
chiffrer indéfiniment avec la même clé... bref.
> Effectivement, si le nom de fichier est trop court, c'est mort pour le
> dernier segment du masque. Mais je n'ai de toutes façons pas trouvé de
> vraie utilité à connaître ce dernier segment. Par contre, on peut
> extraire des informations *sans* connaître le masque. Par exemple, en XOR-
> ant deux fichiers chiffrés, si on trouve trois caractères NULL à la fin
> du XOR, alors on sait que les extensions de fichier sont identiques. En
> plus, on sait que les derniers caractères clairs sont "doc", "DOC", "xls",
> "XLS", etc. Sans compter la possibilité de décrypter le nom du fichier.
la même clé, mais en plus qu'ils fassent rigoureusement la même
taille, autant en ce qui concerne le contenu que le nom du fichier...
mais je concède, c'est déjà une faille en soi.
> (...) En accumulant plusieurs chiffrés, avec la même clé, on
> peut appliquer la cryptanalyse classique qui sert contre le chiffre de
> Vernam. Hashmask hérite de ses défauts. (...)
> Le cassage de RC4 profite de la réutilisation de la clé (pour le WEP du
> Wifi). Dans le cadre d'un chiffrement sans réutilisation de la clé, la
> cryptanalyse ne s'applique pas à mon humble avis. Dans le cadre d'un
> chiffrement avec réutilisation de la clé, la cryptanalyse du Vernam
> s'applique. (...) On refait inconditionnellement le masque si on a un clair et un
> Wifi). Dans le cadre d'un chiffrement sans réutilisation de la clé, la
> cryptanalyse ne s'applique pas à mon humble avis. Dans le cadre d'un
> chiffrement avec réutilisation de la clé, la cryptanalyse du Vernam
> chiffré. On sais le reconstituer si on a plusieurs chiffrés, en utilisant
> la cryptanalyse du Vernam.
Parfait alors ? ? Si l'outil n'est pas sensible à d'autres attaques
> la cryptanalyse du Vernam.
que celles applicables sur la méthode du masque jetable (excepté la
brute-force sur la clé) alors le challenge est remporté (c'était le
but initial, le masque jetable étant apparemment la méthode la plus
sûre au niveau sécurité).
> > - reconstituer le masque ne représente pas d'intérêt si l'utilisateur
> > change de clé à chaque utilisation comme prévu
>
> Si, parce qu'on peut découvrir si un utilisateur réutilise une clé. Cela
> donne des informations à l'attaque, comme par exemple l'identité probable
> d'une personne s'ils sont plusieurs à communiquer chacun avec sa clé, par
> exemple.
sécurité en cas de réutilisation d'une clé par l'une ou l'autre partie
(ce qui doit quand même poser des problèmes de gestion administrative
je concède). Il doit quand même y avoir quelque chose à améliorer
aussi de ce côté là...
> > - exploiter le nom du fichier encapsulé dans le chiffré semble
> > moins efficace qu'une brute-force sur la clé (n'hésitez pas à me dire si
> > je me trompe...)
>
> J'ai montré plus haut que c'était bien plus efficace. C'est une faille à
> supprimer de toute urgence. Autre exemple, les extensions de fichier sont
> souvent à 3 lettres dans le suffixe, la lettre précédente étant le point.
> On connaît donc toujours, ou presque, le 4ème dernier caractère clair.
du masque, ce qui ne semble pas vraiment exploitable. Même si encore
une fois, j'avoue que c'est déjà une faille en soi (j'y avais bien
pensé en codant l'implémentation pourtant, mais ne voyant pas de
manière sérieuse de l'exploiter je n'y ai pas prêté plus d'attention
que ça). Toutefois je vois déjà comment remédier au problème tout en
conservant l'encapsulation du nom dans le chiffré (je préfère vraiment
ne pas donner d'indications sur le nom ou l'extension du fichier
original).
> Une rustine, assurément. Cela mettrait peut-être la cryptanalyse hors de
> ma portée faute de compétence et de temps. L'algorithme CENA était plus
> tortueux et a ralenti son analyse, cela ne l'a pas rendu plus fort pour
> autant. Si on me donnait du temps (et beaucoup d'argent), mes compétences
> actuelles feraient l'affaire... Mais ici, mon temps est épuisé. Et moi
> aussi ;-)
beaucoup de temps tout ça.
Le but ici n'est pas de faire perdre un temps précieux aux personnes
intéressées, ce qui m'intéresse pour le moment c'est de savoir s'il
est possible de réaliser un algo qui tienne la route face aux
standards du moment (d'où l'idée d'utiliser un masque jetable). Il y a
certainement encore du chemin à faire mais je crois qu'on est sur la
bonne voie.
Finalement, à côté de Vernam, la faiblesse de HashMask réside
principalement dans le fait que la clé fournie est bien plus courte...
et donc attaquable en brute force, plus ou moins facilement suivant le
longueur de la clé utilisée (laissons de côté cette histoire de nom de
fichier qui sera bientôt corrigée de toutes façons).
Je me dis qu'il doit y avoir quelque chose à faire en utilisant
également le clair comme paramètre de chiffrement... je crois savoir
que ça a déjà été fait, je vais me pencher sur la question, ainsi peut-
être existe t-il une solution qui éviterait l'emploi d'une clé
différente à chaque usage... la suite au prochain épisode.
Merci d'avoir lu !
dimitri.mestdagh
May 9, 2012, 2:51:05 AM5/9/12
to
> Quelqu'un d'entre vous a-t-il connaissance d'un logiciel de chiffrement basé
> sur le même principe ?
En cherchant un peu sur le wiki, j'ai trouvé une indication sur une
méthode plus ou moins similaire qui datait de 1987... aouch, 25 ans
déjà !
C'est pas encore les 50 ans annoncés mais quand même... :P côté
principe révolutionnaire c'est peut-être pas encore ça finalement.
> sur le même principe ?
En cherchant un peu sur le wiki, j'ai trouvé une indication sur une
méthode plus ou moins similaire qui datait de 1987... aouch, 25 ans
déjà !
C'est pas encore les 50 ans annoncés mais quand même... :P côté
principe révolutionnaire c'est peut-être pas encore ça finalement.
Philippe Lheureux
May 9, 2012, 3:14:12 AM5/9/12
to
Ok. Il va falloir que Philippe retravaille le principe donc :)
pas pu déchiffrer la suite du masque malgré 99,99% de connu.
Hmmm... pour cela il faudrait que les deux chiffrés l'aient été avec
la même clé, mais en plus qu'ils fassent rigoureusement la même
taille, autant en ce qui concerne le contenu que le nom du fichier...
mais je concède, c'est déjà une faille en soi.
lettre avec la date ou Monsieur :-)
Parfait alors ? ? Si l'outil n'est pas sensible à d'autres attaques
que celles applicables sur la méthode du masque jetable (excepté la
brute-force sur la clé) alors le challenge est remporté (c'était le
but initial, le masque jetable étant apparemment la méthode la plus
sûre au niveau sécurité).
:-)
Finalement, à côté de Vernam, la faiblesse de HashMask réside
principalement dans le fait que la clé fournie est bien plus courte...
et donc attaquable en brute force, plus ou moins facilement suivant le
longueur de la clé utilisée (laissons de côté cette histoire de nom de
fichier qui sera bientôt corrigée de toutes façons).
Il était une fois au royaume des fées, Phil, un jeune lutin des bois et
Fanny, une petite fée des framboises que le destin avait fait se rencontrer.
ça fait 148 caractères :-) Combien de temps pour casser ça ?
Philippe Lheureux
May 9, 2012, 3:15:41 AM5/9/12
to
En cherchant un peu sur le wiki, j'ai trouvé une indication sur une
méthode plus ou moins similaire qui datait de 1987... aouch, 25 ans
déjà !
C'est pas encore les 50 ans annoncés mais quand même... :P côté
principe révolutionnaire c'est peut-être pas encore ça finalement.
LP Envoi moi le lien car il y a 25 ans le SHA-256 n'existait probablement
méthode plus ou moins similaire qui datait de 1987... aouch, 25 ans
déjà !
C'est pas encore les 50 ans annoncés mais quand même... :P côté
principe révolutionnaire c'est peut-être pas encore ça finalement.
pas .
dimitri.mestdagh
May 9, 2012, 8:31:35 AM5/9/12
to
(équivalente à ton idée de création d'un tableau de substitution). Il
est bien évident que SHA-256 n'existait pas à l'époque...
http://fr.wikipedia.org/wiki/RC4
dimitri.mestdagh
May 9, 2012, 8:57:09 AM5/9/12
to
> LP : une cl courte c'est aussi :
>
> Il tait une fois au royaume des f es, Phil, un jeune lutin des bois et
> Fanny, une petite f e des framboises que le destin avait fait se rencontrer.
>
> a fait 148 caract res :-) Combien de temps pour casser a ?
Bonne question ! Pas mal d'années certainement avec les moyens
actuels ? ... Pour te donner une idée mon PC perso peut tester en
brute force entre 1M et 16M de possibilités par seconde pour une
chaine de 24 chars (quand il est bien paramétré)... là il faut tester
148 chars... ça revient à peu près à dire (les experts en maths me
corrigeront peut-être) qu'il faut tester (un total maximum de) 256
puissance 148 possibilités pour être certain de tester/trouver la
bonne chaine...
Maintenant, il faut considérer aussi que le cracker potentiel utilise
un cluster constitué de toutes les machines disponibles sur la planète
et qu'elles tournent toutes 10 fois plus vite qu'aujourd'hui (on lui
laisse le bénéfice des moyens techniques maximum) donc difficile de
faire une estimation valable (pour moi en tous cas). Disons simplement
"un certain temps" (cf. un sketche bien connu)
PS: c'est vrai que c'est pas toujours facile de te lire, quand tu fais
une réponse le texte original n'est pas indenté (on ne sait plus qui
parle) même si tu met tes initiales c'est un peu pénible de faire
visuellement le tri... et là en plus les caractères accentués et/ou
spéciaux n'apparaissent plus dans tes posts donc galère à lire... mais
que se passe t-il ? Ton lecteur de news te ferait-il des misères ?
>
> Il tait une fois au royaume des f es, Phil, un jeune lutin des bois et
> Fanny, une petite f e des framboises que le destin avait fait se rencontrer.
>
> a fait 148 caract res :-) Combien de temps pour casser a ?
Bonne question ! Pas mal d'années certainement avec les moyens
actuels ? ... Pour te donner une idée mon PC perso peut tester en
brute force entre 1M et 16M de possibilités par seconde pour une
chaine de 24 chars (quand il est bien paramétré)... là il faut tester
148 chars... ça revient à peu près à dire (les experts en maths me
corrigeront peut-être) qu'il faut tester (un total maximum de) 256
puissance 148 possibilités pour être certain de tester/trouver la
bonne chaine...
Maintenant, il faut considérer aussi que le cracker potentiel utilise
un cluster constitué de toutes les machines disponibles sur la planète
et qu'elles tournent toutes 10 fois plus vite qu'aujourd'hui (on lui
laisse le bénéfice des moyens techniques maximum) donc difficile de
faire une estimation valable (pour moi en tous cas). Disons simplement
"un certain temps" (cf. un sketche bien connu)
PS: c'est vrai que c'est pas toujours facile de te lire, quand tu fais
une réponse le texte original n'est pas indenté (on ne sait plus qui
parle) même si tu met tes initiales c'est un peu pénible de faire
visuellement le tri... et là en plus les caractères accentués et/ou
spéciaux n'apparaissent plus dans tes posts donc galère à lire... mais
que se passe t-il ? Ton lecteur de news te ferait-il des misères ?
Philippe Lheureux
May 9, 2012, 10:24:44 AM5/9/12
to
Je ne te parle pas de l'affirmer, mais de le prouver.
HashMask Lite est cassable uniquement par attaque en force brute sur la clé.
Ce qui si la clé est une phrase de 200 caractères environ , risque de
prendre un temps fou.
L'attaque n'est pas possible sur les x hash concaténés pour faire le masque
intermédiaire ( qui contient la clé salée) car SHA-256 n'est pas réversible.
Christophe HENRY
May 9, 2012, 12:54:39 PM5/9/12
to
Le Wed, 09 May 2012 16:24:44 +0200, Philippe Lheureux a écrit :
> Je ne te parle pas de l'affirmer, mais de le prouver.
>
> LP : Voila mes arguments
>
> HashMask Lite est cassable uniquement par attaque en force brute sur la
> clé. Ce qui si la clé est une phrase de 200 caractères environ , risque
> de prendre un temps fou.
> (...)
> Je ne te parle pas de l'affirmer, mais de le prouver.
>
> LP : Voila mes arguments
>
> HashMask Lite est cassable uniquement par attaque en force brute sur la
> clé. Ce qui si la clé est une phrase de 200 caractères environ , risque
> de prendre un temps fou.
Non. Il est cassable si on réutilise deux fois la clé.
Christophe HENRY
May 9, 2012, 12:59:59 PM5/9/12
to
Le Wed, 09 May 2012 08:34:31 +0200, Philippe Lheureux a écrit :
> (...)
même clé sans risquer la cryptanalyse.
> J'ai montré plus haut que c'était bien plus efficace. C'est une faille à
> supprimer de toute urgence. Autre exemple, les extensions de fichier
> sont souvent à 3 lettres dans le suffixe, la lettre précédente étant le
> point. On connaît donc toujours, ou presque, le 4ème dernier caractère
> clair.
>
> LP > ce n'est pas plus une faille que dans le challenge ou tu connais
> 99.99% du texte et ou tu n'arrives pas à retrouver la suite.
Si. C'est un mot probable, et c'est la petite fissure qui grandira avec
le temps.
> Admettons que l'extension de fichier soit DOC .. tu vas trouver quoi ..
> le masque de 3 lettres :-) genre 4F12e1 et alors ? en quoi cela va-t-il
> te renseigner sur le numéro précédent cette partie de sous-masque ?
Ça guide une recherche exhaustive des clés. On ne sait pas de quoi demain
sera fait.
> (...)
>> Non. On refait inconditionnellement le masque si on a un clair et un
>> chiffré. On sais le reconstituer si on a plusieurs chiffrés, en
>> utilisant la cryptanalyse du Vernam.
>
> LP > Dans le challenge je t'ai chiffré 3 fois le même texte avec des
> clés différentes .. j'attends toujours la partie manquante :-)
J'ai cassé ton chiffrement. On ne peut pas utiliser deux fois de suite la
>> chiffré. On sais le reconstituer si on a plusieurs chiffrés, en
>> utilisant la cryptanalyse du Vernam.
>
> LP > Dans le challenge je t'ai chiffré 3 fois le même texte avec des
> clés différentes .. j'attends toujours la partie manquante :-)
même clé sans risquer la cryptanalyse.
> J'ai montré plus haut que c'était bien plus efficace. C'est une faille à
> supprimer de toute urgence. Autre exemple, les extensions de fichier
> sont souvent à 3 lettres dans le suffixe, la lettre précédente étant le
> point. On connaît donc toujours, ou presque, le 4ème dernier caractère
> clair.
>
> LP > ce n'est pas plus une faille que dans le challenge ou tu connais
> 99.99% du texte et ou tu n'arrives pas à retrouver la suite.
le temps.
> Admettons que l'extension de fichier soit DOC .. tu vas trouver quoi ..
> le masque de 3 lettres :-) genre 4F12e1 et alors ? en quoi cela va-t-il
> te renseigner sur le numéro précédent cette partie de sous-masque ?
sera fait.
Christophe HENRY
May 9, 2012, 1:11:13 PM5/9/12
to
Le Tue, 08 May 2012 23:39:38 -0700, dimitri.mestdagh a écrit :
> Hmmm... pour cela il faudrait que les deux chiffrés l'aient été avec la
> même clé, mais en plus qu'ils fassent rigoureusement la même taille,
> autant en ce qui concerne le contenu que le nom du fichier...
> mais je concède, c'est déjà une faille en soi.
Pas vraiment. Et même, au contraire. Avec deux couples clair/chiffrés de
> Hmmm... pour cela il faudrait que les deux chiffrés l'aient été avec la
> même clé, mais en plus qu'ils fassent rigoureusement la même taille,
> autant en ce qui concerne le contenu que le nom du fichier...
> mais je concède, c'est déjà une faille en soi.
longueur différentes, on révèle plusieurs octets de la clé.
>> (...)
> Parfait alors ? ? Si l'outil n'est pas sensible à d'autres attaques que
> celles applicables sur la méthode du masque jetable (excepté la
> brute-force sur la clé) alors le challenge est remporté (c'était le but
> initial, le masque jetable étant apparemment la méthode la plus sûre au
> niveau sécurité).
Le challenge est perdu, au contraire. J'ai démontré et appliqué une façon
> celles applicables sur la méthode du masque jetable (excepté la
> brute-force sur la clé) alors le challenge est remporté (c'était le but
> initial, le masque jetable étant apparemment la méthode la plus sûre au
> niveau sécurité).
de reconstituer un clair en ne connaissant que le chiffré. J'ai prouvé
que le chiffré à décrypter commençait exactement par le clair qui était
offert. C'est déjà une grande information. Ensuite, dans les cas plus
réalistes, le clair serait quasi complètement découvert.
>> (...)
> Effectivement, mais l'outil ne peut pas garantir une quelconque sécurité
> en cas de réutilisation d'une clé par l'une ou l'autre partie (ce qui
> doit quand même poser des problèmes de gestion administrative je
> concède). Il doit quand même y avoir quelque chose à améliorer aussi de
> ce côté là...
Oui. Ça fait bien plus de 30 ans qu'on sait faire des clés utilisables
> en cas de réutilisation d'une clé par l'une ou l'autre partie (ce qui
> doit quand même poser des problèmes de gestion administrative je
> concède). Il doit quand même y avoir quelque chose à améliorer aussi de
> ce côté là...
des deux côtés sans interception (presque) possible. Mais cette solution
a son propre problème.... Pour ce faire, il faudra abandonner la
transposition et la substitution.
>> J'ai montré plus haut que c'était bien plus efficace. C'est une faille
>> à supprimer de toute urgence. Autre exemple, les extensions de fichier
>> sont souvent à 3 lettres dans le suffixe, la lettre précédente étant le
>> point.
>> On connaît donc toujours, ou presque, le 4ème dernier caractère clair.
>
> Et au mieux ça nous permet de reconstituer les 4 derniers caractères du
> masque, ce qui ne semble pas vraiment exploitable.
En général, c'est maigre. Mais lorsque le contexte est connu, cela
constitue un indice.
Christophe HENRY
May 9, 2012, 1:15:12 PM5/9/12
to
Le Wed, 09 May 2012 09:14:12 +0200, Philippe Lheureux a écrit :
> Ok. Il va falloir que Philippe retravaille le principe donc :)
>
> LP : Surtout pas , il est parfait comme il est ! La preuve Christophe
> n'a pas pu déchiffrer la suite du masque malgré 99,99% de connu.
J'ai une autre vision à suggérer. Un seul gus qui fait ça en dilettante
> Ok. Il va falloir que Philippe retravaille le principe donc :)
>
> LP : Surtout pas , il est parfait comme il est ! La preuve Christophe
> n'a pas pu déchiffrer la suite du masque malgré 99,99% de connu.
qui décalque 99,99% du chiffré, ça devrait plutôt indiquer que le chiffre
est défectueux. Pour être honnête, je n'ai pas un niveau élevé en
cryptanalyse, donc le fait que je n'y arrive pas ne donne aucun indice
sérieux.
>
>
> Hmmm... pour cela il faudrait que les deux chiffrés l'aient été avec la
> même clé, mais en plus qu'ils fassent rigoureusement la même taille,
> autant en ce qui concerne le contenu que le nom du fichier...
> mais je concède, c'est déjà une faille en soi.
>
> LP : L'extension du fichier n'est pas plus un problème que de commencer
> une lettre avec la date ou Monsieur :-)
Christophe HENRY
May 9, 2012, 1:19:27 PM5/9/12
to
Le Wed, 09 May 2012 08:04:46 +0200, Philippe Lheureux a écrit :
> (...)
violées, tout s'écroule.
>> J'ai posté mon article ici :
>> [http://blog.sbgodin.fr/index.php?2012/05/09/00/29/56-cryptanalyse-de-
>> hashmask]
> LP : Je vais aller voir ça mais ce qui m'inquiètes un peu c'est que tu
> laisses sous entendre une faiblesse dans HashMask qui en fait n'est rien
> d'autre qu'une faiblesse propre à tous les masques jetables
En effet. HashMask hérite de la faiblesse principale du masque jetable.
> (...)
> (...)
> LP : Donc le masque jetable considéré comme le seul système sur ... est
> faible d'après toi :-)
Tout à fait. Lorsque les conditions d'utilisation du masque jetable sont
> faible d'après toi :-)
violées, tout s'écroule.
>> J'ai posté mon article ici :
>> [http://blog.sbgodin.fr/index.php?2012/05/09/00/29/56-cryptanalyse-de-
>> hashmask]
> LP : Je vais aller voir ça mais ce qui m'inquiètes un peu c'est que tu
> laisses sous entendre une faiblesse dans HashMask qui en fait n'est rien
> d'autre qu'une faiblesse propre à tous les masques jetables
> (...)
> Il est bien précisé qu'une clé ne doit être utilisée qu'une seule fois .
> HashMask a justement été crée pour simplifier l'échange de clés. Au lieu
> de transmettre un masque hyper long , on le reconstruit à partir d'une
> clé hyper courte.
C'est en effet la bonne trouvaille de l'algorithme.
> HashMask a justement été crée pour simplifier l'échange de clés. Au lieu
> de transmettre un masque hyper long , on le reconstruit à partir d'une
> clé hyper courte.
Message has been deleted
Christophe HENRY
May 9, 2012, 2:15:46 PM5/9/12
to
Le Wed, 09 May 2012 20:00:00 +0200, Dany Boonce a écrit :
> Bonjour,
>
> Christophe HENRY <news:joe8uu$2geh$5...@saria.nerim.net>
> algo, en plus de savoir "crypter", sait aussi "décrypter" ?
Oui. J'avais demandé à pouvoir travailler sur une implémentation de
référence ainsi que sur le code source avec une licence libre. J'ai
vérifié que le chiffré produit à partir du site web de Dimitri pouvait
être déchiffré par ma version locale.
> (...)
> Vous avez à faire à du très très redoutable !!!
Je confirme ;-) Mais il a bien progressé. Le premier algorithme que j'ai
cassé, CENA, était bien tortueux. Le second est bien plus propre et
repose sur une idée originale d'il y a... longtemps.
En passant, voici un lien vers un article évoquant la problématique du
moment : http://www.di.ens.fr/~bresson/P12-M1/P12-M1-Crypto_8.pdf
En résumé, pas d'avancée pertinente concernant les algorithmes de
chiffrement par flot.
> Bonjour,
>
> Christophe HENRY <news:joe8uu$2geh$5...@saria.nerim.net>
>
>> C'est en effet la bonne trouvaille de l'algorithme.
>
> Juste comme ça en passant... Vous vous êtes assuré que le merveilleux
>> C'est en effet la bonne trouvaille de l'algorithme.
>
> algo, en plus de savoir "crypter", sait aussi "décrypter" ?
Oui. J'avais demandé à pouvoir travailler sur une implémentation de
référence ainsi que sur le code source avec une licence libre. J'ai
vérifié que le chiffré produit à partir du site web de Dimitri pouvait
être déchiffré par ma version locale.
> (...)
> Vous avez à faire à du très très redoutable !!!
Je confirme ;-) Mais il a bien progressé. Le premier algorithme que j'ai
cassé, CENA, était bien tortueux. Le second est bien plus propre et
repose sur une idée originale d'il y a... longtemps.
En passant, voici un lien vers un article évoquant la problématique du
moment : http://www.di.ens.fr/~bresson/P12-M1/P12-M1-Crypto_8.pdf
En résumé, pas d'avancée pertinente concernant les algorithmes de
chiffrement par flot.
Philippe Lheureux
May 9, 2012, 2:30:03 PM5/9/12
to
Non. Il est cassable si on réutilise deux fois la clé.
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
LP>
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
Le masque jetable aussi et pourtant il est reconnu comme le seul système
vraiment sur :-) Avec HashMask , la moindre modification de caractère de la
clé produit un masque radicalement différent . Cela autorise
l'incrémentation de la clé.
Exemple :
Le lutin vert se promène dans la forêt.
Le lutin vert se promène dans la forêt. 1
Le lutin vert se promène dans la forêt. 2
Le lutin vert se promène dans la forêt. 3
Le lutin vert se promène dans la forêt. 1500
Le lutin vert se promène dans la forêt. etc..
A chaque fois le masque produit sera complètement différent pourtant
l'essentiel de la clé reste identique.
La transmission du masque est donc simplifiée par une clé courte et
incrémentable.
Ps : AES aussi est cassable si tu me donnes la clé :-)
Philippe Lheureux
May 9, 2012, 2:35:49 PM5/9/12
to
J'ai cassé ton chiffrement. On ne peut pas utiliser deux fois de suite la
même clé sans risquer la cryptanalyse.
doit être utilisée qu'une seule fois ... voir www.superlutin.net/cec.html
Même moi je n'oserais pas écrire que j'ai cassé le masque jetable sous
prétexte qu'on ne peut pas l'utiliser deux fois de suite sans risquer la
cryptanalyse.
> LP > ce n'est pas plus une faille que dans le challenge ou tu connais
> 99.99% du texte et ou tu n'arrives pas à retrouver la suite.
Si. C'est un mot probable, et c'est la petite fissure qui grandira avec
le temps.
> Admettons que l'extension de fichier soit DOC .. tu vas trouver quoi ..
> le masque de 3 lettres :-) genre 4F12e1 et alors ? en quoi cela va-t-il
> te renseigner sur le numéro précédent cette partie de sous-masque ?
Ça guide une recherche exhaustive des clés. On ne sait pas de quoi demain
sera fait.
deux fois moins de clés concaténés pour produire le même masque... et ton
extension de fichier noyée dans le masque :-)
Philippe Lheureux
May 9, 2012, 2:38:26 PM5/9/12
to
J'ai une autre vision à suggérer. Un seul gus qui fait ça en dilettante
qui décalque 99,99% du chiffré, ça devrait plutôt indiquer que le chiffre
est défectueux. Pour être honnête, je n'ai pas un niveau élevé en
cryptanalyse, donc le fait que je n'y arrive pas ne donne aucun indice
sérieux.
LP > tu es déjà plus doué que moi :-) c'est déjà pas si mal non ?
qui décalque 99,99% du chiffré, ça devrait plutôt indiquer que le chiffre
est défectueux. Pour être honnête, je n'ai pas un niveau élevé en
cryptanalyse, donc le fait que je n'y arrive pas ne donne aucun indice
sérieux.
> LP : L'extension du fichier n'est pas plus un problème que de commencer
> une lettre avec la date ou Monsieur :-)
Je suis tout à fait d'accord. Ça reste tout de même un problème.
Philippe Lheureux
May 9, 2012, 2:42:04 PM5/9/12
to
Le challenge est perdu, au contraire. J'ai démontré et appliqué une façon
de reconstituer un clair en ne connaissant que le chiffré. J'ai prouvé
que le chiffré à décrypter commençait exactement par le clair qui était
offert. C'est déjà une grande information. Ensuite, dans les cas plus
réalistes, le clair serait quasi complètement découvert.
XOR ou quoi ?
Philippe Lheureux
May 9, 2012, 2:46:21 PM5/9/12
to
> LP : Donc le masque jetable considéré comme le seul système sur ... est
> faible d'après toi :-)
Tout à fait. Lorsque les conditions d'utilisation du masque jetable sont
violées, tout s'écroule.
LP : idem pour le système de crypto le plus sur du monde si tu laisse
> faible d'après toi :-)
Tout à fait. Lorsque les conditions d'utilisation du masque jetable sont
violées, tout s'écroule.
trainer les clés.
En effet. HashMask hérite de la faiblesse principale du masque jetable.
> (...)
> Il est bien précisé qu'une clé ne doit être utilisée qu'une seule fois .
> HashMask a justement été crée pour simplifier l'échange de clés. Au lieu
> de transmettre un masque hyper long , on le reconstruit à partir d'une
> clé hyper courte.
C'est en effet la bonne trouvaille de l'algorithme.
savoir si le fait de crypter x fois la même clé avec le hash précédent
générait une faille quelconque dans la génération des hash.
Christophe HENRY
May 9, 2012, 2:48:45 PM5/9/12
to
Hello,
Maintenant que le challenge est terminé, peux-tu fournir ici la clé de
chiffrement utilisée ?
Maintenant que le challenge est terminé, peux-tu fournir ici la clé de
chiffrement utilisée ?
Philippe Lheureux
May 9, 2012, 2:50:59 PM5/9/12
to
Juste comme ça en passant... Vous vous êtes assuré que le
merveilleux algo, en plus de savoir "crypter", sait aussi
"décrypter" ?
http://dimooz.free.fr/void/hashmask/v-0-1/index.php
Parce que Rantanplan a déjà donné là-dedans il y a quelques
années...
Mais cette fois-là il avait abandonné le troll très rapidement.
Et dans un autre genre d'idée, pour bien cerner le personnage,
demandez-lui son explication des mystères de la Pyramide de
Khéops...
LP: La voila http://autospeed.celeonet.fr/khufu/IMG/pdf/5plafonds.pdf
Quelque chose à redire ?
Vous avez à faire à du très très redoutable !!!
Philippe Lheureux
May 9, 2012, 2:57:05 PM5/9/12
to
Je confirme ;-) Mais il a bien progressé. Le premier algorithme que j'ai
cassé, CENA, était bien tortueux. Le second est bien plus propre et
repose sur une idée originale d'il y a... longtemps.
LP : On l'a épuré au maximum pour ne laisser que la porte blindée.
cassé, CENA, était bien tortueux. Le second est bien plus propre et
repose sur une idée originale d'il y a... longtemps.
En passant, voici un lien vers un article évoquant la problématique du
moment : http://www.di.ens.fr/~bresson/P12-M1/P12-M1-Crypto_8.pdf
En résumé, pas d'avancée pertinente concernant les algorithmes de
chiffrement par flot.
chiffrement par flot , pour moi c'est juste un chiffrement symétrique.
J'aime sa simplicité et sa robustesse mais je n'aime pas avoir une clé par
fichier car même si c'est facile à utiliser , c'est chiant à gérer.
CENA était meilleur pour ça , le même fichier chiffré toujours avec la même
clé donnait des résultats différents sans géner pour autant le déchiffrage
... malheureusement il multipliait par 8 la taille du chiffré par rapport au
clair.
dimitri.mestdagh
May 9, 2012, 5:00:13 PM5/9/12
to
Je ne crois pas que Philippe avait la prétention de révolutionner la
cryptographie au point de faire mieux que le chiffre de Vernam...
L'idée c'était de faire une clé plus simple (et ainsi éviter une
longueur de clé à transmettre qui soit équivalente au clair) sans pour
autant que l'outil présente des vulnérabilités supplémentaires.
Maintenant, il serait bien de pousser l'idée jusqu'à faire un système
qui respecte ces mêmes principes sans pour autant nécessiter un
changement de clé à chaque échange. Il va falloir se creuser la
tête !
* Le PDF sur la crypto nous remet dans le droit chemin (façon de
parler, il resitue bien les bases), intéressant à lire en tous cas.
Merci Christophe !
cryptographie au point de faire mieux que le chiffre de Vernam...
L'idée c'était de faire une clé plus simple (et ainsi éviter une
longueur de clé à transmettre qui soit équivalente au clair) sans pour
autant que l'outil présente des vulnérabilités supplémentaires.
Maintenant, il serait bien de pousser l'idée jusqu'à faire un système
qui respecte ces mêmes principes sans pour autant nécessiter un
changement de clé à chaque échange. Il va falloir se creuser la
tête !
* Le PDF sur la crypto nous remet dans le droit chemin (façon de
parler, il resitue bien les bases), intéressant à lire en tous cas.
Merci Christophe !
Philippe Lheureux
May 9, 2012, 5:47:14 PM5/9/12
to
Ou son explication à propos des missions apollo...
La voila .. merci google livres :-)
http://books.google.fr/books?id=ACsrPlV6JAsC&printsec=frontcover&dq=lumi%C3%A8res+sur+la+lune&hl=fr&sa=X&ei=-uSqT_KNNsKt0QX4-s2MBA&ved=0CEEQ6AEwAA#v=onepage&q=lumi%C3%A8res%20sur%20la%20lune&f=false
ça te pose un problème ?
dimitri.mestdagh
May 9, 2012, 7:57:25 PM5/9/12
to
>> Ou son explication à propos des missions apollo...
>
> La voila .. merci google livres :-)
Heu... et si on arrêtait le hors sujet ?
>
> La voila .. merci google livres :-)
Philippe (ou qui que ce soit) aurais tu une idée pour permettre des
échanges multiples avec une même clé sur ce même principe de
chiffrement ? et ainsi rendre le hashmask exploitable pour des
applications réseau par exemple ? sans multiplier la taille du
chiffré, sans créer de vulnérabilité supplémentaire, et en respectant
toujours une taille de clé standard, bien sûr...
0 new messages