Quelques petites questions au sujet de DES (Digital Encryption Standard) :
Je souhaite utiliser l'implémentation founie dans le cadre du Framework
DotNet de Microsoft.
Je me pose des questions sur des contraintes relatives ou choix des entrée
de l'algorithme.
Il y a trois données en entrée de l'algorithme :
1 - le texte à chiffrer (cleartext)
2 - la clé de chiffrement (key)
3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre.
Quelle importance à le choix de ce paramètre ?
Dans le cadre d'une implémentation je vais demander à l'utilisateur de
choisir une clé.
Est-ce problématique si je prend un IV égal à la clé ?
Si oui quelles sont les contraintes de choix ?
* Au sujet de la taille de la clé.
Elle est de 56 ou 64 bits ?
Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique
de répéter cette clé autant de fois que nécéssaire pour obtenir la taille
minimum ?
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
Jacques Caron
Salut,
Je suis loin d'être un expert en crypto ni en DES, mais quelques éléments...
On Mon, 20 Oct 2003 22:55:38 +0200, Christian wrote:
Il y a trois données en entrée de l'algorithme : 1 - le texte à chiffrer (cleartext) 2 - la clé de chiffrement (key) 3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre. Quelle importance à le choix de ce paramètre ?
Beaucoup. On a vu ce que ça a donné avec WEP :-/
Dans le cadre d'une implémentation je vais demander à l'utilisateur de choisir une clé. Est-ce problématique si je prend un IV égal à la clé ? Si oui quelles sont les contraintes de choix ?
Normalement le but de l'IV c'est de pouvoir chiffrer plusieurs éléments différents (par exemple plusieurs paquets) avec une même clef "de base", mais pas vraiment la clef. Si tu chiffres tous tes éléments avec la même clef, tu risques de donner beaucoup d'informations sur ta clef. Mais de toutes façons l'IV doit de toutes façons être transmise "en clair" en même temps que chaque élément, non?
* Au sujet de la taille de la clé. Elle est de 56 ou 64 bits ? Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique de répéter cette clé autant de fois que nécéssaire pour obtenir la taille minimum ?
Je pense que tu facilites le travail de l'attaquant si tu fais ça.
Mais je suis sûr qu'on va corriger toutes les bêtises que je raconte :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
Je suis loin d'être un expert en crypto ni en DES, mais quelques
éléments...
On Mon, 20 Oct 2003 22:55:38 +0200, Christian <xtian_news@hotmail.com>
wrote:
Il y a trois données en entrée de l'algorithme :
1 - le texte à chiffrer (cleartext)
2 - la clé de chiffrement (key)
3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre.
Quelle importance à le choix de ce paramètre ?
Beaucoup. On a vu ce que ça a donné avec WEP :-/
Dans le cadre d'une implémentation je vais demander à l'utilisateur de
choisir une clé.
Est-ce problématique si je prend un IV égal à la clé ?
Si oui quelles sont les contraintes de choix ?
Normalement le but de l'IV c'est de pouvoir chiffrer plusieurs éléments
différents (par exemple plusieurs paquets) avec une même clef "de base",
mais pas vraiment la clef. Si tu chiffres tous tes éléments avec la même
clef, tu risques de donner beaucoup d'informations sur ta clef. Mais de
toutes façons l'IV doit de toutes façons être transmise "en clair" en même
temps que chaque élément, non?
* Au sujet de la taille de la clé.
Elle est de 56 ou 64 bits ?
Si l'utilisateur saisit une clé de taille inférieure, est-ce
problématique
de répéter cette clé autant de fois que nécéssaire pour obtenir la taille
minimum ?
Je pense que tu facilites le travail de l'attaquant si tu fais ça.
Mais je suis sûr qu'on va corriger toutes les bêtises que je raconte :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Je suis loin d'être un expert en crypto ni en DES, mais quelques éléments...
On Mon, 20 Oct 2003 22:55:38 +0200, Christian wrote:
Il y a trois données en entrée de l'algorithme : 1 - le texte à chiffrer (cleartext) 2 - la clé de chiffrement (key) 3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre. Quelle importance à le choix de ce paramètre ?
Beaucoup. On a vu ce que ça a donné avec WEP :-/
Dans le cadre d'une implémentation je vais demander à l'utilisateur de choisir une clé. Est-ce problématique si je prend un IV égal à la clé ? Si oui quelles sont les contraintes de choix ?
Normalement le but de l'IV c'est de pouvoir chiffrer plusieurs éléments différents (par exemple plusieurs paquets) avec une même clef "de base", mais pas vraiment la clef. Si tu chiffres tous tes éléments avec la même clef, tu risques de donner beaucoup d'informations sur ta clef. Mais de toutes façons l'IV doit de toutes façons être transmise "en clair" en même temps que chaque élément, non?
* Au sujet de la taille de la clé. Elle est de 56 ou 64 bits ? Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique de répéter cette clé autant de fois que nécéssaire pour obtenir la taille minimum ?
Je pense que tu facilites le travail de l'attaquant si tu fais ça.
Mais je suis sûr qu'on va corriger toutes les bêtises que je raconte :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
VE
Bonjour,
L'IV permet de crypter différemment et ceci dés le premier octet 2 messages commencant de manière identique. Ce qui est le cas par exemple avec des trames de communications . Sinon comme l'entete est connu cela donne des couples texte crypté/texte en clair à l'attaquant et donc facilite son travail sur la recherche de la clé.
Les methodes courantes de chiffrement par bloc font que le résultat du cryptage du bloc précédent sert au cryptage du bloc suivant. En commancant ton message par un bloc alétaoire tu changes entierement le résultat du cryptage des blocs de données suivant.
L'IV ne peut pas etre une valeur constante sinon il pert tous son interet cela doit etre une valeur aléatoire ( ou au minimum variant constamment )
Les cles DES sont stockées sur 8 octets = 64 bits toutefois seul 56 bits sont utilisés pour le calcul du DES . La clé effective fait donc bien 56 bits. Les 8 bits restants sont utilisées normalement pour un test de parité sur chaque octet de la clé.
Enfin pour la clé, en utilisant une méthode de hashage sur ton password et filtrant les clés faibles cela devrais pouvoir résoudre les problème de clé trop courrte ou trop longue. Une méthode sûre est me semble t'il décrite dans les doc du DES.
Vincent
"Christian" a écrit dans le message de news:bn1i4b$ns7$
Quelques petites questions au sujet de DES (Digital Encryption Standard) :
Je souhaite utiliser l'implémentation founie dans le cadre du Framework DotNet de Microsoft. Je me pose des questions sur des contraintes relatives ou choix des entrée de l'algorithme. Il y a trois données en entrée de l'algorithme : 1 - le texte à chiffrer (cleartext) 2 - la clé de chiffrement (key) 3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre. Quelle importance à le choix de ce paramètre ? Dans le cadre d'une implémentation je vais demander à l'utilisateur de choisir une clé. Est-ce problématique si je prend un IV égal à la clé ? Si oui quelles sont les contraintes de choix ?
* Au sujet de la taille de la clé. Elle est de 56 ou 64 bits ? Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique de répéter cette clé autant de fois que nécéssaire pour obtenir la taille minimum ?
Par avance merci,
Christian ()
Bonjour,
L'IV permet de crypter différemment et ceci dés le premier octet 2 messages
commencant de manière identique. Ce qui est le cas par exemple avec des
trames de communications . Sinon comme l'entete est connu cela donne des
couples texte crypté/texte en clair à l'attaquant et donc facilite son
travail sur la recherche de la clé.
Les methodes courantes de chiffrement par bloc font que le résultat du
cryptage du bloc précédent sert au cryptage du bloc suivant. En commancant
ton message par un bloc alétaoire tu changes entierement le résultat du
cryptage des blocs de données suivant.
L'IV ne peut pas etre une valeur constante sinon il pert tous son interet
cela doit etre une valeur aléatoire ( ou au minimum variant constamment )
Les cles DES sont stockées sur 8 octets = 64 bits toutefois seul 56 bits
sont utilisés pour le calcul du DES . La clé effective fait donc bien 56
bits. Les 8 bits restants sont utilisées normalement pour un test de parité
sur chaque octet de la clé.
Enfin pour la clé, en utilisant une méthode de hashage sur ton password et
filtrant les clés faibles cela devrais pouvoir résoudre les problème de clé
trop courrte ou trop longue. Une méthode sûre est me semble t'il décrite
dans les doc du DES.
Vincent
"Christian" <xtian_news@hotmail.com> a écrit dans le message de
news:bn1i4b$ns7$1@news-reader3.wanadoo.fr...
Quelques petites questions au sujet de DES (Digital Encryption Standard) :
Je souhaite utiliser l'implémentation founie dans le cadre du Framework
DotNet de Microsoft.
Je me pose des questions sur des contraintes relatives ou choix des entrée
de l'algorithme.
Il y a trois données en entrée de l'algorithme :
1 - le texte à chiffrer (cleartext)
2 - la clé de chiffrement (key)
3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre.
Quelle importance à le choix de ce paramètre ?
Dans le cadre d'une implémentation je vais demander à l'utilisateur de
choisir une clé.
Est-ce problématique si je prend un IV égal à la clé ?
Si oui quelles sont les contraintes de choix ?
* Au sujet de la taille de la clé.
Elle est de 56 ou 64 bits ?
Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique
de répéter cette clé autant de fois que nécéssaire pour obtenir la taille
minimum ?
L'IV permet de crypter différemment et ceci dés le premier octet 2 messages commencant de manière identique. Ce qui est le cas par exemple avec des trames de communications . Sinon comme l'entete est connu cela donne des couples texte crypté/texte en clair à l'attaquant et donc facilite son travail sur la recherche de la clé.
Les methodes courantes de chiffrement par bloc font que le résultat du cryptage du bloc précédent sert au cryptage du bloc suivant. En commancant ton message par un bloc alétaoire tu changes entierement le résultat du cryptage des blocs de données suivant.
L'IV ne peut pas etre une valeur constante sinon il pert tous son interet cela doit etre une valeur aléatoire ( ou au minimum variant constamment )
Les cles DES sont stockées sur 8 octets = 64 bits toutefois seul 56 bits sont utilisés pour le calcul du DES . La clé effective fait donc bien 56 bits. Les 8 bits restants sont utilisées normalement pour un test de parité sur chaque octet de la clé.
Enfin pour la clé, en utilisant une méthode de hashage sur ton password et filtrant les clés faibles cela devrais pouvoir résoudre les problème de clé trop courrte ou trop longue. Une méthode sûre est me semble t'il décrite dans les doc du DES.
Vincent
"Christian" a écrit dans le message de news:bn1i4b$ns7$
Quelques petites questions au sujet de DES (Digital Encryption Standard) :
Je souhaite utiliser l'implémentation founie dans le cadre du Framework DotNet de Microsoft. Je me pose des questions sur des contraintes relatives ou choix des entrée de l'algorithme. Il y a trois données en entrée de l'algorithme : 1 - le texte à chiffrer (cleartext) 2 - la clé de chiffrement (key) 3 - le vecteur d'initialisation (IV)
* Ma 1ère question porte sur le 3ième paramêtre. Quelle importance à le choix de ce paramètre ? Dans le cadre d'une implémentation je vais demander à l'utilisateur de choisir une clé. Est-ce problématique si je prend un IV égal à la clé ? Si oui quelles sont les contraintes de choix ?
* Au sujet de la taille de la clé. Elle est de 56 ou 64 bits ? Si l'utilisateur saisit une clé de taille inférieure, est-ce problématique de répéter cette clé autant de fois que nécéssaire pour obtenir la taille minimum ?
