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)
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 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é
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)
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)
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)
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
Philippe Lheureux
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 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.
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
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.
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 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
Le 16/05/2012 10:02, Philippe Lheureux a écrit :
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 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.
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
Le 16/05/2012 10:02, Philippe Lheureux a écrit :
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 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.
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.
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 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.
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
Philippe Lheureux
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> 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
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>
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
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> 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
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.
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.
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
Le 16/05/2012 14:24, Philippe Lheureux a écrit, me quotant
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.
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 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
Le 16/05/2012 14:24, Philippe Lheureux a écrit, me quotant
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.
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
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
Le 16/05/2012 14:24, Philippe Lheureux a écrit, me quotant
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.
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 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
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
LP : c'est le cas , minimum 16 caractères mais on a prévu de l'enregistrer 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).
LP: Ca c'est sur ... à moins d'être médium je ne vois pas comment on peut 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).
LP: Il parait que SHA-512 est insensible à la cryptanalyse 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
LP: Encore qu'il est toujours possible de faire le SHA-512 de "lutin" et de 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
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
LP : c'est le cas , minimum 16 caractères mais on a prévu de l'enregistrer
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).
LP: Ca c'est sur ... à moins d'être médium je ne vois pas comment on peut
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).
LP: Il parait que SHA-512 est insensible à la cryptanalyse 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
LP: Encore qu'il est toujours possible de faire le SHA-512 de "lutin" et de
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 ?
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
LP : c'est le cas , minimum 16 caractères mais on a prévu de l'enregistrer 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).
LP: Ca c'est sur ... à moins d'être médium je ne vois pas comment on peut 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).
LP: Il parait que SHA-512 est insensible à la cryptanalyse 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
LP: Encore qu'il est toujours possible de faire le SHA-512 de "lutin" et de 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
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).
LP: Comme je l'indique aussi sur ma page www.superlutin.net/hmk.html , il 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.
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).
LP: Comme je l'indique aussi sur ma page www.superlutin.net/hmk.html , il
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.
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).
LP: Comme je l'indique aussi sur ma page www.superlutin.net/hmk.html , il 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.
