HashMask 512 Schémas de principe Chiffrement/Déchiffrement

Le 11/05/2012 17:16, Philippe Lheureux a écrit :

Pour le chiffrement : http://www.superlutin.net/hashmask_c.pdf
Pour le déchiffrement : http://www.superlutin.net/hashmask_d.pdf

Qu'en pensez-vous ?

Ce système de chiffrement a les mérites d'être exposé clairement,
de pouvoir fonctionner (on peut déchiffrer un message), et il me
semble de protéger l'intégrité du message.

Parmi ses défauts:

- Le hash du texte clair est transmis en clair, ce qui compromet
la confidentialité des messages courts ou presque complètement
connus. On peut par exemple savoir si le clair est "oui" en
vérifiant si le chiffré commence par le SHA-256 de "oui". Les
messages courts ou courants sont donc extrêmement vulnérables
à une simple "rainbow table", et plus généralement les messages
presque complètement connus très vulnérables à la force brute.

- Le système n'est pas très efficace puisqu'il y a un round de
SHA-512 et un round de SHA-256 pour chaque 512 bits de clair.
Des systèmes comme AES-GCM sont bien plus rapides.

- La sécurité du système dépend de plusieurs propriétés de SHA-512
qui ne sont pas parmi ses objectifs de conception. En particulier
que connaissant de nombreuses paires (x,SHA-512(x#k)) il n'est
pas possible de remonter à k.

Francois Grieu

Ce système de chiffrement a les mérites d'être exposé clairement,
de pouvoir fonctionner (on peut déchiffrer un message), et il me
semble de protéger l'intégrité du message.

Parmi ses défauts:

- Le hash du texte clair est transmis en clair, ce qui compromet
la confidentialité des messages courts ou presque complètement
connus. On peut par exemple savoir si le clair est "oui" en
vérifiant si le chiffré commence par le SHA-256 de "oui". Les
messages courts ou courants sont donc extrêmement vulnérables
à une simple "rainbow table", et plus généralement les messages
presque complètement connus très vulnérables à la force brute.

LP > c'est vrai que pour les messages courts , ça craint .. on va y
remédier.

- Le système n'est pas très efficace puisqu'il y a un round de
SHA-512 et un round de SHA-256 pour chaque 512 bits de clair.
Des systèmes comme AES-GCM sont bien plus rapides.

LP> l'objectif est la sécurité , un algo moins rapide sera aussi plus lent à
attaquer par force brute. Ceci dit , pour comparer , il faudrait une
implémentation en C ou C++
parce que la , avec le PHP , on ne se rend pas compte de la vitesse réelle.


- La sécurité du système dépend de plusieurs propriétés de SHA-512
qui ne sont pas parmi ses objectifs de conception. En particulier
que connaissant de nombreuses paires (x,SHA-512(x#k)) il n'est
pas possible de remonter à k.

LP> Tu as plus vite fait d'essayer d'attaquer la clé en force brute plutôt
que de la retrouver dans le hash car elle est toujours et salée par le
résultat précédent.

Francois Grieu

Merci ..

- Le hash du texte clair est transmis en clair, ce qui compromet
la confidentialité des messages courts ou presque complètement
connus. On peut par exemple savoir si le clair est "oui" en
vérifiant si le chiffré commence par le SHA-256 de "oui". Les
messages courts ou courants sont donc extrêmement vulnérables
à une simple "rainbow table", et plus généralement les messages
presque complètement connus très vulnérables à la force brute.

Effectivement c'est un véritable problème pour les messages courts...
système à revoir donc.

- Le système n'est pas très efficace puisqu'il y a un round de
SHA-512 et un round de SHA-256 pour chaque 512 bits de clair.
Des systèmes comme AES-GCM sont bien plus rapides.

En fait non... (le schéma doit être à revoir je suppose, l'explicatio n
du principe doit être mal faite ?)
Dans la réalité, il y a seulement un round de SHA-256 par fichier
clair ou chiffré, et juste un round de SHA-512 pour 512 bits de clair.
Et non pas 2 hashes par tour.

- La sécurité du système dépend de plusieurs propriétés de SH A-512
qui ne sont pas parmi ses objectifs de conception. En particulier
que connaissant de nombreuses paires (x,SHA-512(x#k)) il n'est
pas possible de remonter à k.

Oui l'idée était justement d'utiliser les fonctions de hachages dans
un autre but que celui pour lequel elles ont été conçues. Cependant
l'algo pourrait être employé avec d'autres fonctions de hash que
SHA... Et sinon oui, tout repose sur la non-réversibilité des hash. Si
SHA-512 est réversible, la sécurité du système tombe à l'eau.

Les remarques ont bien été prises en compte.
Désormais, plus de hash du fichier original dans le fichier chiffré,
donc plus vraiment de possibilité d'utiliser les "rainbow tables".

On utilise aussi un crc32 plutôt qu'un SHA-256 pour vérifier
l'intégrité du fichier maintenant.

Avec le nouveau système, on peut chiffrer presque indéfiniment le mêm e
fichier avec la même clé sans jamais obtenir le même fichier
chiffré... Ca aussi c'est une bonne amélioration :)

Merci pour les remarques, ça fait avancer le projet !

Parmi ses défauts:

- Le hash du texte clair est transmis en clair, ce qui compromet
la confidentialité des messages courts ou presque complètement
connus. On peut par exemple savoir si le clair est "oui" en
vérifiant si le chiffré commence par le SHA-256 de "oui". Les
messages courts ou courants sont donc extrêmement vulnérables
à une simple "rainbow table", et plus généralement les messages
presque complètement connus très vulnérables à la force brute.

Francois Grieu

LP > Nous venons de remédier à ce problème. Maintenant il y a un vecteur
d'initialisation aléatoire , complètement indépendant du texte clair et de
longueur variable.
De plus , le hash pour la vérification de l'intégrité est inclus dans le
chiffré.

http://dimooz.free.fr/void/hashmask/hashmask512/img/chiffrement.png

http://dimooz.free.fr/void/hashmask/hashmask512/img/chiffrement.png

et le logiciel nouvelle version est dispo sur
http://dimooz.free.fr/void/hashmask/

Maintenant si l'on chiffre deux fois le même clair avec la même clé , on
obtient des résultats totalement différents. De plus , le hash du fichier
clair est chiffré.
On s'approche de la perfection non ? :-)

Le 14/05/2012 13:05, dimitri.mestdagh a écrit :

Francois Grieu a écrit:

- Le système n'est pas très efficace puisqu'il y a un round de
SHA-512 et un round de SHA-256 pour chaque 512 bits de clair.
Des systèmes comme AES-GCM sont bien plus rapides.

En fait non... (le schéma doit être à revoir je suppose, l'explication
du principe doit être mal faite ?)
Dans la réalité, il y a seulement un round de SHA-256 par fichier
clair ou chiffré, et juste un round de SHA-512 pour 512 bits de clair.
Et non pas 2 hashes par tour.

SHA-256 se décompose en rounds; il y en a un pour chaque 512 bits de
clair, pour un seul résultat SHA-256. Donc dans le système que j'ai
commenté, il y a bien un round de SHA-512 (un par SHA-512) et un
round de SHA-256 pour chaque 512 bits de clair (dans l'unique SHA-256).

- La sécurité du système dépend de plusieurs propriétés de SHA-512
qui ne sont pas parmi ses objectifs de conception. En particulier
que connaissant de nombreuses paires (x,SHA-512(x#k)) il n'est
pas possible de remonter à k.

Oui l'idée était justement d'utiliser les fonctions de hachages dans
un autre but que celui pour lequel elles ont été conçues. Cependant
l'algo pourrait être employé avec d'autres fonctions de hash que
SHA... Et sinon oui, tout repose sur la non-réversibilité des hash.
Si SHA-512 est réversible, la sécurité du système tombe à l'eau.

D'accord. Et je ne dis pas que SHA-512 n'a pas les propriétés requises,
seulement que cette fonction n'a ps été conçue avec pour objectif
d'avoir ces propriétés.

François Grieu

SHA-256 se décompose en rounds; il y en a un pour chaque 512 bits de
clair, pour un seul résultat SHA-256. Donc dans le système que j'ai
commenté, il y a bien un round de SHA-512 (un par SHA-512) et un
round de SHA-256 pour chaque 512 bits de clair (dans l'unique SHA-256).

Ah ok, je n'avais pas compris ça. On a remplacé le hash SHA-256 par un
crc32 dont le résultat est maintenant chiffré pour éviter de
transmettre l'info en clair, ce qui constituait une faille assez
énorme comme tu l'as fait remarquer. Reste à voir si le crc32 est
aussi gourmand en cycles d'exécution que SHA-256 ? (je suppose que
non...)

D'accord. Et je ne dis pas que SHA-512 n'a pas les propriétés requise s,
seulement que cette fonction n'a ps été conçue avec pour objectif
d'avoir ces propriétés.

Oui, c'est bien un détournement de son utilité première. Je crois qu'
AES sera dur à battre en termes de vitesse d'exécution, il faudra
toutefois que je code l'outil en langage C pour comparer efficacement.
En attendant, on a comparé les chiffrements issus de l'outil et ceux
produits par AES, on gagne (légèrement) en volume pour chaque fichier
chiffré. C'est plutôt encourageant pour nous pour l'instant.

Le 14/05/2012 22:35, Philippe Lheureux a écrit :

Nous venons de remédier à ce problème. Maintenant il y a un vecteur
d'initialisation aléatoire , complètement indépendant du texte clair
et de longueur variable.
De plus, le hash pour la vérification de l'intégrité est inclus dans
le chiffré.

http://dimooz.free.fr/void/hashmask/hashmask512/img/chiffrement.png
http://dimooz.free.fr/void/hashmask/hashmask512/img/dechiffrement.png

Contrairement au système précédent, celui-ci
- assure (il me semble) la protection de la confidentialité du message,
y compris court ou/et presque complètement connu, sous réserve de
certaines hypothèses plausibles sur SHA-512, que IV ne soit pas
réutilisé (ce qui est improbable avant quelques milliards de
messages), et que la clé soit solide;
- mais n'assure plus la protection de l'intégrité du message par
rapport à une attaque modifiant le chiffré, ce qui semble pourtant
un des objectifs.

En effet, sans connaitre la clé, si l'on connais la longueur du clair
(ou de la clé), on peut modifier un bit du chiffré (correspondant au
changement d'un bit du clair) et modifier la partie du chiffré
correspondant au CRC pour corriger celui-ci, en utilisant la propriété
vérifiée par tout CRC digne de ce nom:
CRC(X^Y^Z) = CRC(X)^CRC(Y)^CRC(Z) où X Y Z ont le même taille
[appliquée avec X=clair, Y=changement désiré au clair, Z=tout à zéro],
et la linéarité du XOR utilisé pour la transformation clair<->chiffré.

Par exemple, si le chiffré est un exécutable, on peut le corrompre
légèrement; si l'on suppose que le clair commence par "oui" on peut
le changer en "non"; si l'on a obtenu un message chiffré et son clair,
il est possible de faire un message chiffré avec le clair que l'on
désire (pourvu qu'il ne soit pas plus long).


Note: en cryptographie moderne (depuis en gros 15 ans) il est d'usage
d'indiquer avec un système ses objectifs de sécurité, et au moins une
ébauche de preuve qu'ils sont atteints sous réserve de certaines
hypothèses également énoncées, par exemple selon cette méthodologie:
http://cseweb.ucsd.edu/~mihir/papers/ro.pdf

Francois Grieu

Oups

Comment a t-on pu passer à côté de ça ? hihi ça semble tellement
évident pourtant...
En effet, trop simple de corrompre le fichier en trafiquant la chaine
du crc ! j'aurais du le voir tout de suite.

Merci pour le lien, ça nous remet dans le droit chemin au niveau de la
présentation à fournir.
Finalement, je me demande si l'usage d'un algo tiers comme SHA est
bien pertinent. L'idéal aurait plutôt été de construire un algo de
hachage personnalisé, ce qui sera d'une toute autre difficulté :P

Heureusement qu'il y a encore des gens pour pointer les failles (aussi
énormes soient-elles), notre vision de la crypto semble (un peu ?)
biaisée au final.

Merci encore pour l'effort, Mr Grieu... Bien qu'après avoir cassé qqs
challenges de crypto, j'ai encore le sentiment d'être un nouveau né
après vous avoir lu !

cordialement

Oups

Comment a t-on pu passer à côté de ça ? hihi ça semble tellement
évident pourtant...
En effet, trop simple de corrompre le fichier en trafiquant la chaine
du crc ! j'aurais du le voir tout de suite.

LP: Oui mais on peut facilement corriger le problème en utilisant
SHA-256(texte clair concaténé avec la clé) comme contrôle d'intégrité à la
place de CRC-32
L'attaquant peut modifier un OUI en NON mais il ne pourra pas retrouver le
SHA-256 de NON+Clé puisqu'il n'a pas la clé :-)
Dans ce cas , toute modification du chiffré sera clairement visible


Merci pour le lien, ça nous remet dans le droit chemin au niveau de la
présentation à fournir.
Finalement, je me demande si l'usage d'un algo tiers comme SHA est
bien pertinent. L'idéal aurait plutôt été de construire un algo de
hachage personnalisé, ce qui sera d'une toute autre difficulté :P

LP: Je pense au contraire que ça serait une grosse bêtise de faire sa propre
fonction de hachage plutôt que d'utiliser celles reconnues comme sures par
la NSA. En créant notre propre fonction , on peut créer tout un tas de
failles exploitables sans même sans rendre compte.


Heureusement qu'il y a encore des gens pour pointer les failles (aussi
énormes soient-elles), notre vision de la crypto semble (un peu ?)
biaisée au final.

Merci encore pour l'effort, Mr Grieu... Bien qu'après avoir cassé qqs
challenges de crypto, j'ai encore le sentiment d'être un nouveau né
après vous avoir lu !

cordialement

LP: La remarque était judicieuse ... encore qu'il fallait être sur de la
position du OUI dans le chiffré :-) C'est corrigé !