Hashmask Lite ... futur Challenge.

Le Tue, 08 May 2012 18:49:38 -0700, dimitri.mestdagh a écrit :

(...)
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
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
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.

(...)
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.

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 !

--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr

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 :)

Cela signifie que l'algorithme est inutilisable en pratique. Pour évite r
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.

Là on tourne en rond... tout ça n'est vrai que si on s'obstine à
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é d e
vraie utilité à connaître ce dernier segment. Par contre, on peut
extraire des informations *sans* connaître le masque. Par exemple, en X OR-
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", "xl s",
"XLS", etc. Sans compter la possibilité de décrypter le nom du fichie r.

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.

(...) 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é, l a
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 cla ir et un
chiffré. On sais le reconstituer si on a plusieurs chiffrés, en utili sant
la cryptanalyse du Vernam.

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é).

> - reconstituer le masque ne représente pas d'intérêt si l'utilisa teur
> 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é prob able
d'une personne s'ils sont plusieurs à communiquer chacun avec sa clé, par
exemple.

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 par tie
(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 faill e à
supprimer de toute urgence. Autre exemple, les extensions de fichier sont
souvent à 3 lettres dans le suffixe, la lettre précédente étant l e point.
On connaît donc toujours, ou presque, le 4ème dernier caractère cla ir.

Et au mieux ça nous permet de reconstituer les 4 derniers caractères
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'attentio n
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 vraimen t
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étenc es
actuelles feraient l'affaire... Mais ici, mon temps est épuisé. Et mo i
aussi ;-)

Merci encore pour les réponses. Je sais que ça prend forcément
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 !

Quelqu'un d'entre vous a-t-il connaissance d'un logiciel de chiffrement b asé
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.

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.


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 :-)

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é).

LP : Oui remporté tant qu'on aura pas démontré la reversibilité du SHA-256
:-)


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).

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 ?

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
pas .

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.

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.

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.
(...)

Non. Il est cassable si on réutilise deux fois la clé.

--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr

Le Wed, 09 May 2012 08:34:31 +0200, Philippe Lheureux a écrit :

(...)

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
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.


--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr

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
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
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
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
FR EO EN - http://www.sbgodin.fr

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
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 :-)

Je suis tout à fait d'accord. Ça reste tout de même un problème.

--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr