remplir de données aléatoires un disque avant de le chiffrer [cryptsetup]

Le
Kevin Denis
Bonjour,

je lis qu'il est toujours obligatoire de remplir de données aléatoires
un disque avant de le chiffrer:

http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les données
sont chiffrées, et écrasent les données précedemment inscrites. En
quoi le fait que ces données précedemment inscrites soient
aléatoires ou bien connues influe-t'il sur une cryptanalyse?

Merci
--
Kevin
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mathieu SEGAUD
Le #598975
Kevin Denis
Bonjour,

je lis qu'il est toujours obligatoire de remplir de données aléatoires
un disque avant de le chiffrer:

http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les données
sont chiffrées, et écrasent les données précedemment inscrites. En
quoi le fait que ces données précedemment inscrites soient
aléatoires ou bien connues influe-t'il sur une cryptanalyse?


si elles sont connues, on a un niveau de sécurité qui permet une
attaque de type:
texte de départ connu + texte chiffré connu.
Ce qui est nettement moins sûr que de ne laisser que le texte chiffré.
Certains algorithmes sont plus sensibles à tel ou tel type d'attaque

--
Mathieu

remy
Le #598974
bonjour

Bonjour,

je lis qu'il est toujours obligatoire de remplir de données aléatoires
un disque avant de le chiffrer:

http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les données
sont chiffrées, et écrasent les données précedemment inscrites. En
quoi le fait que ces données précedemment inscrites soient
aléatoires ou bien connues influe-t'il sur une cryptanalyse?



bicause attaque à texte clair connu
en gros

remy




Merci


Kevin Denis
Le #598973
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les données
sont chiffrées, et écrasent les données précedemment inscrites. En
quoi le fait que ces données précedemment inscrites soient
aléatoires ou bien connues influe-t'il sur une cryptanalyse?


si elles sont connues, on a un niveau de sécurité qui permet une
attaque de type:
texte de départ connu + texte chiffré connu.


C'est bien ce que j'ai du mal a comprendre. On parle du texte de départ
pas de l'état du support.

Ce qui est nettement moins sûr que de ne laisser que le texte chiffré.
Certains algorithmes sont plus sensibles à tel ou tel type d'attaque

Soit un disque rempli de 0 (dd if=/dev/zero of=/dev/hda1).

Le disque est donc: 000000(etc..)

Soit un fichier texte: "abcdef"
Soit sa version chiffrée: "tujbfg"

Le disque dur aura donc apres ecriture du fichier chiffré:
tujbfg0000000(etc..)

En quoi le fait de connaitre les 0 qui sont presents _avant_ l'ecriture
est il une faille de securite? Mis à part de pouvoir intuiter la taille
des données copiées sur le support, ou est la faille cryptographique?

Si mon disque est préalablement chiffré, admettons:
moiuaezpoiqezrnmalekjf(...) , la version après écriture du fichier chiffré
sera donc:
tujbfgzpoiqezrnmalekjf(...)

J'ai l'impression de manquer une étape qui m'expliquerait pourquoi
il est néecessaire que le disque soit chiffré avant utilisation.
--
Kevin


Mathieu SEGAUD
Le #598972
Kevin Denis
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les données
sont chiffrées, et écrasent les données précedemment inscrites. En
quoi le fait que ces données précedemment inscrites soient
aléatoires ou bien connues influe-t'il sur une cryptanalyse?


si elles sont connues, on a un niveau de sécurité qui permet une
attaque de type:
texte de départ connu + texte chiffré connu.


C'est bien ce que j'ai du mal a comprendre. On parle du texte de départ
pas de l'état du support.



oui, tout juste, mea culpa, j'avais pas bien lu la question :(

Soit un disque rempli de 0 (dd if=/dev/zero of=/dev/hda1).
Le disque est donc: 000000(etc..)

Soit un fichier texte: "abcdef"
Soit sa version chiffrée: "tujbfg"

Le disque dur aura donc apres ecriture du fichier chiffré:
tujbfg0000000(etc..)

En quoi le fait de connaitre les 0 qui sont presents _avant_ l'ecriture
est il une faille de securite? Mis à part de pouvoir intuiter la taille
des données copiées sur le support, ou est la faille cryptographique?


c'est déjà pas mal, dans le sens où l'attaquant a accés à une info de
plus à laquelle il ne devrait pas avoir accés.

Si mon disque est préalablement chiffré, admettons:
moiuaezpoiqezrnmalekjf(...) , la version après écriture du fichier chiffré
sera donc:
tujbfgzpoiqezrnmalekjf(...)

J'ai l'impression de manquer une étape qui m'expliquerait pourquoi
il est néecessaire que le disque soit chiffré avant utilisation.


