Attaque sur AES. disque préalablement rempli de zéros.

Le 2008-01-07, Sylvain ecrivit:

je n'ai rien compris.
et c'est normal ici c'est fmc pas fr.??.linux ni fr.??.bash
si l'idée que vous présentez ne peux pas être décrite en français mais
seulement en commande shell, on a un problème.

En plus explicatif: Le chiffrement AES, permet, via une clé d'écrire ou

de lire des données. Il existe donc un point de vue, les données
chiffrées, et un second point de vue, les données en clair.

Le passage de l'un a l'autre est effectué par AES.

Maintenant, que se passe t'il si je demande a AES, via une clé de
me lire des données chiffrées? Il me les donne en clair. Il existe
donc bien un lien entre les données lues, et les données telles
qu'elles sont rendues par AES, après déchiffrement.

Fort de ce principe, je demande a AES de continuer a travailler
sauf que, oh surprise, les données initiales lues ne sont
qu'une suite de zéros. Les données après déchiffrement par AES
auront elles des propriétés qui permettront de casser la clé?

une fois cette hypothèse péniblement énoncée on fait / gagne quoi ?

C'est la question. Le fait d'avoir a disposition une grande quantite

de donnees dont le chiffré est une suite de zero permet il de
casser la cle de chiffrement, ou tout au moins de l'affaiblir?

hmm, est-ce qu'avoir 80 Go de '0' est mieux que seulement qlq méga ???

Vous vous meprenez. Quelques Go de 0 ne menent à rien. Par contre,
quelques Go de 0 déchiffrés par AES?

je peux vous en déserver qlq téra si vous les collectionnez ?!

J'en ai quelques uns en stock dans /dev/zero, merci.

--
Kevin

Le (on) mardi 08 janvier 2008 12:35, Kevin Denis a écrit (wrote) :

Fort de ce principe, je demande a AES de continuer a travailler
sauf que, oh surprise, les données initiales lues ne sont
qu'une suite de zéros. Les données après déchiffrement par AES
auront elles des propriétés qui permettront de casser la clé?

Je persiste à ne pas comprendre. Tu supposes que l'attaquant peut demander

le déchiffrement de données ? Mais l'attaque est finie (de façon
victorieuse) à ce moment, non ?

Bon, sinon, que ça soit des zéros ou pas, au fond on d'en fout. En supposant
que l'attaquant dispose de données en clair et des même données chiffrées
(même si je ne vois *vraiment* pas pourquoi tu supposes qu'il a les données
en clair), ça s'appelle une attaque à clair connu. Et plusieurs personnes
depuis le début du fil ont déjà dit qu'AES était censé bien résister à ce
genre d'attaques.

Vous vous meprenez. Quelques Go de 0 ne menent à rien. Par contre,
quelques Go de 0 déchiffrés par AES?

Une attaque à clair connu. Ni plus ni moins.

Manuel.

Bonjour,

linux permet de chiffrer un disque à l'aide de cryptsetup. Le chiffrement
par défaut utilisé est AES.

Imaginons un disque préalablement rempli de zéros. Le chiffrement utilisé
est AES à l'aide d'une clé non triviale. Imaginons un attaquant root sur
la machine qui ne dispose pas de la clé.

Il a donc a dispositions de très grandes quantités de données (plusieurs
giga au vu des disques actuels) dont le chiffré est une suite de zéros.

Ceci constitue t'il une faiblesse?

Merci

Bonsoir,

Vous faites une erreur

Vous initialisez votre disque avec des zéros et ensuite vous dites ces
zéros sont le chiffré de quelque chose par AES avec une clé non triviale
.... et là c'est faut.

En fait il faut d'abord créer le disque chiffré et ensuite le remplir
de zéro et la vous aurez des zéros crypter par AES.

Bonjour,

linux permet de chiffrer un disque à l'aide de cryptsetup. Le chiffrement
par défaut utilisé est AES.

