Est-ce une bonne idée de conserver la clé avec les données chiffrées ?

Le
Vincent
Bonjour,

J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un
logiciel que je développe. Pour le chiffrement, je calcule un hash md5
du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme
Blowfish.

Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe
est faux pour afficher un message du genre « Mot de passe non valable »
au lieu de fournir des données aléatoires.

Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.

Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?

Merci d'avance,
Vincent
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick 'Zener' Brunet
Le #597369
Bonsoir.

"Vincent"
J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un
logiciel que je développe. Pour le chiffrement, je calcule un hash md5
du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme
Blowfish.

Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe
est faux pour afficher un message du genre « Mot de passe non valable »
au lieu de fournir des données aléatoires.

Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.

Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?



Pourquoi faciliter le moins du monde la tâche d'un attaquant ?

Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.

--
Cordialement.
--
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe

Al
Le #597368
Bonsoir.

"Vincent"
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.

Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?



Pourquoi faciliter le moins du monde la tâche d'un attaquant ?

Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.
le problème c'est que de faire une check sur le mot de passer réduit

l'espace de clé d'autant...

bon, si ta clé est bien plus grosse que le digest, ce n'est pas
dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de
véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton
mot de passe est long et complexe)

une idée ce serait plutot de faire un checksum de ce qui est à chiffre,
et de l'ajouter à la fin.

ca me rappelle une norme de chiffrement...
bon évidemment il faut aussi que tu puisse détecter la fin de ton message.
soit il est de taille fixe, et tu stocke
chiffre_Clé_(message,hash(message))
soit il est terminé par un truc défini et tu stocke
chiffre_Clé_(message,terminateur,hash(message))
soit il est de taille variable

chiffre_Clé_(longueur,message,hash(message))

a noter que si le message est trop court il faudrait aussi convenir d'un
padding aléatoire
chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))

sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins
dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut
être modeste) regarde les standards de chiffrement PKCS...
il doit y en avoir un qui te convient.

n'oublie pas tout les détails, tesl que longuer minimal, padding
aléatoire, hash, ordre des opérations

par exemple il est peut être plus cool de faire

chiffre_Clé_(longueur,message,padding,hash(longueur,message,padding))

en effet le padding crée plus d'entropie et complique encore le travail
à texte connu (qui ne l'est plus a cause du bourrage), mais c'est
peutêtre de la zoophilie pour mouches...
un principe en crypto c'est que si d'autres ont eu le même problème (là
c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris
pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème
voir trouvé un truc solide et standardisé qui a tenus quelque temps face
a des scientifiques vicieux


Vincent
Le #597364

Pourquoi faciliter le moins du monde la tâche d'un attaquant ?

Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.



Merci, celà me parait en effet plus sûr... Pourrais-je stocker le hash
md5 de la clé au lieu de la clé ? (la taille n'a pas beaucoup d'importance)

Vincent

Vincent
Le #597363
...
le problème c'est que de faire une check sur le mot de passer réduit
l'espace de clé d'autant...

bon, si ta clé est bien plus grosse que le digest, ce n'est pas
dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de
véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton
mot de passe est long et complexe)

une idée ce serait plutot de faire un checksum de ce qui est à chiffre,
et de l'ajouter à la fin.

ca me rappelle une norme de chiffrement...
bon évidemment il faut aussi que tu puisse détecter la fin de ton message.
soit il est de taille fixe, et tu stocke
chiffre_Clé_(message,hash(message))
soit il est terminé par un truc défini et tu stocke
chiffre_Clé_(message,terminateur,hash(message))
soit il est de taille variable

chiffre_Clé_(longueur,message,hash(message))

a noter que si le message est trop court il faudrait aussi convenir d'un
padding aléatoire
chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))

sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins
dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut
être modeste) regarde les standards de chiffrement PKCS...
il doit y en avoir un qui te convient.

n'oublie pas tout les détails, tesl que longuer minimal, padding
aléatoire, hash, ordre des opérations

par exemple il est peut être plus cool de faire

chiffre_Clé_(longueur,message,padding,hash(longueur,message,padding))

en effet le padding crée plus d'entropie et complique encore le travail
à texte connu (qui ne l'est plus a cause du bourrage), mais c'est
peutêtre de la zoophilie pour mouches...
un principe en crypto c'est que si d'autres ont eu le même problème (là
c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris
pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème
voir trouvé un truc solide et standardisé qui a tenus quelque temps face
a des scientifiques vicieux





Merci, je vais donc essayer de voir les standards PKCS. Juste une
question : quelque chose m'échappe dans ton explication, pourrais-tu
préciser ce que représente "chiffre_clé" ? Dans mon fichier je stocke le
"salt", le vecteur d'initialisation, puis les données chiffrées.

Vincent

Al
Le #601355

Merci, je vais donc essayer de voir les standards PKCS. Juste une
question : quelque chose m'échappe dans ton explication, pourrais-tu
préciser ce que représente "chiffre_clé" ?


c'est une notation pas claire du cliffrement par la clé

Chiffrement(clé,donnée)
mais comme j'ai des données complexes

en plus toi tu aurait
Chiffrement(clé, vecteur d'init,
(salt,longueur,message,hash(salt,longueur,message)))

note qu'on peut utiliser un hash non crypto: une parité, un crc, une
checksum... on n'est pas la pour signer, juste pour vérifier



Dans mon fichier je stocke le
"salt", le vecteur d'initialisation, puis les données chiffrées.


le salt joue un peu le rôle du padding, mais pas pour bourer, juste pour
bruiter...
regarde comment je l'utilise ci-avant


dans certains docs standards on parle du vecteur d'init qui n'est pas
une clé, mais un paramètre (public) de l'algo...

j'ai pas tout suivi et donc prudence

Patrick 'Zener' Brunet
Le #601353
Bonsoir.

"Al" 47742772$0$897$
[...]
note qu'on peut utiliser un hash non crypto: une parité, un crc,
une checksum... on n'est pas la pour signer, juste pour vérifier



Tout à fait, précisément il n'y a pas d'objectif de sécurité au sens de
l'authentification.
Si j'ai bien compris, l'objectif est seulement de diagnostiquer un mot de
passe incorrect afin que l'utilisateur ne reste pas devant un refus d'accès
incompréhensible ?

Avec une simple checksum de type XOR sur 5 bits indexant une clé
alphanumérique, il aurait seulement une chance sur 32 de trouver un mauvais
mot de passe qui ne soit pas diagnostiqué et provoque seulement un refus
d'accès. A moins de viser une population de malchanceux chroniques, cela
semble largement suffisant, non ?

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.free.fr/ContactMe

Publicité
Poster une réponse
Anonyme