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

Le
Kevin Denis
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
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
A. Caspis
Le #601133
Kevin Denis wrote:
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é.


Comme tout le monde va proposer:

# dmsetup table --showkeys

on peut imaginer de plus que le dispositif de chiffrement est
du genre FIPS 140-2 niveau 3 (c'est à dire avec une interface
séparée pour la gestion des clés).

AC

Al
Le #601132
le chiffré sauf chance incroyable n'a pas de raison d'être des zéro.
je suppose que tu parle d'un disque plein de clair zéro, écrits sous
forme de chiffré, qui ressemblera a de l'aléatoire.

je connais pas cryptsetup, mais:
si cryptsetup chiffre chaque bloc indépendemment sans ajouter de donnée
variable, alors tout les bloc a zéro auront la même valeur.
ce sera simple a détecter, et ca permettra de faire une analyse du
remplissage du disque.
l'analyse de remplissage est très utile pour détecter si une chose
importante est stockée dessus, si une opération est en cours...

par contre le chiffrement du bloc zero ne donne qu'un seul couple
clair-chiffré. mais comme ce bloc zéro est commun a tout les disque, un
groupe peut se faire un dictionnaire de toutes les manières de chiffrer
zéro (est-ce les rainbow table). ca suppose que la clé est pas trop
grande. 56 est a la portée de gens puissants (512milliers de To), 64
bits est a la portée peut être de la NSA (128 millions de To, ie de
disques), quoique... 128 bits, n'y pensons même pas...
tout ca si les algo sont solides (attaquables uniquement par force
brute, ce qui est probable car la NSA sais bien que tout secret fini par
fuiter ou être redécouvert avec le temps, et a du faire de son mieux,
comme avec le DES)

ensuite si on ajoute une donnée déterministes (numéro de bloc par
exemple) au bloc, on obtient les versions chiffrées de pas mal de bloc
connus... moins utiles

si c'est du bruit que l'on rajoute, on n'a plus trop de trucs prévisible
sur lesquels se reposer...

bref, a mon avis ajouter au bon endroit un bloc de 128 bits aléatoires ,
au début de chainage de bloc du bloc disque (eh oui il y a deux niveaux
de bloc ici, bloc chiffrement et bloc disque), ca neutralise l'attaque a
clair connu ...
reste a attaquer le générateur aléatoire.
si le générateur est bon, par exemple en étant couplé à un système de
chiffrement en boucle et a un bon hash en sortie, afin d'étaler les
éventuels faiblesse du générateur... enfin je dis ca, mais il doit y
avoir des gens qui ont étudié le soucis (lire la doc de cryptsetup, de
dev/random, et les grans bouquins genre applied cryptography de bruce
schneier)



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


Thierry B.
Le #600914
--{ Kevin Denis a plopé ceci: }--

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

Tu voulais dire le clair, là ?


--
Q. What kind of moron includes Arabic symbols that can't be displayed in most
fonts in the From: header just because they look nice on his/her own screen?
A. A Google-Groping kind of moron.

mpg
Le #600913
Le (on) dimanche 06 janvier 2008 18:21, Thierry B. a écrit (wrote) :

--{ Kevin Denis a plopé ceci: }--

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

Tu voulais dire le clair, là ?

Ah, je suis as le seul à trouver ça louche...



Vincent Bernat
Le #600912
OoO Lors de la soirée naissante du dimanche 06 janvier 2008, vers 17:05,
Al
le chiffré sauf chance incroyable n'a pas de raison d'être des zéro.
je suppose que tu parle d'un disque plein de clair zéro, écrits sous
forme de chiffré, qui ressemblera a de l'aléatoire.


Non, le chiffré est une suite de 0.

On prend un disque rempli de 0. On demande au système de le chiffrer
avec une clef X. Le système ne fait absolument rien, il considère que le
disque est chiffré avec la clef X. On obtient donc un chiffré rempli de
0.
--
IT'S POTATO, NOT POTATOE
IT'S POTATO, NOT POTATOE
IT'S POTATO, NOT POTATOE
-+- Bart Simpson on chalkboard in episode 7F01

Kevin Denis
Le #600910
Le 2008-01-07, Sylvain ecrivit:
Non, le chiffré est une suite de 0.