Imaginons un disque préalablement rempli de zéros. Le chiffrement utilisé
est AES à l'aide d'une clé non triviale. Imaginons un attaquant root sur
la machine qui ne dispose pas de la clé.

Il a donc a dispositions de très grandes quantités de données (plusieurs
giga au vu des disques actuels) dont le chiffré est une suite de zéros.

Ceci constitue t'il une faiblesse?

Merci

Bonsoir,

Vous faites une erreur

Vous initialisez votre disque avec des zéros et ensuite vous dites ces
zéros sont le chiffré de quelque chose par AES avec une clé non triviale
.... et là c'est faut.

En fait il faut d'abord créer le disque chiffré et ensuite le remplir
de zéro et la vous aurez des zéros crypter par AES.

OoO Pendant le repas du mardi 08 janvier 2008, vers 19:43, mpg
<manuel.pg@free.fr> disait:

Je persiste à ne pas comprendre. Tu supposes que l'attaquant peut demander
le déchiffrement de données ? Mais l'attaque est finie (de façon
victorieuse) à ce moment, non ?

Bon, sinon, que ça soit des zéros ou pas, au fond on d'en fout. En supposant
que l'attaquant dispose de données en clair et des même données chiffrées
(même si je ne vois *vraiment* pas pourquoi tu supposes qu'il a les données
en clair), ça s'appelle une attaque à clair connu. Et plusieurs personnes
depuis le début du fil ont déjà dit qu'AES était censé bien résister à ce
genre d'attaques.

Pour le moment, il n'y a qu'une personne qui a dit ça
(Jean-Marc). Toutes les autres persistent à ne pas comprendre que c'est
le chiffré qui est une suite de 0.

Vous vous meprenez. Quelques Go de 0 ne menent à rien. Par contre,
quelques Go de 0 déchiffrés par AES?

Une attaque à clair connu. Ni plus ni moins.

Le clair n'est pas connu. On dispose de tout un tas de chiffrés dont
tout un tas sont remplis de 0.

Dit autrement, je dispose d'une clef X et de deux fonctions:
- encrypt_aes_cbc(key, data)
- decrypt_aes_cbc(key, data)

Je fais: decrypt_aes_cbc(X, 00000000000000000000000000). Pas plus pas
moins. L'attaquant n'obtient pas le résultat (c'est dire s'il ne connaît
rien). Est-ce que cela donne des informations pertinentes sur la clef
[1] ? Selon Jean-Marc, la réponse est non, c'est aussi mon avis, mais
on trouve comme conseil sur le net de remplir le disque de données
aléatoires avant d'appliquer cryptsetup pour éviter certaines
attaques. Le but de la question de Kevin est d'obtenir des billes pour
montrer que c'est une croyance sans fondement (ou l'inverse).

[1] C'est une question un peu bête car il y aura toujours
00000000000000000000000000 quelle que soit la clef que l'on choisit, ça
montre clairement que cette seule information ne vaut rien. Mais
imaginons que l'on dispose en plus d'autres informations qui séparemment
ne valent rien, mais combinées avec cette information, cela nous
donnerait des infos.
--
printk("What? oldfid != cii->c_fid. Call 911.n");
2.4.3 linux/fs/coda/cnode.c

OoO En cette soirée bien amorcée du mardi 08 janvier 2008, vers 22:26,
Sylvain <noSpam@mail.net> disait:

Bon, sinon, que ça soit des zéros ou pas, au fond on d'en fout. En supposant
que l'attaquant dispose de données en clair et des même données chiffrées
(même si je ne vois *vraiment* pas pourquoi tu supposes qu'il a les données
en clair), ça s'appelle une attaque à clair connu. Et plusieurs personnes
depuis le début du fil ont déjà dit qu'AES était censé bien résister à ce
genre d'attaques.

Pour le moment, il n'y a qu'une personne qui a dit ça
(Jean-Marc). Toutes les autres persistent à ne pas comprendre que c'est
le chiffré qui est une suite de 0.

une seule est suffisante non ?

Je n'ai jamais dit le contraire. Je contredisais juste le "plusieurs
personnes".

