Je recherche un logiciel qui me permeterais d'effacer mon disque dur au
complet, un effacement permanent pour qu'il soit impossible de retrouver le
moindre fichier, j'aimerais aussi qu'il soit possible de lancer l'effacement
avec un combinaison de touche.
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec des O, et que lorsque de la lecture on trouve des traces de 1 et des traces de 0, on pourra déduire de tout cela que la valeur initiale était sans doute 1.
Nicob
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin
d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec
des O, et que lorsque de la lecture on trouve des traces de 1 et des
traces de 0, on pourra déduire de tout cela que la valeur initiale était
sans doute 1.
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec des O, et que lorsque de la lecture on trouve des traces de 1 et des traces de 0, on pourra déduire de tout cela que la valeur initiale était sans doute 1.
Nicob
Emmanuel Florac
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ??
On n'a pas besoin d'un aléa pour un wipping, mais juste de "code
poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut
pas abuser.
R.Debray
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Pierre BETOUIN
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec des O, et que lorsque de la lecture on trouve des traces de 1 et des traces de 0, on pourra déduire de tout cela que la valeur initiale était sans doute 1.
Nicob Je suis bien d'accord sur le /dev/null (trop voyant), mais ce que je veux
dire, c'est qu'un aléa "pûr" ne rendrait pas la situation plus fiable à mon avis. Je ne suis pas certain que sur la totalité des secteurs d'un DD, on puisse savoir, pour un partie de celui-ci, s'il s'agit de données effacées, ou d'un aléa (pseudo soit-il) rajouté par un wipping...
On n'arrivera sûrement pas à déceler l'aléa, surtout qu'il existe bcp de moteurs différents, et que, à part pour une zone de 1GO, je ne suis pas sûr qu'un algo de reconnaissance puisse y faire gd chose car l'échantillon doit être assez conséquent.
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
°°°°°°°°°----------------°°°°°°°°°
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas
besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec
des O, et que lorsque de la lecture on trouve des traces de 1 et des
traces de 0, on pourra déduire de tout cela que la valeur initiale était
sans doute 1.
Nicob
Je suis bien d'accord sur le /dev/null (trop voyant), mais ce que je veux
dire, c'est qu'un aléa "pûr" ne rendrait pas la situation plus fiable à
mon avis. Je ne suis pas certain que sur la totalité des secteurs d'un
DD, on puisse savoir, pour un partie de celui-ci, s'il s'agit de données
effacées, ou d'un aléa (pseudo soit-il) rajouté par un wipping...
On n'arrivera sûrement pas à déceler l'aléa, surtout qu'il existe bcp
de moteurs différents, et que, à part pour une zone de 1GO, je ne suis
pas sûr qu'un algo de reconnaissance puisse y faire gd chose car
l'échantillon doit être assez conséquent.
--
°°°°°°°°°----------------°°°°°°°°°
Pierre BETOUIN
soulrider@unsigned.ath.cx
°°°°°°°°°----------------°°°°°°°°°
On Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN wrote:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Si l'attaquant "sait" que les données ont été plutôt écrasées avec des O, et que lorsque de la lecture on trouve des traces de 1 et des traces de 0, on pourra déduire de tout cela que la valeur initiale était sans doute 1.
Nicob Je suis bien d'accord sur le /dev/null (trop voyant), mais ce que je veux
dire, c'est qu'un aléa "pûr" ne rendrait pas la situation plus fiable à mon avis. Je ne suis pas certain que sur la totalité des secteurs d'un DD, on puisse savoir, pour un partie de celui-ci, s'il s'agit de données effacées, ou d'un aléa (pseudo soit-il) rajouté par un wipping...
On n'arrivera sûrement pas à déceler l'aléa, surtout qu'il existe bcp de moteurs différents, et que, à part pour une zone de 1GO, je ne suis pas sûr qu'un algo de reconnaissance puisse y faire gd chose car l'échantillon doit être assez conséquent.
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
°°°°°°°°°----------------°°°°°°°°°
Your Name
Emmanuel Florac wrote:
Dans article <3fae69a6$0$2799$, disait...
Non c'est impossible. Fait 2 passes de cat /dev/urandom et du ne retrouvera plus rien quelque soit l'equipement.
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé comme codes russes dans les années 50? :)
Non mais on est en 2003 !
/dev/urandom n'est pas aléatoire, déjà, c'est un problème.
Aucun probleme, pas besoin d'etre vraiment aleatoire.
Et vous semblez oublier comment sont fait les disques actuels: par exemple un Cheetah 36 Go contient en fait 47Go, à cause de l'espace réservé pour les badblocks auto-corrigés. Cet espace là ne peut jamais être réécrit par aucune action utilisateur...
Dans ce cas là oui...
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Emmanuel Florac wrote:
Dans article <3fae69a6$0$2799$626a54ce@news.free.fr>,
email@address.invalid disait...
Non c'est impossible. Fait 2 passes de cat /dev/urandom et du ne
retrouvera plus rien quelque soit l'equipement.
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé
comme codes russes dans les années 50? :)
Non mais on est en 2003 !
/dev/urandom n'est pas
aléatoire, déjà, c'est un problème.
Aucun probleme, pas besoin d'etre vraiment aleatoire.
Et vous semblez oublier comment sont
fait les disques actuels: par exemple un Cheetah 36 Go contient en fait
47Go, à cause de l'espace réservé pour les badblocks auto-corrigés. Cet
espace là ne peut jamais être réécrit par aucune action utilisateur...
Dans ce cas là oui...
donc une fois enregistré comme "badblock" (mais sûrement lisible par
autre chose que la tête du disque), un block ne peut plus être réécrit
pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque,
silencieusement rendu innaccessible!
Non c'est impossible. Fait 2 passes de cat /dev/urandom et du ne retrouvera plus rien quelque soit l'equipement.
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé comme codes russes dans les années 50? :)
Non mais on est en 2003 !
/dev/urandom n'est pas aléatoire, déjà, c'est un problème.
Aucun probleme, pas besoin d'etre vraiment aleatoire.
Et vous semblez oublier comment sont fait les disques actuels: par exemple un Cheetah 36 Go contient en fait 47Go, à cause de l'espace réservé pour les badblocks auto-corrigés. Cet espace là ne peut jamais être réécrit par aucune action utilisateur...
Dans ce cas là oui...
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Your Name
Emmanuel Florac wrote:
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
Bref, pour une utilisation "domestique" (nettoyage poste Windows) /dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre des jours!
Emmanuel Florac wrote:
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ??
On n'a pas besoin d'un aléa pour un wipping, mais juste de "code
poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
Bref, pour une utilisation "domestique" (nettoyage poste Windows)
/dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois
fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre
des jours!
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Quel est le problème ici s'il est pseudo-aléatoire ?? On n'a pas besoin d'un aléa pour un wipping, mais juste de "code poubelle", non?
Dans ce cas-là, pourquoi /dev/urandom plutôt que /dev/zero, selon toi?
Bref, pour une utilisation "domestique" (nettoyage poste Windows) /dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre des jours!
Eric Razny
"Your Name" a écrit dans le message de news:3fafeec5$0$234$
Emmanuel Florac wrote:
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Bref, pour une utilisation "domestique" (nettoyage poste Windows) /dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre des jours!
Non. Tu confonds /dev/urandom et /dev/random.
Le second donne un "vrai" aléa et s'arrête faute d'entropie suffisante (et là ce n'est pas des jours mais des années voir plus qu'il va te falloir pour parcourir ton hd si tu as une activité "classique" sur ta machine).
Le premier continue en s'appuyant sur un générateur de pseudo-alea (seed) et n'est pas bloquant.
Si tu as un doute essaye un cat sur les deux périph...
Eric
"Your Name" <email@address.invalid> a écrit dans le message de
news:3fafeec5$0$234$636a55ce@news.free.fr...
Emmanuel Florac wrote:
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Bref, pour une utilisation "domestique" (nettoyage poste Windows)
/dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois
fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre
des jours!
Non.
Tu confonds /dev/urandom et /dev/random.
Le second donne un "vrai" aléa et s'arrête faute d'entropie suffisante (et
là ce n'est pas des jours mais des années voir plus qu'il va te falloir pour
parcourir ton hd si tu as une activité "classique" sur ta machine).
Le premier continue en s'appuyant sur un générateur de pseudo-alea (seed) et
n'est pas bloquant.
Si tu as un doute essaye un cat sur les deux périph...
"Your Name" a écrit dans le message de news:3fafeec5$0$234$
Emmanuel Florac wrote:
Le Mon, 10 Nov 2003 11:07:52 +0000, Pierre BETOUIN écrivait:
Bref, pour une utilisation "domestique" (nettoyage poste Windows) /dev/zero suffit LARGEMENT !
Evidement si tu es mafieux, pedophile, ou si tu geres les emplois fictifs de l'UMP, /dev/urandom s'impossent, mais ca doit prendre des jours!
Non. Tu confonds /dev/urandom et /dev/random.
Le second donne un "vrai" aléa et s'arrête faute d'entropie suffisante (et là ce n'est pas des jours mais des années voir plus qu'il va te falloir pour parcourir ton hd si tu as une activité "classique" sur ta machine).
Le premier continue en s'appuyant sur un générateur de pseudo-alea (seed) et n'est pas bloquant.
Si tu as un doute essaye un cat sur les deux périph...
Eric
Nicob
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça. Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks. Mais il doit y avoir moyen de sortir les plateaux et de les analyser "à la main", mais c'est pas les mêmes coûts.
Quelqu'un peut confirmer ?
Nicob
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par
autre chose que la tête du disque), un block ne peut plus être
réécrit pour masquer son contenu... Et ça peut représenter jusqu'à
30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça.
Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks. Mais il
doit y avoir moyen de sortir les plateaux et de les analyser "à la main",
mais c'est pas les mêmes coûts.
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça. Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks. Mais il doit y avoir moyen de sortir les plateaux et de les analyser "à la main", mais c'est pas les mêmes coûts.
Quelqu'un peut confirmer ?
Nicob
Emmanuel Florac
Dans article <3fafed86$0$13268$, disait...
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé comme codes russes dans les années 50? :)
Non mais on est en 2003 !
Et bien il y a plus de 50 ans, les ricains ont cassés des codes aléatoires à clef unique, de même longueur que le message. C'est à dire des codes théoriquement incassables (comme chacun sait, en théorie la théorie et la pratique c'est la même chose, mais pas en pratique...)
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Rien ne l'écrase, c'est innaccessible et invisible, sauf pour le contrôleur du disque, ou en attaquant le disque directement. Par l'interface du disque, aucune action ne peut atteindre ces zones.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fafed86$0$13268$626a54ce@news.free.fr>,
email@address.invalid disait...
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé
comme codes russes dans les années 50? :)
Non mais on est en 2003 !
Et bien il y a plus de 50 ans, les ricains ont cassés des codes
aléatoires à clef unique, de même longueur que le message. C'est à dire
des codes théoriquement incassables (comme chacun sait, en théorie la
théorie et la pratique c'est la même chose, mais pas en pratique...)
donc une fois enregistré comme "badblock" (mais sûrement lisible par
autre chose que la tête du disque), un block ne peut plus être réécrit
pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque,
silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Rien ne l'écrase, c'est innaccessible et invisible, sauf pour le
contrôleur du disque, ou en attaquant le disque directement. Par
l'interface du disque, aucune action ne peut atteindre ces zones.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Je ne parierais pas là-dessus. Tu as vu ce que les ricains ont cassé comme codes russes dans les années 50? :)
Non mais on est en 2003 !
Et bien il y a plus de 50 ans, les ricains ont cassés des codes aléatoires à clef unique, de même longueur que le message. C'est à dire des codes théoriquement incassables (comme chacun sait, en théorie la théorie et la pratique c'est la même chose, mais pas en pratique...)
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Rien ne l'écrase, c'est innaccessible et invisible, sauf pour le contrôleur du disque, ou en attaquant le disque directement. Par l'interface du disque, aucune action ne peut atteindre ces zones.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Your Name
Nicob wrote:
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça. Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks.
S'il accede au disque avec le protocol normal, mais sinon?
Mais il doit y avoir moyen de sortir les plateaux et de les analyser "à la main", mais c'est pas les mêmes coûts.
Quelqu'un peut confirmer ?
Pourquoi devoir les sortir? Les tetes on bien su y acceder pour lire/ecrire les zones defectueuses sans avoir avoir le disque!
Nicob wrote:
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par
autre chose que la tête du disque), un block ne peut plus être
réécrit pour masquer son contenu... Et ça peut représenter jusqu'à
30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça.
Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks.
S'il accede au disque avec le protocol normal, mais sinon?
Mais il
doit y avoir moyen de sortir les plateaux et de les analyser "à la main",
mais c'est pas les mêmes coûts.
Quelqu'un peut confirmer ?
Pourquoi devoir les sortir? Les tetes on bien su y acceder pour
lire/ecrire les zones defectueuses sans avoir avoir le disque!
On Mon, 10 Nov 2003 21:10:22 +0000, Your Name wrote:
donc une fois enregistré comme "badblock" (mais sûrement lisible par autre chose que la tête du disque), un block ne peut plus être réécrit pour masquer son contenu... Et ça peut représenter jusqu'à 30% du disque, silencieusement rendu innaccessible!
cat n'ecrasse pas tous ca?
Non, bicoz (il me semble) que c'est le contrôleur du disque qui gère ça. Le BIOS et l'OS ne "voient" pas le moins du monde ces badblocks.
S'il accede au disque avec le protocol normal, mais sinon?
Mais il doit y avoir moyen de sortir les plateaux et de les analyser "à la main", mais c'est pas les mêmes coûts.
Quelqu'un peut confirmer ?
Pourquoi devoir les sortir? Les tetes on bien su y acceder pour lire/ecrire les zones defectueuses sans avoir avoir le disque!
Your Name
Emmanuel Florac wrote:
Et bien il y a plus de 50 ans, les ricains ont cassés des codes aléatoires à clef unique, de même longueur que le message. C'est à dire des codes théoriquement incassables (comme chacun sait, en théorie la théorie et la pratique c'est la même chose, mais pas en pratique...)
Un bon encryptage est irreversible et le sera toujours
Emmanuel Florac wrote:
Et bien il y a plus de 50 ans, les ricains ont cassés des codes
aléatoires à clef unique, de même longueur que le message. C'est à dire
des codes théoriquement incassables (comme chacun sait, en théorie la
théorie et la pratique c'est la même chose, mais pas en pratique...)
Un bon encryptage est irreversible et le sera toujours
Et bien il y a plus de 50 ans, les ricains ont cassés des codes aléatoires à clef unique, de même longueur que le message. C'est à dire des codes théoriquement incassables (comme chacun sait, en théorie la théorie et la pratique c'est la même chose, mais pas en pratique...)
Un bon encryptage est irreversible et le sera toujours
