Attaque sur AES. disque préalablement rempli de zéros.
23 réponses
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.
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
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).
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 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
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.
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.
--{ 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.
--{ 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.
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 (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...
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.
^^^^^^^
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
OoO Lors de la soirée naissante du dimanche 06 janvier 2008, vers 17:05, Al disait:
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
OoO Lors de la soirée naissante du dimanche 06 janvier 2008, vers 17:05,
Al <aln@nospam.fr> disait:
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
OoO Lors de la soirée naissante du dimanche 06 janvier 2008, vers 17:05, Al disait:
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 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
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?
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
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.
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.
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 (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.
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.
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 (on) lundi 07 janvier 2008 21:14, Erwan David a écrit (wrote) :
mpg écrivait :
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.
Le (on) lundi 07 janvier 2008 21:14, Erwan David a écrit (wrote) :
mpg <manuel.pg@free.fr> écrivait :
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
Le (on) lundi 07 janvier 2008 21:14, Erwan David a écrit (wrote) :
mpg écrivait :
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
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 ?!
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 ?!
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 ?!