Une attaque à clair connu. Ni plus ni moins.

Le clair n'est pas connu. On dispose de tout un tas de chiffrés dont
tout un tas sont remplis de 0.

et on dispose de la bonne clé ? (et pourquoi on s'embête)

Non, où ai-je pu dire que l'on avait la clef ?

ou, et on teste toutes les clés AES 256 bits une à une ?
que le chiffré soit des '0' ou des '1' vous obtiendrez de la purée
tant que ce ne sera pas la bonne clé - et vous n'apprendrez rien à
préparer 1ko, 1Mo ou 1Go de purée.

Ça, c'est si on considère que AES correspond à un chiffrement parfait. À
part celui de Vernam, il n'en existe pas. AES a plein de propriétés
algébriques. La question initiale était de savoir si dans cette
utilisation atypique, on risquait de réveiller une faiblesse d'AES. J'ai
bien compris que ta réponse est non, j'en suis aussi convaincu, je
précise juste la question initiale qui a quand même été très mal
comprise.

Je fais: decrypt_aes_cbc(X, 00000000000000000000000000). Pas plus pas
moins. L'attaquant n'obtient pas le résultat (c'est dire s'il ne connaît

c'est "je" qui faid ou l'attaquant ??

Je fais. L'attaquant n'a pas clef.

[1] ? Selon Jean-Marc, la réponse est non, c'est aussi mon avis, mais
on trouve comme conseil sur le net de remplir le disque de données
aléatoires avant d'appliquer cryptsetup pour éviter certaines
attaques. Le but de la question de Kevin est d'obtenir des billes pour
montrer que c'est une croyance sans fondement (ou l'inverse).

ce conseil n'a rien à voir avec un problème (inexistant) de
déchiffrement de zéros!
il vise à:
- dissimuler une partition chiffré parmi un disque éventuellement non
entièrement utilisé
- minimiser le fait de rendre visible une information chiffrée (car ce
ne sera que du bruit parmi du bruit), cela non par crainte que cette
information chiffrée soit plus vulnérable mais seulement pour ne pas
révéler qu'il pourrait exister une telle information chiffrée.

Je veux bien y croire, mais les pages en question indiquent que c'est
pour préserver le secret de la clef:
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDeviceUsingLUKS

D'où la question (je me répète, mais c'est pour être sûr d'être compris)
initiale qui consistait à demander s'il y avait un fond de vérité dans
cette affirmation:

,----[ http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDeviceUsingLUKS ]
| It's good to fill an encrypted disk with initial random data. This
| makes breaking the passphrase so much harder. The below method is
| sufficient for a casual attack but is not 'random enough' to defeat
| sophisticated cryptographers. If you need that, use the '/dev/urandom'
| method below or read a good book on cryptography and random numbers!
`----
--
panic("Aarggh: attempting to free lock with active wait queue - shoot Andy");
2.0.38 /usr/src/linux/fs/locks.c

Le (on) mardi 08 janvier 2008 20:28, Vincent Bernat a écrit (wrote) :

Bon, sinon, que ça soit des zéros ou pas, au fond on d'en fout. En
supposant que l'attaquant dispose de données en clair et des même données
chiffrées (même si je ne vois *vraiment* pas pourquoi tu supposes qu'il a
les données en clair), ça s'appelle une attaque à clair connu. Et
plusieurs personnes depuis le début du fil ont déjà dit qu'AES était
censé bien résister à ce genre d'attaques.

Pour le moment, il n'y a qu'une personne qui a dit ça
(Jean-Marc). Toutes les autres persistent à ne pas comprendre que c'est
le chiffré qui est une suite de 0.

Autant pour moi (ou au temps, je ne sais jamais). Une personne, alors.

Vous vous meprenez. Quelques Go de 0 ne menent à rien. Par contre,
quelques Go de 0 déchiffrés par AES?

Une attaque à clair connu. Ni plus ni moins.

Le clair n'est pas connu. On dispose de tout un tas de chiffrés dont
tout un tas sont remplis de 0.

On est d'accords : le clair n'est pas connu. Mais la question était : « des

Go de 0 ne donnent rien, mais des Go des 0 décodés par AES ? ». J'ai
répondu que dans ce cas, si on connaît le clair et la chiffré, ça s'appelle
une attaque à clair connu. Mais comme je le précisais plus haut, je ne vois
pas pourquoi le clair serait connu de l'attaquant (ou alors il ne se prend
plus la tête sur le bruit et va regarder les données)...

Manuel.

Le (on) mardi 08 janvier 2008 20:17, Arnal a écrit (wrote) :

Il a donc a dispositions de très grandes quantités de données (plusieurs
giga au vu des disques actuels) dont le chiffré est une suite de zéros.

Donc, je persiste à croire que l'attaquant n'a pas les données. Il existe

des données, dont le chiffré est 0. C'est toujours vrai, donc ça n'apporte
rien. Le seul truc, c'est que *vous* pouvez facilement trouver
lesdites « données ». Bof.

Vous initialisez votre disque avec des zéros et ensuite vous dites ces
zéros sont le chiffré de quelque chose par AES avec une clé non triviale
.... et là c'est faut.

Non, c'est vrai. Les 0 sont le chiffré de quelque chose puisque le

chiffrement par AES est une bijection. Après, je prétends que le quelque
chose en question est inintéressant pour tout le monde (j'ai peut-être tort
sur ce point), et qu'il n'est de toutes façons pas connu de l'attaquant.

En fait il faut d'abord créer le disque chiffré et ensuite le remplir
de zéro et la vous aurez des zéros crypter par AES.

Justement, il ne parle pas de zéros cryptés par AES. Il parle de
zéros /arbitrairement interprêtés/ comme le chiffré de quelque chose par
AES. Disons que si on y va comme ça, mon disque dur n'étant pas crypté, je
peux quand même affirmer que son contenu est le chiffré de quelque chose
par AES avec la clé que je veux : c'est tautologique et à mon avis ça
n'apporte rien à personne.

Manuel.

--{ remy a plopé ceci: }--

sinon à part ça je te déconseille sed

Parce que ses lignes de commandes sont trop cryptiques ?

--
I don't know of any implementations of lazy allocation in a 64 bit
address space. It would open some interesting possibilities. You could
probably memory map the internet! --{ JA, in comp.lang.fortran }--

Le (on) mardi 08 janvier 2008 20:28, Vincent Bernat a écrit (wrote) :

Une attaque à clair connu. Ni plus ni moins.
Le clair n'est pas connu. On dispose de tout un tas de chiffrés dont

tout un tas sont remplis de 0.

On est d'accords : le clair n'est pas connu. Mais la question était : « des

Go de 0 ne donnent rien, mais des Go des 0 décodés par AES ? ». J'ai
répondu que dans ce cas, si on connaît le clair et la chiffré, ça s'appelle
une attaque à clair connu. Mais comme je le précisais plus haut, je ne vois
pas pourquoi le clair serait connu de l'attaquant (ou alors il ne se prend
plus la tête sur le bruit et va regarder les données)...

ben vu que le type est connecté en root il peut lire la partition
déchiffrée ...
ce qui donne le déchiffrement des zéro.

il a donc le clair, la partition crypt
le chiffré, la partition physique.

s'il n'était pas connecté sur l'OS il n'aurait pas accès au déchiffré.
peut être juste au chiffré en lisant le disque dur hors du PC

ya un problème de clarté et de stabilité du problème exprimé....

on a l'air aussi de voulor chercher les clés. or d'après certains, il
suffit à root de les demander... mais ca je crois c'est évitable en
changeant le soft.

reste que je persiste que l'attaque la plus logique dans ce cas est une
attaque à clair choisi. on écrit sur une des partition chiffré ou pas,
et on voir le résulat sur l'autre.

l'autre point des de voir s'il n'y a pas des chainages de blocs et des
dépendance au numéro de bloc