Bonjour,
j'utilise openSSL pour faire quelques tests de chiffrement. Un point
m'étonne, concernant le salage:
$ dd if=/dev/urandom ofQ2octets bsQ2 count=1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt2
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt3
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt1
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt2
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt3
$ sha256sum *salt*
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt1
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt2
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt3
b64df3b8f17c9d5dc5045e10c725d3b7fefae052451e4c6620b34a48f89d520d salt1
5be23d8e04ecfcf2f7391a030896d7cb570237b71ff6888707806a6af8aa2883 salt2
74bb1e04e0cc8f6179490aa6d60fc2cef91aee8dd8c125de518450a69762b5e1 salt3
Jusque là, normal. Le chiffrement non salé donne toujours le même
résultat, le chiffrement salé change.
Mais:
$ ls -l *salt*
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt1
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt2
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt3
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt1
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt2
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt3
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas. (le fichier salé est plus
gros que le fichier non salé, ce qui me semble normal).
Quels sont ces 16 octets en plus?
Merci
Bonjour,
j'utilise openSSL pour faire quelques tests de chiffrement. Un point
m'étonne, concernant le salage:
$ dd if=/dev/urandom ofQ2octets bsQ2 count=1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt2
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt3
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt1
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt2
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt3
$ sha256sum *salt*
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt1
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt2
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt3
b64df3b8f17c9d5dc5045e10c725d3b7fefae052451e4c6620b34a48f89d520d salt1
5be23d8e04ecfcf2f7391a030896d7cb570237b71ff6888707806a6af8aa2883 salt2
74bb1e04e0cc8f6179490aa6d60fc2cef91aee8dd8c125de518450a69762b5e1 salt3
Jusque là, normal. Le chiffrement non salé donne toujours le même
résultat, le chiffrement salé change.
Mais:
$ ls -l *salt*
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt1
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt2
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt3
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt1
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt2
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt3
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas. (le fichier salé est plus
gros que le fichier non salé, ce qui me semble normal).
Quels sont ces 16 octets en plus?
Merci
Bonjour,
j'utilise openSSL pour faire quelques tests de chiffrement. Un point
m'étonne, concernant le salage:
$ dd if=/dev/urandom ofQ2octets bsQ2 count=1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt1
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt2
$ openssl enc -aes-128-cbc -nosalt -in 512octets -pass pass:word -out nosalt3
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt1
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt2
$ openssl enc -aes-128-cbc -salt -in 512octets -pass pass:word -out salt3
$ sha256sum *salt*
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt1
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt2
0abe59946b9ba78bc2a623621268f9f23ddc6d3a30d6b16a5395fbb0718700f2 nosalt3
b64df3b8f17c9d5dc5045e10c725d3b7fefae052451e4c6620b34a48f89d520d salt1
5be23d8e04ecfcf2f7391a030896d7cb570237b71ff6888707806a6af8aa2883 salt2
74bb1e04e0cc8f6179490aa6d60fc2cef91aee8dd8c125de518450a69762b5e1 salt3
Jusque là, normal. Le chiffrement non salé donne toujours le même
résultat, le chiffrement salé change.
Mais:
$ ls -l *salt*
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt1
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt2
-rw-r--r-- 1 kevin users 528 2010-11-08 12:36 nosalt3
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt1
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt2
-rw-r--r-- 1 kevin users 544 2010-11-08 12:36 salt3
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas. (le fichier salé est plus
gros que le fichier non salé, ce qui me semble normal).
Quels sont ces 16 octets en plus?
Merci
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas.
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas.
J'aurai pensé que le chiffrement non salé conservait la taille
d'origine du fichier. Il n'en est pas le cas.
La technique la plus courante est ISO/IEC 9797-1 Padding Method 2:
La technique la plus courante est ISO/IEC 9797-1 Padding Method 2:
La technique la plus courante est ISO/IEC 9797-1 Padding Method 2:
En bref, pour enlever des 16 octets supplémentaires, ajoutez l'option
"-nopad", mais il faudra alors que l'entrée ait toujours une taille
multiple de 16.
Il convient de noter que :
1. Ce que fait OpenSSL avec la commande "openssl enc" n'est compatible
qu'avec OpenSSL, et encore, pas toutes les versions.
2. Utiliser un mot de passe sans "salt" est un risque de sécurité. Cela
permet d'optimiser une recherche sur le mot de passe (dans le sens
suivant : l'attaquant devra se payer le dictionnaire, mais il
pourra le faire _une_ fois, et attaquer ensuite de nombreux messages
chiffrés avec des mots de passes différents).
3. Le mode CBC nécessite une IV. OpenSSL dérive cette IV du mot de
passe. Cela veut dire qu'en mode "nosalt", si on utilise le même
mot de passe deux fois, on va aussi utiliser la même IV. C'est
_aussi_ un problème de sécurité avec CBC (pas le même que le point 2).
En bref, pour enlever des 16 octets supplémentaires, ajoutez l'option
"-nopad", mais il faudra alors que l'entrée ait toujours une taille
multiple de 16.
Il convient de noter que :
1. Ce que fait OpenSSL avec la commande "openssl enc" n'est compatible
qu'avec OpenSSL, et encore, pas toutes les versions.
2. Utiliser un mot de passe sans "salt" est un risque de sécurité. Cela
permet d'optimiser une recherche sur le mot de passe (dans le sens
suivant : l'attaquant devra se payer le dictionnaire, mais il
pourra le faire _une_ fois, et attaquer ensuite de nombreux messages
chiffrés avec des mots de passes différents).
3. Le mode CBC nécessite une IV. OpenSSL dérive cette IV du mot de
passe. Cela veut dire qu'en mode "nosalt", si on utilise le même
mot de passe deux fois, on va aussi utiliser la même IV. C'est
_aussi_ un problème de sécurité avec CBC (pas le même que le point 2).
En bref, pour enlever des 16 octets supplémentaires, ajoutez l'option
"-nopad", mais il faudra alors que l'entrée ait toujours une taille
multiple de 16.
Il convient de noter que :
1. Ce que fait OpenSSL avec la commande "openssl enc" n'est compatible
qu'avec OpenSSL, et encore, pas toutes les versions.
2. Utiliser un mot de passe sans "salt" est un risque de sécurité. Cela
permet d'optimiser une recherche sur le mot de passe (dans le sens
suivant : l'attaquant devra se payer le dictionnaire, mais il
pourra le faire _une_ fois, et attaquer ensuite de nombreux messages
chiffrés avec des mots de passes différents).
3. Le mode CBC nécessite une IV. OpenSSL dérive cette IV du mot de
passe. Cela veut dire qu'en mode "nosalt", si on utilise le même
mot de passe deux fois, on va aussi utiliser la même IV. C'est
_aussi_ un problème de sécurité avec CBC (pas le même que le point 2).
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
Comment fonctionnent alors les systèmes de Full Disk Encryption?
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
Comment fonctionnent alors les systèmes de Full Disk Encryption?
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
Comment fonctionnent alors les systèmes de Full Disk Encryption?
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
L'implémentation d'AES est standard : pour une même clé de 128 bits, un
bloc de 16 octets sera transformé dans le même bloc chiffré que ce que
produit n'importe quelle autre implémentation de l'AES.
Mais de l'AES à un chiffrement de message par mot de passe, il y a un
pas. Ce que fait "openssl enc" est une tambouille spécifique à OpenSSL
et qui n'est décrite nulle part ailleurs que dans le code source
d'OpenSSL.
Il faut dire que les standards de chiffrement de messages sont un peu
plus "haut niveau" que ça. Par exemple, S/MIME est un standard de
chiffrement et signature d'emails. S/MIME utilise CMS, dérivé de PKCS#7.
OpenSSL a une implémentation de S/MIME ("openssl smime").Comment fonctionnent alors les systèmes de Full Disk Encryption?
Pour le reste, il faut encore se préoccuper des IV. Si on considère le
disque entier comme un unique gros message en mode CBC, alors, pour
déchiffrer un secteur, il faut lire ce secteur _et_ les derniers 16
octets du secteur précédent. C'est un peu pénalisant du point de vue
performances.
Une autre méthode est de considérer chaque secteur (de 512
octets) comme un message indépendant, et d'utiliser comme IV une valeur
dérivée de la clé et du numéro de secteur
(c'est un peu délicat à faire :
on veut des IV réparties uniformément dans l'espace des blocs de 16
octets, et imprédictibles).
Une autre méthode encore consisterait à
ne pas utiliser le mode CBC, mais le mode CTR, où le numéro de
secteur donne naturellement les informations nécessaires.
Si on veut en outre du contrôle d'intégrité, alors c'est plus compliqué.
Beaucoup plus.
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
L'implémentation d'AES est standard : pour une même clé de 128 bits, un
bloc de 16 octets sera transformé dans le même bloc chiffré que ce que
produit n'importe quelle autre implémentation de l'AES.
Mais de l'AES à un chiffrement de message par mot de passe, il y a un
pas. Ce que fait "openssl enc" est une tambouille spécifique à OpenSSL
et qui n'est décrite nulle part ailleurs que dans le code source
d'OpenSSL.
Il faut dire que les standards de chiffrement de messages sont un peu
plus "haut niveau" que ça. Par exemple, S/MIME est un standard de
chiffrement et signature d'emails. S/MIME utilise CMS, dérivé de PKCS#7.
OpenSSL a une implémentation de S/MIME ("openssl smime").
Comment fonctionnent alors les systèmes de Full Disk Encryption?
Pour le reste, il faut encore se préoccuper des IV. Si on considère le
disque entier comme un unique gros message en mode CBC, alors, pour
déchiffrer un secteur, il faut lire ce secteur _et_ les derniers 16
octets du secteur précédent. C'est un peu pénalisant du point de vue
performances.
Une autre méthode est de considérer chaque secteur (de 512
octets) comme un message indépendant, et d'utiliser comme IV une valeur
dérivée de la clé et du numéro de secteur
(c'est un peu délicat à faire :
on veut des IV réparties uniformément dans l'espace des blocs de 16
octets, et imprédictibles).
Une autre méthode encore consisterait à
ne pas utiliser le mode CBC, mais le mode CTR, où le numéro de
secteur donne naturellement les informations nécessaires.
Si on veut en outre du contrôle d'intégrité, alors c'est plus compliqué.
Beaucoup plus.
Je pensais qu'openssl était standard, dans le sens ou un (dé)chiffrement
effectué par lui est utilisable par n'importe quel autre programme (?)
L'implémentation d'AES est standard : pour une même clé de 128 bits, un
bloc de 16 octets sera transformé dans le même bloc chiffré que ce que
produit n'importe quelle autre implémentation de l'AES.
Mais de l'AES à un chiffrement de message par mot de passe, il y a un
pas. Ce que fait "openssl enc" est une tambouille spécifique à OpenSSL
et qui n'est décrite nulle part ailleurs que dans le code source
d'OpenSSL.
Il faut dire que les standards de chiffrement de messages sont un peu
plus "haut niveau" que ça. Par exemple, S/MIME est un standard de
chiffrement et signature d'emails. S/MIME utilise CMS, dérivé de PKCS#7.
OpenSSL a une implémentation de S/MIME ("openssl smime").Comment fonctionnent alors les systèmes de Full Disk Encryption?
Pour le reste, il faut encore se préoccuper des IV. Si on considère le
disque entier comme un unique gros message en mode CBC, alors, pour
déchiffrer un secteur, il faut lire ce secteur _et_ les derniers 16
octets du secteur précédent. C'est un peu pénalisant du point de vue
performances.
Une autre méthode est de considérer chaque secteur (de 512
octets) comme un message indépendant, et d'utiliser comme IV une valeur
dérivée de la clé et du numéro de secteur
(c'est un peu délicat à faire :
on veut des IV réparties uniformément dans l'espace des blocs de 16
octets, et imprédictibles).
Une autre méthode encore consisterait à
ne pas utiliser le mode CBC, mais le mode CTR, où le numéro de
secteur donne naturellement les informations nécessaires.
Si on veut en outre du contrôle d'intégrité, alors c'est plus compliqué.
Beaucoup plus.
Surtout qu'a priori si je change un des 16 derniers octets du bloc 'n'
je devrais rechiffrer le bloc 'n+1'? Et par cascade, éventuellement le
disque entier?
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Surtout qu'a priori si je change un des 16 derniers octets du bloc 'n'
je devrais rechiffrer le bloc 'n+1'? Et par cascade, éventuellement le
disque entier?
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Surtout qu'a priori si je change un des 16 derniers octets du bloc 'n'
je devrais rechiffrer le bloc 'n+1'? Et par cascade, éventuellement le
disque entier?
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
Je voulais dire, imprédictibles du point de vue de l'attaquant (ne
pas pouvoir écrire un fichier en clair et savoir dès ce moment quelle
IV sera utilisée).
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans ce cas, les choses sont plus compliquées. Il va falloir dépenser un
peu de place disque. Si on veut qu'un secteur de 512 octets soit chiffré
de façon différente à chaque écriture, alors il va falloir que la
variante chiffrée soit plus grande que 512 octets. 16 octets aléatoires
suffiraient amplement (et ça peut alors prendre la forme d'un
chiffrement CBC, les 16 octets étant l'IV). Dans ce cadre, les secteurs
sont groupés par 33 : 32 secteurs de données, un 33ème pour les IV. La
perte de place est de l'ordre de 3%. Mais la lecture d'un secteur
demande également la lecture du secteur contenant l'IV correspondante,
et l'écriture d'un secteur chiffré exige de réécrire le secteur
contenant l'IV aussi.
Il n'est pas clair que le secteur soit la bonne
granularité, surtout que les OS récent sur PC ont tendance à faire les
accès par 4 Ko (comme une page de la MMU) et que les disques récents ont
des secteurs de 4 Ko aussi.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Je ne suis pas persuadé que séparer intégrité et chiffrement soit une
tactique optimale face à un attaquant actif. Le contrôle d'intégrité
d'un disque dur est une chose compliquée parce qu'on veut prendre en
charge des modifications partielles, et la recherche de la performance
pour le chiffrement (par réduction du nombre d'I/O) devrait suivre les
mêmes chemins.
Une référence qui pourrait être une bonne lecture sur le sujet :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi.1.1.23.976
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
Je voulais dire, imprédictibles du point de vue de l'attaquant (ne
pas pouvoir écrire un fichier en clair et savoir dès ce moment quelle
IV sera utilisée).
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans ce cas, les choses sont plus compliquées. Il va falloir dépenser un
peu de place disque. Si on veut qu'un secteur de 512 octets soit chiffré
de façon différente à chaque écriture, alors il va falloir que la
variante chiffrée soit plus grande que 512 octets. 16 octets aléatoires
suffiraient amplement (et ça peut alors prendre la forme d'un
chiffrement CBC, les 16 octets étant l'IV). Dans ce cadre, les secteurs
sont groupés par 33 : 32 secteurs de données, un 33ème pour les IV. La
perte de place est de l'ordre de 3%. Mais la lecture d'un secteur
demande également la lecture du secteur contenant l'IV correspondante,
et l'écriture d'un secteur chiffré exige de réécrire le secteur
contenant l'IV aussi.
Il n'est pas clair que le secteur soit la bonne
granularité, surtout que les OS récent sur PC ont tendance à faire les
accès par 4 Ko (comme une page de la MMU) et que les disques récents ont
des secteurs de 4 Ko aussi.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Je ne suis pas persuadé que séparer intégrité et chiffrement soit une
tactique optimale face à un attaquant actif. Le contrôle d'intégrité
d'un disque dur est une chose compliquée parce qu'on veut prendre en
charge des modifications partielles, et la recherche de la performance
pour le chiffrement (par réduction du nombre d'I/O) devrait suivre les
mêmes chemins.
Une référence qui pourrait être une bonne lecture sur le sujet :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi.1.1.23.976
Uniformément réparties, ok. Mais imprédictibles? Il le faut un minimum
pour pouvoir déchiffrer le bloc après coup tout de même?
Je voulais dire, imprédictibles du point de vue de l'attaquant (ne
pas pouvoir écrire un fichier en clair et savoir dès ce moment quelle
IV sera utilisée).
D'accord. Mais ce qui m'ennuie tout de même la dedans, c'est que
la même donnée sur le même secteur avec la même clé donnera toujours
le même chiffré. C'est ce que je voudrais éviter.
Dans ce cas, les choses sont plus compliquées. Il va falloir dépenser un
peu de place disque. Si on veut qu'un secteur de 512 octets soit chiffré
de façon différente à chaque écriture, alors il va falloir que la
variante chiffrée soit plus grande que 512 octets. 16 octets aléatoires
suffiraient amplement (et ça peut alors prendre la forme d'un
chiffrement CBC, les 16 octets étant l'IV). Dans ce cadre, les secteurs
sont groupés par 33 : 32 secteurs de données, un 33ème pour les IV. La
perte de place est de l'ordre de 3%. Mais la lecture d'un secteur
demande également la lecture du secteur contenant l'IV correspondante,
et l'écriture d'un secteur chiffré exige de réécrire le secteur
contenant l'IV aussi.
Il n'est pas clair que le secteur soit la bonne
granularité, surtout que les OS récent sur PC ont tendance à faire les
accès par 4 Ko (comme une page de la MMU) et que les disques récents ont
des secteurs de 4 Ko aussi.
Dans mon idée, je délègue ça au filesystem qui utilisera la partition
chiffrée.
Je ne suis pas persuadé que séparer intégrité et chiffrement soit une
tactique optimale face à un attaquant actif. Le contrôle d'intégrité
d'un disque dur est une chose compliquée parce qu'on veut prendre en
charge des modifications partielles, et la recherche de la performance
pour le chiffrement (par réduction du nombre d'I/O) devrait suivre les
mêmes chemins.
Une référence qui pourrait être une bonne lecture sur le sujet :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi.1.1.23.976