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

Le 19-12-2007, Patrick 'Zener' Brunet a écrit :

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).

Je ne saisis pas le rapport entre le remplissage prealable de donnees

aleatoires et des problemes d'effacements imparfaits ?

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 !

Je suis entierement d'accord (meme si je n'ai jamais trouve

un document clair synthetisant ces histoires de 7 recouvrements
et des recuperations de donnees), mais je ne vois pas le lien avec
mon post original.
--
Kevin

Le 19-12-2007, A. Caspis <a_caspis@yahoo.com> a écrit :

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.

Vu le petit nombre de systèmes de fichiers existant, je ne pense

pas que ceci soit important. De plus, je considere que c'est connu.
Un thread de ce groupe en parlait recemment;

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).

Ok. Quelle information cruciale pourrait en tirer un attaquant?

--
Kevin

Le 17-12-2007, Mathieu SEGAUD <mathieu.segaud@regala.cx> a écrit :

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."

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......

Ok

ceci est un "texte" _clair_ d'après le fonctionnement de dm-crypt

Non, chiffré. Le device /dev/hda1 est chiffré. C'est /dev/mapper/crypted
qui est en clair.

le "texte" chiffré correspondant (inconnu a priori) possède des
caractéristiques bien précises, c'est un FS par exemple.

Le texte chiffré n'est pas un FS, il est chiffré.

_Et_ une partie du texte chiffré (inconnu) a pour texte clair une
série consécutive de 0.

Si j'inverse le sens de clair et chiffré, je te suis.

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.

Donc, si je resume, un attaquant va utiliser la vision qu'il a de

/dev/mapper/crypted sur une partie du disque remplie de zéro.
Bien évidemment, les octets correspondants sur /dev/mapper/crypted
sont chiffrés par la clé.
Ainsi, il serait plus facile de retrouver la clé de chiffrement
si l'on possède de grandes quantités de zéro consécutivement chiffrées
à l'aide de celle-ci.
Néanmoins, cela signifie que l'attaquant dispose d'un accès
à /dev/mapper/crypted, et donc que la clé a été entrée.

Donc dans un cas d'école ou je distribue un disque chiffré éteint,
le fait qu'il ait été préalablement rempli de données aléatoires
de 'high qualtiy', de low quality ou bien de zéro n'a pas
d'incidence sur la facilité qu'un cryptologue peut avoir à
trouver la clé (à la limite, il pourra intuiter la quantité
de données chiffrées, mais ca reste un peu cheap comme info).


Je fais définitivement fausse route, ou est-ce l'unique raison
qui impose de devoir mettre du "high quality random data" sur
les disques qui doivent être chiffrés?
--
Kevin

Kevin Denis wrote:

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.

Vu le petit nombre de systèmes de fichiers existant, je ne pense

pas que ceci soit important. De plus, je considere que c'est connu.

Je poursuis l'exemple des superblocks de secours:
Si le disque est rempli de zéros, l'attaquant peut facilement
identifier plusieurs dizaines de superblocks de secours, tous
alignés sur des débuts de blocs CBC, tous identiques, et dont
une partie du contenu est connu; c'est idéal pour monter une
attaque crypto. Même si les algos modernes sont censés y
résister, la prudence s'impose.

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

Ok. Quelle information cruciale pourrait en tirer un attaquant?

Si il sait faire cette distinction, alors il peut se ramener
au cas précédent (où le disque était rempli par des zéros).
Donc ça ne servirait à rien de remplir par de l'aléatoire de
trop mauvaise qualité. Ceci répond à une de tes questions
(pourquoi devoir utiliser du "high quality random data"?).

AC

Bonsoir.

"Kevin Denis" <kevin@nowher.invalid> a écrit dans le message de news:
slrnfn71hs.2gs.kevin@slackwall.local.tux...

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).

Je ne saisis pas le rapport entre le remplissage prealable de donnees

aleatoires et des problemes d'effacements imparfaits ?

Avec une surimpression parfaite, les données superposées écrasent totalement
les données à détruire, donc vous pouvez même le faire avec du 0 uniforme et
il n'en restera rien.
Mais si l'effacement est imparfait, les données à détruire subsistent sous
une forme atténuée en addition des données superposées. Tout le problème est
de savoir s'il est possible de les extraire par une lecture analogique.

J'avais utilisé cette métaphore qui me paraît limpide:

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...

Donc distinguer des traces sous un calque uniforme, c'est facile.
Sous un ou plusieurs calques imprimés (en gris puisque le masquage est
imparfait) d'un motif reconnaissable, c'est difficile mais on peu analyser
chaque point et en déduire s'il y a du blanc ou du gris en dessous des
motifs qui sont chacun d'un gris uniforme.
Si les calques sont mouchetés de manière aléatoire, même avec un gris
uniforme, cette analyse devient extrêmement difficile.