ce n'est pas nécessaire, mais c'est plus sûr.
Et que le disque n'a pas besoin d'être chiffré a priori,
il faut avoir des données _aléatoires_ au départ.

--
Mathieu



Kevin Denis
Le #598971
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

En quoi le fait de connaitre les 0 qui sont presents _avant_ l'ecriture


est il une faille de securite? Mis à part de pouvoir intuiter la taille
des données copiées sur le support, ou est la faille cryptographique?


c'est déjà pas mal, dans le sens où l'attaquant a accés à une info de
plus à laquelle il ne devrait pas avoir accés.

Oui, je suis bien d'accord, mais les textes conseillant le remplissage de

données aléatoires parlent bien d'attaques crypto. Sinon, pourquoi
devoir utiliser du "high quality random data"?

J'ai l'impression de manquer une étape qui m'expliquerait pourquoi
il est néecessaire que le disque soit chiffré avant utilisation.


ce n'est pas nécessaire, mais c'est plus sûr.


Aucun problème la dessus.
--
Kevin




Mathieu SEGAUD
Le #598970
Kevin Denis
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

En quoi le fait de connaitre les 0 qui sont presents _avant_ l'ecriture


est il une faille de securite? Mis à part de pouvoir intuiter la taille
des données copiées sur le support, ou est la faille cryptographique?


c'est déjà pas mal, dans le sens où l'attaquant a accés à une info de
plus à laquelle il ne devrait pas avoir accés.

Oui, je suis bien d'accord, mais les textes conseillant le remplissage de

données aléatoires parlent bien d'attaques crypto. Sinon, pourquoi
devoir utiliser du "high quality random data"?


parce que, prenons le cas suivant:

tu fais:
dd if=/dev/zero of=/dev/cryptfs

là tu as rempli ta partition "claire" de 0

ensuyite:
cryptsetup create /dev/crypts cryptfs

alors /dev/mapper/cryptfs est chiffrée

e2fsck -j /dev/mapper/cryptfs
mount /dev/mapper/cryptfs /mnt

cp gros_fichier.tar.gz /mnt
umount /dev/mapper/cryptfs

le problème est:

/dev/cryptfs contient ghkJNFLA,NZVNKZNVQNNbjhargjn000000000000000
/dev/mapper/cryptfs hhhhhhhhhhhhhhhhhhhhhhhhhhhhkhqknganegnijnk

avec dd il peut récupérer une grosse partie de texte chiffré dont il
connait le texte clair car il a une idée que ce sont encore des 0 qui
sont dessus.
là se trouve la faille

je me disais bien :)

--
Mathieu





Kevin Denis
Le #598737
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."






parce que, prenons le cas suivant:

tu fais:
dd if=/dev/zero of=/dev/cryptfs

là tu as rempli ta partition "claire" de 0

ensuyite:
cryptsetup create /dev/crypts cryptfs

alors /dev/mapper/cryptfs est chiffrée

e2fsck -j /dev/mapper/cryptfs


mke2fs plutot, mais ok.

mount /dev/mapper/cryptfs /mnt

cp gros_fichier.tar.gz /mnt
umount /dev/mapper/cryptfs

le problème est:

/dev/cryptfs contient ghkJNFLA,NZVNKZNVQNNbjhargjn000000000000000
/dev/mapper/cryptfs hhhhhhhhhhhhhhhhhhhhhhhhhhhhkhqknganegnijnk

Je ne comprends pas pourquoi un tar.gz se transforme en repetition

de caracteres identiques?

avec dd il peut récupérer une grosse partie de texte chiffré dont il
connait le texte clair car il a une idée que ce sont encore des 0 qui
sont dessus.
là se trouve la faille

tu peux reprendre plus doucement?


dd va permettre de recuperer du texte chiffre (depuis /dev/cryptfs
donc). Le cryptanalyste connait le texte clair? Cela veut dire qu'on se
place dans un cas d'ecole ou l'on dispose a la fois du clair et du
chiffre? Dans ce cas d'école quel interet de mettre avant copie
des données aléatoires?

je me disais bien :)

Je ne vois toujours pas ou intervient le probleme de remplissage de

données aléatoires avant chiffrement.
--
Kevin






Mathieu SEGAUD
Le #598736
Kevin Denis
Le 17-12-2007, Mathieu SEGAUD
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."






parce que, prenons le cas suivant:

tu fais:
dd if=/dev/zero of=/dev/cryptfs

là tu as rempli ta partition "claire" de 0

ensuyite:
cryptsetup create /dev/crypts cryptfs

alors /dev/mapper/cryptfs est chiffrée