cela ne se peux pas (à une probabilité nulle) si ce chiffré resulte d'un
chiffrement.

On prend un disque rempli de 0.


un disque dont le clair est rempli de 0 ?


dd if=/dev/zero of=/dev/hda1
Le disque est rempli de zeros, actuellement, il n'y a ni clair, ni
chiffré, seulement un disque dont la partition est remplie de zéros.

ou, une fois rempli de zéro, faisons-nous comme s'il était chffré?
(alors qu'il ne l'a pas été).

si.

cryptsetup create c_hda1 /dev/hda1
(saisie de la cle)

Un mapping est créé, ce mapping fait juste le lien entre un
disque chiffré (le /dev/hda1) et un disque en clair ( /dev/mapper/c_hda1)

On demande au système de le chiffrer avec une clef X.
Le système ne fait absolument rien


?!? quand vous demandez "au système" de chiffrer, il ne fait "absolument
rien" ??? et c'est ce que vous attendez ? c'est un système capricieux ?
il aime pas qu'on lui demande ?

Pas de fausse ironie, SVP.


il considère que le disque est chiffré avec la clef X.
On obtient donc un chiffré rempli de 0.


donc vous vouliez dire: faisons comme si cette suite de zéro résultait
d'un chiffrement qui n'a jamais été fait.

Maintenant, je fais un

cat /dev/mapper/c_hda1
J'ai une suite d'octets. Ces octets sont la version claire dont le
chiffré est une suite de zéros. Et oui, le chiffré, c'est ce qui est
sur le disque ( /dev/hda1 ), le clair ce qui est sur /dev/mapper/c_hda1

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?

--
Kevin


Jean-Marc Desperrier
Le #600909
Kevin Denis 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.
dont le clair

Ceci constitue t'il une faiblesse?


AES est réputé insensible aux attaques clair/chiffré.

pour info il est très peu probable que l'on chiffre directement des
zéros, car on utilise certainement un mode de chaînage des blocs et des
vecteurs d'initialisation pour faire varier le résultat chiffré.
En quelque sorte, ça augmente les "risques", car n'avoir qu'un seul
résultat, celui du chiffrement d'une suite de zéro, représenterait très
peu d'information, alors qu'ici les données sont toujours des zéro, mais
ce que l'on a sous la main est le résultat du chiffrement de ces zéro
avec des dizaines de milliers de valeurs de vecteur d'initialisation
différents.

M'enfin cela fait vraiment partie du "cahier des charges" de base de
l'AES de rester parfaitement solide dans cette situation, donc il n'y a
franchement pas de raison de s'inquiéter.

mpg
Le #600908
Le (on) lundi 07 janvier 2008 09:29, Kevin Denis a écrit (wrote) :
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?

Si tout se passe comme tu le décris, il n'y pas de *données* dont le chiffré

est une suite de zéros. Il y a une suite de zéros, point-barre. Cette suite
n'est le chiffré de rien du tout. Une partie des octets
de /dev/mapper/c_hda1 est « aléatoire », ou plus précisément n'est pas
initialisée.

Manuel.


mpg
Le #600676
Le (on) lundi 07 janvier 2008 21:14, Erwan David a écrit (wrote) :

mpg
Si tout se passe comme tu le décris, il n'y pas de *données* dont le
chiffré est une suite de zéros. Il y a une suite de zéros, point-barre.
Cette suite n'est le chiffré de rien du tout. Une partie des octets
de /dev/mapper/c_hda1 est « aléatoire », ou plus précisément n'est pas
initialisée.


Par contre on peut obtenir le *déchiffré* d'une grande suite de zéros :
est-ce que ça a une incidence ?

Qui, on ? A priori l'attaquant n'a pas accès au déchiffré, ou alors quelque

chose d'essentiel m'a échappé...

Manuel.


Sylvain
Le #600675
Kevin Denis wrote on 07/01/2008 09:29:

dd if=/dev/zero of=/dev/hda1
cryptsetup create c_hda1 /dev/hda1
cat /dev/mapper/c_hda1


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.

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 ???
je peux vous en déserver qlq téra si vous les collectionnez ?!

Sylvain.


Publicité
Poster une réponse
Anonyme