[...] je ne vois pas le lien avec mon post original.

Je vous donne une réponse à cette question:

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?

La clé est que l'effacement n'est jamais total.

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

"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> a écrit dans
le message de news: fl3umb$a8s$1@shakotay.alphanet.ch...

"Kevin Denis" <kevin@nowher.invalid> a écrit dans le message de news:
slrnfn71hs.2gs.kevin@slackwall.local.tux...

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."

[...]

[...] je ne vois pas le lien avec mon post original.

Je vous donne une réponse à cette question:

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?

La clé est que l'effacement n'est jamais total.

Je crois que je vois le quiproquo:

En fait ce sont les données de recouvrement qui doivent être aléatoires, si
on parle d'effacer un disque.

Sinon pour le chiffrement global d'un disque, il s'agit de combler le disque
(au-delà des données utiles) avec de l'aléatoire plutôt qu'avec des 0 par
exemple, afin de ne pas laisser une part de clair connue avant le
chiffrement, ce qui permettrait une attaque à clair partiellement connu du
chiffré global, qui peut fournir assez d'information pour ensuite attaquer
la partie utile (les données).

fill = remplir = combler dans ce cas, pas recouvrir.

Navré, je n'avais pas percuté tout de suite, les deux problèmes sont à
considérer séparément en fait.

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

Le 28-12-2007, Patrick 'Zener' Brunet a écrit :

Sinon pour le chiffrement global d'un disque, il s'agit de combler le disque
(au-delà des données utiles) avec de l'aléatoire plutôt qu'avec des 0 par
exemple, afin de ne pas laisser une part de clair connue avant le
chiffrement, ce qui permettrait une attaque à clair partiellement connu du
chiffré global, qui peut fournir assez d'information pour ensuite attaquer
la partie utile (les données).

Ok, y a t'il un lien, une doc explicitant ce point?

Navré, je n'avais pas percuté tout de suite, les deux problèmes sont à
considérer séparément en fait.

Je le pense aussi.

--
Kevin

Bonsoir.

"Kevin Denis" <kevin@nowher.invalid> a écrit dans le message de news:
slrnfncok9.2g3.kevin@slackwall.local.tux...

Sinon pour le chiffrement global d'un disque, il s'agit de combler le
disque
(au-delà des données utiles) avec de l'aléatoire plutôt qu'avec des 0
par
exemple, afin de ne pas laisser une part de clair connue avant le
chiffrement, ce qui permettrait une attaque à clair partiellement connu
du
chiffré global, qui peut fournir assez d'information pour ensuite
attaquer
la partie utile (les données).

Ok, y a t'il un lien, une doc explicitant ce point?

C'est une application de l'attaque à clair partiellement connu.
J'ai demandé à Google mais il est assez avare sur ce point, et en relâchant
les contraintes on trouve le Web entier...
C'est mieux en anglais avec "partial known plaintext". Mais bon j'ai pas que
ça à faire :-)

C'est une simple conséquence des principes de Kerckhoffs, dans la mesure ou
un algorithme de chiffrement embarqué ne peut pas utiliser un chiffre de
Vernam: l'existence de blancs prévisibles et souvent importants, ou même de
données de bourrage structurées, affaiblit forcément la sécurité.

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

OoO En cette fin de matinée radieuse du jeudi 27 décembre 2007, vers
11:27, Kevin Denis <kevin@nowher.invalid> disait:

Ainsi, il serait plus facile de retrouver la clé de chiffrement
si l'on possède de grandes quantités de zéro consécutivement chiffrées
à l'aide de celle-ci.

C'est l'inverse. Le chiffré, c'est 000000000000. Le clair n'est pas
connu. Cela ne donne à mon avis aucune information valable quand on
utilise un algorithme un tant soit peu sérieux.
--
/* James M doesn't say fuck enough. */
2.4.3 linux/net/core/netfilter.c

Le 2008-01-05, Vincent Bernat ecrivit:

Ainsi, il serait plus facile de retrouver la clé de chiffrement
si l'on possède de grandes quantités de zéro consécutivement chiffrées
à l'aide de celle-ci.

C'est l'inverse.

Tout a fait.

Le chiffré, c'est 000000000000. Le clair n'est pas
connu. Cela ne donne à mon avis aucune information valable quand on
utilise un algorithme un tant soit peu sérieux.

Je rouvre un nouveau thread, plus spécifique sur les attaques sur AES.

--
Kevin