Je cherche a cr=E9=E9 une appli web permettant de stocker des infos. Ces
infos sont encod=E9 cot=E9 client et stock=E9 en crypt=E9 sur le serveur,
le serveur ne connaitra jamais la clef de d=E9cryptage.
J'utilise le crytage AES mais j'aurais besoin de v=E9rifier si la clef
entr=E9 par l'utilisateur est bien la bonne (afin d'=E9viter l'affichage
de donn=E9e corrompu si la clef est fausse). J'ai pens=E9 =E0 stocker des
crc sur chaques donn=E9s mais je trouve =E7a un peu lourd.
J'ai pens=E9 =E0 encrypter une chaine banal cot=E9 client et stock=E9 en
cod=E9 cot=E9 serveur, laquel servirait =E0 confirmer que la clef AEs est
bien la bonne. Je me suis donc demander si il =E9t=E9 relativement plus
facile de trouver la clef de cryptage AES lorsque l'on connait les
donn=E9es de d=E9part et d'arriv=E9 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain
xorax wrote on 26/08/2006 20:33:
Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC de contrôles idéalement calculés en mode CTR: il est bon de vérifier que "c'est la bonne clé", il est également utile de vérifier que tous les blocs sont corrects.
Sylvain.
xorax wrote on 26/08/2006 20:33:
Je me suis donc demander si il été relativement plus
facile de trouver la clef de cryptage AES lorsque
l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC
de contrôles idéalement calculés en mode CTR: il est bon de vérifier que
"c'est la bonne clé", il est également utile de vérifier que tous les
blocs sont corrects.
Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC de contrôles idéalement calculés en mode CTR: il est bon de vérifier que "c'est la bonne clé", il est également utile de vérifier que tous les blocs sont corrects.
Sylvain.
xorax
ok, je pensais que se serait largement plus facile...
Merci
Sylvain wrote:
xorax wrote on 26/08/2006 20:33:
Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC de contrôles idéalement calculés en mode CTR: il est bon de vérif ier que "c'est la bonne clé", il est également utile de vérifier que tous l es blocs sont corrects.
Sylvain.
ok, je pensais que se serait largement plus facile...
Merci
Sylvain wrote:
xorax wrote on 26/08/2006 20:33:
Je me suis donc demander si il été relativement plus
facile de trouver la clef de cryptage AES lorsque
l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC
de contrôles idéalement calculés en mode CTR: il est bon de vérif ier que
"c'est la bonne clé", il est également utile de vérifier que tous l es
blocs sont corrects.
ok, je pensais que se serait largement plus facile...
Merci
Sylvain wrote:
xorax wrote on 26/08/2006 20:33:
Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
non.
mais vous devriez, malgré la "lourdeur" évoquée, stocker des crc ou MAC de contrôles idéalement calculés en mode CTR: il est bon de vérif ier que "c'est la bonne clé", il est également utile de vérifier que tous l es blocs sont corrects.
Sylvain.
Sylvain
xorax wrote on 26/08/2006 23:51:
ok, je pensais que se serait largement plus facile...
pour certains algos (principalement asymétriques) cela aide. pour un algo sym. bien conçu (3DES et AES évidemment) un couple ou même plusieurs ("plusieurs" << tous-les-chiffres-d'un-clair) couples clair/chiffré n'apporte rien; une attaque devra passer (sauf invention inattendue) par une exploration exhaustive.
concernant les MAC de contrôle d'intégrité, vous aurez corrigé mon "raccourci": un checksum calculé sur les chiffrés du message traité en mode chaîné CTR permettrait de calculer un crc global (ce n'est pas le MAC lui même qui utilise le mode CTR bien sur).
Rq: il existe peut être d'autres solutions de "signature-chiffrement" plus efficaces, ce domaine est assez actif.
Sylvain.
xorax wrote on 26/08/2006 23:51:
ok, je pensais que se serait largement plus facile...
pour certains algos (principalement asymétriques) cela aide.
pour un algo sym. bien conçu (3DES et AES évidemment) un couple ou même
plusieurs ("plusieurs" << tous-les-chiffres-d'un-clair) couples
clair/chiffré n'apporte rien; une attaque devra passer (sauf invention
inattendue) par une exploration exhaustive.
concernant les MAC de contrôle d'intégrité, vous aurez corrigé mon
"raccourci": un checksum calculé sur les chiffrés du message traité en
mode chaîné CTR permettrait de calculer un crc global (ce n'est pas le
MAC lui même qui utilise le mode CTR bien sur).
Rq: il existe peut être d'autres solutions de "signature-chiffrement"
plus efficaces, ce domaine est assez actif.
ok, je pensais que se serait largement plus facile...
pour certains algos (principalement asymétriques) cela aide. pour un algo sym. bien conçu (3DES et AES évidemment) un couple ou même plusieurs ("plusieurs" << tous-les-chiffres-d'un-clair) couples clair/chiffré n'apporte rien; une attaque devra passer (sauf invention inattendue) par une exploration exhaustive.
concernant les MAC de contrôle d'intégrité, vous aurez corrigé mon "raccourci": un checksum calculé sur les chiffrés du message traité en mode chaîné CTR permettrait de calculer un crc global (ce n'est pas le MAC lui même qui utilise le mode CTR bien sur).
Rq: il existe peut être d'autres solutions de "signature-chiffrement" plus efficaces, ce domaine est assez actif.
Sylvain.
JL
"xorax" a écrit dans le message de news:
J'ai pensé à encrypter une chaine banal coté client et stocké en codé coté serveur, laquel servirait à confirmer que la clef AEs est bien la bonne. Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la même clé une chaîne fixe (par exemple un zéro) que vous stockez avec la donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne clé.
JL.
"xorax" <xxorax@gmail.com> a écrit dans le message de news:
1156617185.256246.137480@75g2000cwc.googlegroups.com...
J'ai pensé à encrypter une chaine banal coté client et stocké en
codé coté serveur, laquel servirait à confirmer que la clef AEs est
bien la bonne. Je me suis donc demander si il été relativement plus
facile de trouver la clef de cryptage AES lorsque l'on connait les
données de départ et d'arrivé ?
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la
même clé une chaîne fixe (par exemple un zéro) que vous stockez avec la
donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne
clé.
J'ai pensé à encrypter une chaine banal coté client et stocké en codé coté serveur, laquel servirait à confirmer que la clef AEs est bien la bonne. Je me suis donc demander si il été relativement plus facile de trouver la clef de cryptage AES lorsque l'on connait les données de départ et d'arrivé ?
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la même clé une chaîne fixe (par exemple un zéro) que vous stockez avec la donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne clé.
JL.
xorax
JL wrote:
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la même clé une chaîne fixe (par exemple un zéro) que vous stockez a vec la donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne clé.
Merci pour la confirmation!!! Et merci à Sylvain pour l'explication. J'adopte la méthode en ce moment même ;)
JL wrote:
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la
même clé une chaîne fixe (par exemple un zéro) que vous stockez a vec la
donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne
clé.
Merci pour la confirmation!!!
Et merci à Sylvain pour l'explication.
J'adopte la méthode en ce moment même ;)
Non, ça n'aide en rien. Et c'est la bonne solution. Vous cryptez avec la même clé une chaîne fixe (par exemple un zéro) que vous stockez a vec la donnée. Si au déchiffrement vous retombez sur zéro, c'est que c'est la bonne clé.
Merci pour la confirmation!!! Et merci à Sylvain pour l'explication. J'adopte la méthode en ce moment même ;)