e2fsck -j /dev/mapper/cryptfs


mke2fs plutot, mais ok.

mount /dev/mapper/cryptfs /mnt

cp gros_fichier.tar.gz /mnt
umount /dev/mapper/cryptfs

le problème est:

/dev/cryptfs contient ghkJNFLA,NZVNKZNVQNNbjhargjn000000000000000
/dev/mapper/cryptfs hhhhhhhhhhhhhhhhhhhhhhhhhhhhkhqknganegnijnk

Je ne comprends pas pourquoi un tar.gz se transforme en repetition

de caracteres identiques?

avec dd il peut récupérer une grosse partie de texte chiffré dont il
connait le texte clair car il a une idée que ce sont encore des 0 qui
sont dessus.
là se trouve la faille

tu peux reprendre plus doucement?


dd va permettre de recuperer du texte chiffre (depuis /dev/cryptfs
donc). Le cryptanalyste connait le texte clair? Cela veut dire qu'on se
place dans un cas d'ecole ou l'on dispose a la fois du clair et du
chiffre? Dans ce cas d'école quel interet de mettre avant copie
des données aléatoires?

je me disais bien :)

Je ne vois toujours pas ou intervient le probleme de remplissage de

données aléatoires avant chiffrement.


prenons un disque rempli de 0 puis configuré avec dm-crypt et après un
peu de workload, son état est de la forme

/dev/hda1:
hbvjhbrkvnajznanvnoiuyé_"h"éb&"ç'u&hbcç0000000000000000......

ceci est un "texte" _clair_ d'après le fonctionnement de dm-crypt
le "texte" chiffré correspondant (inconnu a priori) possède des
caractéristiques bien précises, c'est un FS par exemple.
_Et_ une partie du texte chiffré (inconnu) a pour texte clair une
série consécutive de 0. Cette dernière information peut être utile
pour inverser l'effet du chainage par bloc par exemple, sous certaines
conditions précises, mais cela reste une information qui réduit
_considérablement_ la sécurité du chiffrement.

--
Mathieu







Patrick 'Zener' Brunet
Le #598179
Bonsoir.

"Kevin Denis"
je lis qu'il est toujours obligatoire de remplir de données
aléatoires un disque avant de le chiffrer:

http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice
" Note : if you want your encryption to defeat a full cryptoanalytic
attack, not just casual snooping, you need to fill the disk with high
quality random data."

J'ai du mal à comprendre. Lorsque je remplis mon disque, les
données sont chiffrées, et écrasent les données précedemment
inscrites. En quoi le fait que ces données précedemment inscrites
soient aléatoires ou bien connues influe-t'il sur une cryptanalyse?



L'idée est que l'effacement n'est jamais parfait (même si la lecture est
interprétée de manière numérique, il s'agit bien d'une superposition de
champs magnétiques, donc analogiques).

Donc c'est comme mettre un papier blanc insuffisamment opaque sur une page
imprimée. Avec du matériel spécial et si l'enjeu le justifie, on peut
arriver à déceler "l'impression" sous-jacente.

Si le papier masque est lui même imprimé, ça brouille mieux, sauf si on peut
procéder par soustraction d'un masque connu ou devinable, d'où l'idée
d'appliquer un masque aléatoire. Bref les bases de la crypto...

Bon en pratique, même avec un mauvais générateur aléatoire, il est plus
efficace de procéder à plusieurs recouvrements différents, même si c'est
plus long. J'avais lu un article qui parlait de 7 pour une récupération
garantie impossible "avec les moyens actuels" d'il y a 2 ans...

Bien entendu, à ce stade, il s'agit de secrets de très grande valeur !

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

A. Caspis
Le #598178
Kevin Denis wrote:
Mis à part de pouvoir intuiter la taille
des données copiées sur le support, ou est la faille cryptographique?
c'est déjà pas mal, dans le sens où l'attaquant a accés à une info de

plus à laquelle il ne devrait pas avoir accés.



En plus du volume des données, ça peut aider à déterminer le type
de partition, ce qui est utile pour monter ensuite une attaque à
clair connu. Par exemple un bloc chiffré au milieu d'une partition
pleine de zéros, c'est à coup sûr un superblock de secours.

Oui, je suis bien d'accord, mais les textes conseillant le remplissage de
données aléatoires parlent bien d'attaques crypto. Sinon, pourquoi
devoir utiliser du "high quality random data"?


Probablement parce qu'un attaquant compétent saurait distinguer un bloc
contenant du chiffré d'un bloc rempli par un générateur aléatoire faible
(du genre générateur congruentiel linéaire ou registre à décalage).

AC



Publicité
Poster une réponse
Anonyme