Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
HashMask 512 Schémas de principe Chiffrement/Déchiffrement
27 views
Skip to first unread message
Philippe Lheureux
May 11, 2012, 11:16:45 AM5/11/12
to
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 ?
Pour le déchiffrement : http://www.superlutin.net/hashmask_d.pdf
Qu'en pensez-vous ?
Francois Grieu
May 14, 2012, 4:00:40 AM5/14/12
to
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
Philippe Lheureux
May 14, 2012, 6:00:52 AM5/14/12
to
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
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.
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.
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.
que de la retrouver dans le hash car elle est toujours et salée par le
résultat précédent.
Francois Grieu
Merci ..
dimitri.mestdagh
May 14, 2012, 7:05:19 AM5/14/12
to
> - 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...
> 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.
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.
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 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.
>
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.
dimitri.mestdagh
May 14, 2012, 12:49:51 PM5/14/12
to
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ême
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 !
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ême
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 !
Philippe Lheureux
May 14, 2012, 4:35:02 PM5/14/12
to
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 > 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 ? :-)
Francois Grieu
May 15, 2012, 3:21:42 AM5/15/12
to
Le 14/05/2012 13:05, dimitri.mestdagh a écrit :
> Francois Grieu a écrit:
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
> 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
>> 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.
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.
seulement que cette fonction n'a ps été conçue avec pour objectif
d'avoir ces propriétés.
François Grieu
dimitri.mestdagh
May 15, 2012, 4:42:00 AM5/15/12
to
> 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
> 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).
>
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 requises,
> seulement que cette fonction n'a ps été conçue avec pour objectif
> d'avoir ces propriétés.
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.
Francois Grieu
May 15, 2012, 7:04:21 AM5/15/12
to
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
> 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.
> 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
dimitri.mestdagh
May 15, 2012, 8:30:12 AM5/15/12
to
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
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
Philippe Lheureux
May 16, 2012, 3:25:04 AM5/16/12
to
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
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.
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
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
position du OUI dans le chiffré :-) C'est corrigé !
Francois Grieu
May 16, 2012, 3:50:54 AM5/16/12
to
Le 16/05/2012 09:25, Philippe Lheureux a écrit :
> 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é
> 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
Le système obtenu en remplaçant CRC-32 par SHA-256 dans le
système d'hier ne corrige que partiellement le problème de non
garantie de l'intégrité. Cette attaque là reste possible:
>> 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)
par M ^ (vrai clair) ^ (faux clair)
et la partie H du chiffré correspondant au SHA-256
par H ^ SHA-256(vrai clair) ^ SHA-256(faux clair)
Francois Grieu
Philippe Lheureux
May 16, 2012, 4:02:52 AM5/16/12
to
>> 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)
Yaka remplacer la partie M du chiffré correspondant au message
par M ^ (vrai clair) ^ (faux clair)
et la partie H du chiffré correspondant au SHA-256
par H ^ SHA-256(vrai clair) ^ SHA-256(faux clair)
Francois Grieu
LP > comme pour tout masque jetable , sauf que la, tu ne peux pas calculer
>> il est possible de faire un message chiffré avec le clair
>> que l'on désire (pourvu qu'il ne soit pas plus long)
Yaka remplacer la partie M du chiffré correspondant au message
par M ^ (vrai clair) ^ (faux clair)
et la partie H du chiffré correspondant au SHA-256
par H ^ SHA-256(vrai clair) ^ SHA-256(faux clair)
Francois Grieu
le SHA-256 du faux clair puisque tu n'as pas la clé :-)
Avant , le contrôle d'intégrité se faisait avec le CRC-32( texte clair ) et
maintenant avec le SHA-256( texte clair+clé)
Celui qui chiffre à la clé , celui qui déchiffre aussi ... mais pas
l'attaquant qui se retrouve dans l'impossibilité de modifier le chiffré sans
que cela se repère.
Francois Grieu
May 16, 2012, 6:15:23 AM5/16/12
to
CRC(texte clair) par SHA-256(texte clair *concaténé avec la clé*).
Cela constitue un MAC sans faille connue (mais sans preuve de
sécurité, contrairement à HMAC) et protège l'intégrité.
Mis à part que connaissant le clair et le chiffré de deux messages,
il est possible de construire un nouveau chiffré avec l'IV du second
message et le clair du premier, je ne vois plus d'attaque.
Francois Grieu
Philippe Lheureux
May 16, 2012, 8:24:13 AM5/16/12
to
Je n'avais pas vu que la nouvelle proposition était de remplacer
CRC(texte clair) par SHA-256(texte clair *concaténé avec la clé*).
Cela constitue un MAC sans faille connue (mais sans preuve de
sécurité, contrairement à HMAC) et protège l'intégrité.
Mis à part que connaissant le clair et le chiffré de deux messages,
il est possible de construire un nouveau chiffré avec l'IV du second
message et le clair du premier, je ne vois plus d'attaque.
Francois Grieu
LP>
CRC(texte clair) par SHA-256(texte clair *concaténé avec la clé*).
Cela constitue un MAC sans faille connue (mais sans preuve de
sécurité, contrairement à HMAC) et protège l'intégrité.
Mis à part que connaissant le clair et le chiffré de deux messages,
il est possible de construire un nouveau chiffré avec l'IV du second
message et le clair du premier, je ne vois plus d'attaque.
Francois Grieu
Je n'ai rien compris à cette dernière attaque !
Si je te chiffre deux messages clairs ( les mêmes ou deux différents ) avec
hashmask , tu vas avoir deux masques différents vu que le vecteur
d'initialisation ne sera pas le même. Si tu prends le VI du second et le
clair chiffré du premier , ça ne marchera pas car les masques seront
différents.
Est ce que tu peux m'expliquer ça un peu mieux
Merci.
Phil
Philippe Lheureux
May 16, 2012, 1:02:27 PM5/16/12
to
J'ai remis les schémas et le principe à jour sur www.superlutin.net/hmk.html
On a du changer le nom du logiciel car HashMasK était déjà pris.
Maintenant on a 3 lettres comme AES ... ça porte bonheur :-)
Maintenant que la version 0.3 est blindée , si quelqu'un voit une autre
attaque possible , il est le bienvenue.
Francois Grieu
May 21, 2012, 4:50:51 AM5/21/12
to
Le 16/05/2012 14:24, Philippe Lheureux a écrit, me quotant
www.superlutin.net/hmk.html
Je ne vois plus de raison que le système ne soit pas sur en
supposant que
1) clé K solide
2) VI non réutilisé
3) x->SHA-256(x#k) et x->SHA-512(x#k) sont indistinguables de
fonctions aléatoires pour qui ne connais pas k (où # désigne
la concaténation).
Cependant attention, SHA-256 et SHA-512 ne sont pas explicitement
conçus pour avoir ces propriétés, et il n'est pas évident que
connaissant de multiples paires (x,SHA-256(x#k)) où # désigne la
concaténation, il est impossible de remonter à k (ce serait une
attaque différentielle).
Le 1) est probablement le plus faible si K est mémorisable; pour
lutter contre ça il existe des solutions, voir PBKDF2:
http://www.ietf.org/rfc/rfc2898.txt
ou mieux scrypt
http://www.tarsnap.com/scrypt.html
François Grieu
>> Mis à part que connaissant le clair et le chiffré de deux messages,
>> il est possible de construire un nouveau chiffré avec l'IV du second
>> message et le clair du premier, je ne vois plus d'attaque.
>
>> il est possible de construire un nouveau chiffré avec l'IV du second
>> message et le clair du premier, je ne vois plus d'attaque.
>
> Je n'ai rien compris à cette dernière attaque !
>
> Si je te chiffre deux messages clairs ( les mêmes ou deux différents )
> avec hashmask , tu vas avoir deux masques différents vu que le vecteur
> d'initialisation ne sera pas le même. Si tu prends le VI du second et
> le clair chiffré du premier , ça ne marchera pas car les masques
> seront différents.
Euh... En effet, je le vois bien avec le nouveau schéma
>
> Si je te chiffre deux messages clairs ( les mêmes ou deux différents )
> avec hashmask , tu vas avoir deux masques différents vu que le vecteur
> d'initialisation ne sera pas le même. Si tu prends le VI du second et
> le clair chiffré du premier , ça ne marchera pas car les masques
> seront différents.
www.superlutin.net/hmk.html
Je ne vois plus de raison que le système ne soit pas sur en
supposant que
1) clé K solide
2) VI non réutilisé
3) x->SHA-256(x#k) et x->SHA-512(x#k) sont indistinguables de
fonctions aléatoires pour qui ne connais pas k (où # désigne
la concaténation).
Cependant attention, SHA-256 et SHA-512 ne sont pas explicitement
conçus pour avoir ces propriétés, et il n'est pas évident que
connaissant de multiples paires (x,SHA-256(x#k)) où # désigne la
concaténation, il est impossible de remonter à k (ce serait une
attaque différentielle).
Le 1) est probablement le plus faible si K est mémorisable; pour
lutter contre ça il existe des solutions, voir PBKDF2:
http://www.ietf.org/rfc/rfc2898.txt
ou mieux scrypt
http://www.tarsnap.com/scrypt.html
François Grieu
Philippe Lheureux
May 21, 2012, 2:51:50 PM5/21/12
to
Euh... En effet, je le vois bien avec le nouveau schéma
www.superlutin.net/hmk.html
Je ne vois plus de raison que le système ne soit pas sur en
supposant que
1) clé K solide
si elle se compose de caractères difficiles à mémoriser.
2) VI non réutilisé
LP : C'est la cas aussi et ce qu'il y a de bien avec les SHA , c'est que le
moindre caractère modifié dans le VI va produire des changements importants
dans le masque.
3) x->SHA-256(x#k) et x->SHA-512(x#k) sont indistinguables de
fonctions aléatoires pour qui ne connais pas k (où # désigne
la concaténation).
retrouver k a partir d'un de son hash salé
Cependant attention, SHA-256 et SHA-512 ne sont pas explicitement
conçus pour avoir ces propriétés, et il n'est pas évident que
connaissant de multiples paires (x,SHA-256(x#k)) où # désigne la
concaténation, il est impossible de remonter à k (ce serait une
attaque différentielle).
... source wikipédia , c'est pour cela que le masque est conçu avec.
http://fr.wikipedia.org/wiki/SHA-256
Le 1) est probablement le plus faible si K est mémorisable; pour
lutter contre ça il existe des solutions, voir PBKDF2:
http://www.ietf.org/rfc/rfc2898.txt
ou mieux scrypt
http://www.tarsnap.com/scrypt.html
le coller dans la zone de pass-phrase. Dans ce cas la , on ne retient que
lutin mais on colle
385ca43a511b5853fc47b6eafc6bd79cc1403198d0c31162bd006436828c5f332f9b3f7c2317edc596e796b086545e1fa834ba53a9bae3b0f076384e285cb8ce
dans la zone de pass-phrase.
Maintenant ce que j'aurais bien aimé savoir c'est si on est les premiers a
avoir pensé à cette façon de générer un masque jetable ?
François Grieu
Philippe Lheureux
May 21, 2012, 4:35:49 PM5/21/12
to
Cependant attention, SHA-256 et SHA-512 ne sont pas explicitement
conçus pour avoir ces propriétés, et il n'est pas évident que
connaissant de multiples paires (x,SHA-256(x#k)) où # désigne la
concaténation, il est impossible de remonter à k (ce serait une
attaque différentielle).
est aussi possible de saler encore plus la clé en ré-injectant de temps en
temps le vecteur d'initialisation dans la formule , voir en incrémentant.
La formule actuelle est :
Hash du masque = SHA-512 ( hash du masque précédent + clé )
+= concaténé avec
mais elle pourrait aussi être de temps en temps , tous les 10 sha calculés
par exemple
Hash du masque = SHA-512 ( hash du masque précédent + clé + VI) ou VI est le
vecteur d'initialisation
ou bien
Hash du masque = SHA-512 ( clé+hash du masque précédent)
ou bien encore
Hash du masque = SHA-512 ( hash du masque précédent + clé +1)
Hash du masque = SHA-512 ( hash du masque précédent + clé +2) a la deuxième
passe
Hash du masque = SHA-512 ( hash du masque précédent + clé +3) à la troisième
passe
etc ... l'injection d'un incrément doit encore plus gêner une cryptanalyse
différentielle.
0 new messages