Suppression sécurisée de fichier

Jean-Marc Bourguet

10/01/2006 à 18:10

Gregory Baudet writes:

Je me demande comment faut t'il s'y prendre pour effacer un fichier
completement en réécrivant sur le disque là où se trouvait le
fichier supprimé?

Il faut utiliser des methodes propres au S.E.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Gregory Baudet

10/01/2006 à 18:12

Jean-Marc Bourguet wrote:

Gregory Baudet writes:

Je me demande comment faut t'il s'y prendre pour effacer un fichier
completement en réécrivant sur le disque là où se trouvait le
fichier supprimé?

Il faut utiliser des methodes propres au S.E.

A+

Pourrais tu me donner quelques informations ou liens pour faciliter mais
recherche (en français ou anglais).
Merci

Fabien LE LEZ

10/01/2006 à 22:16

On Tue, 10 Jan 2006 18:12:20 +0100, Gregory Baudet
:

Pourrais tu me donner quelques informations ou liens pour faciliter mais
recherche (en français ou anglais).

C'est bien difficile de te donner des liens si on ne sait pas sur quel
OS tu programmes.
S'il s'agit de Microsoft Windows, cf http://msdn.microsoft.com.

Gregory Baudet

10/01/2006 à 22:57

Fabien LE LEZ wrote:

On Tue, 10 Jan 2006 18:12:20 +0100, Gregory Baudet
:

Pourrais tu me donner quelques informations ou liens pour faciliter mais
recherche (en français ou anglais).

C'est bien difficile de te donner des liens si on ne sait pas sur quel
OS tu programmes.
S'il s'agit de Microsoft Windows, cf http://msdn.microsoft.com.

Je souhaiterais avoir un logiciel qui puisse etre compilé sous windows
et linux et qui fonctionne sur les deux os.

Fabien LE LEZ

10/01/2006 à 23:39

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
:

Je me demande comment faut t'il s'y prendre pour effacer un fichier
completement en réécrivant sur le disque là où se trouvait le fichier
supprimé?

La solution "naïve" serait d'écrire des données bidon à l'intérieur du
fichier avant de le supprimer.
Seul petit inconvénient : je ne sais pas du tout si ça marche.

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des différents OS
(Windows et Linux en l'occurence), mais des différents systèmes de
fichiers : NTFS et FAT sous Windows, et les quelques systèmes
(courants ou moins courants) sous Linux.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe une
implémentation Linux d'un LFS (Log-structured File System), système
qui permet de ne jamais écraser des données (tant qu'on a de l'espace
libre sur le disque) : on se contente d'écrire les nouvelles données à
la suite, ce qui permet d'obtenir facilement une image du disque tel
qu'il était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.
Bon courage pour implémenter ton programme sur un tel système ;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire de
commencer à étudier les algorithmes à mettre en oeuvre, avant de
t'occuper de l'implémentation en quelque langage que ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon message ;
toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais sur un
disque virtuel (TrueCrypt), avec un mot de passe temporaire et très
long. Au moment d'effacer le fichier, je "dé-monte" (unmount) le
disque virtuel, et je m'empresse d'oublier le mot de passe. Le disque
virtuel (un fichier .tc sur le disque réel) n'est alors plus qu'un
magma indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre dans
la corbeille.
Bien sûr, il est conseillé d'éteindre puis rallumer le PC après
l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire l'intégralité du
disque dur avec un outil comme DBAN <http://dban.sourceforge.net/>.

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
<gregory_baudet@hotmail.com>:

Je me demande comment faut t'il s'y prendre pour effacer un fichier
completement en réécrivant sur le disque là où se trouvait le fichier
supprimé?

La solution "naïve" serait d'écrire des données bidon à l'intérieur du
fichier avant de le supprimer.
Seul petit inconvénient : je ne sais pas du tout si ça marche.

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des différents OS
(Windows et Linux en l'occurence), mais des différents systèmes de
fichiers : NTFS et FAT sous Windows, et les quelques systèmes
(courants ou moins courants) sous Linux.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe une
implémentation Linux d'un LFS (Log-structured File System), système
qui permet de ne jamais écraser des données (tant qu'on a de l'espace
libre sur le disque) : on se contente d'écrire les nouvelles données à
la suite, ce qui permet d'obtenir facilement une image du disque tel
qu'il était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.
Bon courage pour implémenter ton programme sur un tel système ;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire de
commencer à étudier les algorithmes à mettre en oeuvre, avant de
t'occuper de l'implémentation en quelque langage que ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon message ;
toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais sur un
disque virtuel (TrueCrypt), avec un mot de passe temporaire et très
long. Au moment d'effacer le fichier, je "dé-monte" (unmount) le
disque virtuel, et je m'empresse d'oublier le mot de passe. Le disque
virtuel (un fichier .tc sur le disque réel) n'est alors plus qu'un
magma indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre dans
la corbeille.
Bien sûr, il est conseillé d'éteindre puis rallumer le PC après
l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire l'intégralité du
disque dur avec un outil comme DBAN <http://dban.sourceforge.net/>.

Vous avez filtré cet utilisateur ! Consultez son message

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
:

Je me demande comment faut t'il s'y prendre pour effacer un fichier
completement en réécrivant sur le disque là où se trouvait le fichier
supprimé?

La solution "naïve" serait d'écrire des données bidon à l'intérieur du
fichier avant de le supprimer.
Seul petit inconvénient : je ne sais pas du tout si ça marche.

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des différents OS
(Windows et Linux en l'occurence), mais des différents systèmes de
fichiers : NTFS et FAT sous Windows, et les quelques systèmes
(courants ou moins courants) sous Linux.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe une
implémentation Linux d'un LFS (Log-structured File System), système
qui permet de ne jamais écraser des données (tant qu'on a de l'espace
libre sur le disque) : on se contente d'écrire les nouvelles données à
la suite, ce qui permet d'obtenir facilement une image du disque tel
qu'il était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.
Bon courage pour implémenter ton programme sur un tel système ;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire de
commencer à étudier les algorithmes à mettre en oeuvre, avant de
t'occuper de l'implémentation en quelque langage que ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon message ;
toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais sur un
disque virtuel (TrueCrypt), avec un mot de passe temporaire et très
long. Au moment d'effacer le fichier, je "dé-monte" (unmount) le
disque virtuel, et je m'empresse d'oublier le mot de passe. Le disque
virtuel (un fichier .tc sur le disque réel) n'est alors plus qu'un
magma indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre dans
la corbeille.
Bien sûr, il est conseillé d'éteindre puis rallumer le PC après
l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire l'intégralité du
disque dur avec un outil comme DBAN <http://dban.sourceforge.net/>.

kanze

11/01/2006 à 10:42

Fabien LE LEZ wrote:

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
:

Je me demande comment faut t'il s'y prendre pour effacer un
fichier completement en réécrivant sur le disque là où se
trouvait le fichier supprimé?

La solution "naïve" serait d'écrire des données bidon à
l'intérieur du fichier avant de le supprimer. Seul petit
inconvénient : je ne sais pas du tout si ça marche.

Ça dépend de ce que tu appelles « marcher ». Dans la pratique,
obtenir la taille du fichier, l'ouvrir en mise à jour (non en
écriture seulement), et l'écrire complètement avec des données
bidon suffira pour la plupart des cas. D'une façon 100% portable
(mais pas forcément très rapide -- et sans gestion des erreurs) :

std::filebuf f ;
f.open( filename.c_str(),
std::ios::binary | std::ios::in | std::ios::out ) ;
f.imbue( std::locale::classic() ) ;
std::filebuf::pos_type
end = f.pubseekoff( 0, std::ios::end ) ;
f.pubseekoff( 0, std::ios::beg ) ;
while ( f.pubseekoff( 0, ios::cur ) != end ) {
f.sputc( junk ) ;
}
f.close() ;

On pourrait généralement améliorer la performance en prenant la
différence entre les valeurs de rétour de pubseekoff( 0,
std::ios::beg ) et pubseekoff( 0, std::ios::end ), en le traitant
comme un type entier et en bouclant autant de fois (ou en
sortant des blocs plus grand au moyen de sputs). (À condition
que la taille réele de fichier puisse se représenter dans un
type entier -- en mode 32 bits, avec des fichiers de plus de
4Go, ça ne marche pas, évidemment.)

Je vois mal une implémentation sous Unix ou sous Windows où ça
n'écrirait pas les secteurs qui contenait les données avant.
(Évidemment, sous OpenVMS, ça ne fait que générer une nouvelle
version du fichier, sans toucher à l'ancienne.)

Mais voilà la question : est-ce qu'il suffit de simplement
écrire d'autre chose à l'emplacement physique sur le disque ? Il
existe des moyens de lire ce qu'il y avait avant. Ils ne sont
pas à la porter de l'utilisateur untel, mais des organisations
gouvernementales s'en servent parfois. Alors, il faut écrire des
patterns précises, quelque chose comme une centaine de fois,
avant d'être sûr que les données ne peuvent plus être rélues. En
étant sûr que chaque écriture va jusqu'au disque -- typiquement,
dans un système moderne, l'écriture n'est garantie sur disque
que si tu arrêtes la machine. (Au niveau du SE, il existe en
général des moyens d'assurer la synchronisation. Sous Posix, par
exemple, en précisant l'option O_DSYNC lors qu'on ouvre le
fichier. Mais il n'y a aucune façon à spécifier cette option à
travers le C++ standard.)

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des
différents OS (Windows et Linux en l'occurence), mais des
différents systèmes de fichiers : NTFS et FAT sous Windows, et
les quelques systèmes (courants ou moins courants) sous Linux.

Et même des différents types de disque dur.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe
une implémentation Linux d'un LFS (Log-structured File
System), système qui permet de ne jamais écraser des données
(tant qu'on a de l'espace libre sur le disque) : on se
contente d'écrire les nouvelles données à la suite, ce qui
permet d'obtenir facilement une image du disque tel qu'il
était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.

En somme, comme fait OpenVMS depuis toujours:-). Mais c'est
contraire à la philosophie d'Unix qu'on puisse récupérer après
une erreur. Un utilisateur d'Unix ne fait pas d'erreur:-).

Bon courage pour implémenter ton programme sur un tel système
;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire
de commencer à étudier les algorithmes à mettre en oeuvre,
avant de t'occuper de l'implémentation en quelque langage que
ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon
message ; toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais
sur un disque virtuel (TrueCrypt), avec un mot de passe
temporaire et très long. Au moment d'effacer le fichier, je
"dé-monte" (unmount) le disque virtuel, et je m'empresse
d'oublier le mot de passe. Le disque virtuel (un fichier .tc
sur le disque réel) n'est alors plus qu'un magma
indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre
dans la corbeille.

C'est effectivement la solution la plus sûre. Plutôt que
d'essayer à supprimer l'information après coup, s'assurer
qu'elle n'y est pas d'une façon exploitable par ailleur avant.

En fait, ne suffit-il pas de symplement encrypter les données
lors de l'écriture dans un fichier tout à fait normal ?

La plupart du temps, quand on veut un programme comme celui
démandé, c'est qu'on s'en est rendu compte du problème après le
coup, quand c'est trop tard. Ou qu'on veut pouvoir traiter les
données avec d'autres outils (genre grep) tant qu'elles y sont.
Sinon, les encrypter depuis le début est de loin la meilleur
solution. (Mais ton histoire de disque virtuel encrypté résoudra
le problème d'accès par d'autres programmes, je crois. Est-ce
qu'il existe sur toutes les plateformes ?)

Bien sûr, il est conseillé d'éteindre puis rallumer le PC
après l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire
l'intégralité du disque dur avec un outil comme DBAN
<http://dban.sourceforge.net/>.

Utiliser un disque dur externe, et le détruire physiquement
ensuite. (Genre le faire fondre en une masse de métale.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ wrote:

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
<gregory_baudet@hotmail.com>:

Je me demande comment faut t'il s'y prendre pour effacer un
fichier completement en réécrivant sur le disque là où se
trouvait le fichier supprimé?

La solution "naïve" serait d'écrire des données bidon à
l'intérieur du fichier avant de le supprimer. Seul petit
inconvénient : je ne sais pas du tout si ça marche.

Ça dépend de ce que tu appelles « marcher ». Dans la pratique,
obtenir la taille du fichier, l'ouvrir en mise à jour (non en
écriture seulement), et l'écrire complètement avec des données
bidon suffira pour la plupart des cas. D'une façon 100% portable
(mais pas forcément très rapide -- et sans gestion des erreurs) :

std::filebuf f ;
f.open( filename.c_str(),
std::ios::binary | std::ios::in | std::ios::out ) ;
f.imbue( std::locale::classic() ) ;
std::filebuf::pos_type
end = f.pubseekoff( 0, std::ios::end ) ;
f.pubseekoff( 0, std::ios::beg ) ;
while ( f.pubseekoff( 0, ios::cur ) != end ) {
f.sputc( junk ) ;
}
f.close() ;

On pourrait généralement améliorer la performance en prenant la
différence entre les valeurs de rétour de pubseekoff( 0,
std::ios::beg ) et pubseekoff( 0, std::ios::end ), en le traitant
comme un type entier et en bouclant autant de fois (ou en
sortant des blocs plus grand au moyen de sputs). (À condition
que la taille réele de fichier puisse se représenter dans un
type entier -- en mode 32 bits, avec des fichiers de plus de
4Go, ça ne marche pas, évidemment.)

Je vois mal une implémentation sous Unix ou sous Windows où ça
n'écrirait pas les secteurs qui contenait les données avant.
(Évidemment, sous OpenVMS, ça ne fait que générer une nouvelle
version du fichier, sans toucher à l'ancienne.)

Mais voilà la question : est-ce qu'il suffit de simplement
écrire d'autre chose à l'emplacement physique sur le disque ? Il
existe des moyens de lire ce qu'il y avait avant. Ils ne sont
pas à la porter de l'utilisateur untel, mais des organisations
gouvernementales s'en servent parfois. Alors, il faut écrire des
patterns précises, quelque chose comme une centaine de fois,
avant d'être sûr que les données ne peuvent plus être rélues. En
étant sûr que chaque écriture va jusqu'au disque -- typiquement,
dans un système moderne, l'écriture n'est garantie sur disque
que si tu arrêtes la machine. (Au niveau du SE, il existe en
général des moyens d'assurer la synchronisation. Sous Posix, par
exemple, en précisant l'option O_DSYNC lors qu'on ouvre le
fichier. Mais il n'y a aucune façon à spécifier cette option à
travers le C++ standard.)

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des
différents OS (Windows et Linux en l'occurence), mais des
différents systèmes de fichiers : NTFS et FAT sous Windows, et
les quelques systèmes (courants ou moins courants) sous Linux.

Et même des différents types de disque dur.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe
une implémentation Linux d'un LFS (Log-structured File
System), système qui permet de ne jamais écraser des données
(tant qu'on a de l'espace libre sur le disque) : on se
contente d'écrire les nouvelles données à la suite, ce qui
permet d'obtenir facilement une image du disque tel qu'il
était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.

En somme, comme fait OpenVMS depuis toujours:-). Mais c'est
contraire à la philosophie d'Unix qu'on puisse récupérer après
une erreur. Un utilisateur d'Unix ne fait pas d'erreur:-).

Bon courage pour implémenter ton programme sur un tel système
;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire
de commencer à étudier les algorithmes à mettre en oeuvre,
avant de t'occuper de l'implémentation en quelque langage que
ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon
message ; toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais
sur un disque virtuel (TrueCrypt), avec un mot de passe
temporaire et très long. Au moment d'effacer le fichier, je
"dé-monte" (unmount) le disque virtuel, et je m'empresse
d'oublier le mot de passe. Le disque virtuel (un fichier .tc
sur le disque réel) n'est alors plus qu'un magma
indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre
dans la corbeille.

C'est effectivement la solution la plus sûre. Plutôt que
d'essayer à supprimer l'information après coup, s'assurer
qu'elle n'y est pas d'une façon exploitable par ailleur avant.

En fait, ne suffit-il pas de symplement encrypter les données
lors de l'écriture dans un fichier tout à fait normal ?

La plupart du temps, quand on veut un programme comme celui
démandé, c'est qu'on s'en est rendu compte du problème après le
coup, quand c'est trop tard. Ou qu'on veut pouvoir traiter les
données avec d'autres outils (genre grep) tant qu'elles y sont.
Sinon, les encrypter depuis le début est de loin la meilleur
solution. (Mais ton histoire de disque virtuel encrypté résoudra
le problème d'accès par d'autres programmes, je crois. Est-ce
qu'il existe sur toutes les plateformes ?)

Bien sûr, il est conseillé d'éteindre puis rallumer le PC
après l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire
l'intégralité du disque dur avec un outil comme DBAN
<http://dban.sourceforge.net/>.

Utiliser un disque dur externe, et le détruire physiquement
ensuite. (Genre le faire fondre en une masse de métale.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Fabien LE LEZ wrote:

On Tue, 10 Jan 2006 18:04:32 +0100, Gregory Baudet
:

Je me demande comment faut t'il s'y prendre pour effacer un
fichier completement en réécrivant sur le disque là où se
trouvait le fichier supprimé?

La solution "naïve" serait d'écrire des données bidon à
l'intérieur du fichier avant de le supprimer. Seul petit
inconvénient : je ne sais pas du tout si ça marche.

Ça dépend de ce que tu appelles « marcher ». Dans la pratique,
obtenir la taille du fichier, l'ouvrir en mise à jour (non en
écriture seulement), et l'écrire complètement avec des données
bidon suffira pour la plupart des cas. D'une façon 100% portable
(mais pas forcément très rapide -- et sans gestion des erreurs) :

std::filebuf f ;
f.open( filename.c_str(),
std::ios::binary | std::ios::in | std::ios::out ) ;
f.imbue( std::locale::classic() ) ;
std::filebuf::pos_type
end = f.pubseekoff( 0, std::ios::end ) ;
f.pubseekoff( 0, std::ios::beg ) ;
while ( f.pubseekoff( 0, ios::cur ) != end ) {
f.sputc( junk ) ;
}
f.close() ;

On pourrait généralement améliorer la performance en prenant la
différence entre les valeurs de rétour de pubseekoff( 0,
std::ios::beg ) et pubseekoff( 0, std::ios::end ), en le traitant
comme un type entier et en bouclant autant de fois (ou en
sortant des blocs plus grand au moyen de sputs). (À condition
que la taille réele de fichier puisse se représenter dans un
type entier -- en mode 32 bits, avec des fichiers de plus de
4Go, ça ne marche pas, évidemment.)

Je vois mal une implémentation sous Unix ou sous Windows où ça
n'écrirait pas les secteurs qui contenait les données avant.
(Évidemment, sous OpenVMS, ça ne fait que générer une nouvelle
version du fichier, sans toucher à l'ancienne.)

Mais voilà la question : est-ce qu'il suffit de simplement
écrire d'autre chose à l'emplacement physique sur le disque ? Il
existe des moyens de lire ce qu'il y avait avant. Ils ne sont
pas à la porter de l'utilisateur untel, mais des organisations
gouvernementales s'en servent parfois. Alors, il faut écrire des
patterns précises, quelque chose comme une centaine de fois,
avant d'être sûr que les données ne peuvent plus être rélues. En
étant sûr que chaque écriture va jusqu'au disque -- typiquement,
dans un système moderne, l'écriture n'est garantie sur disque
que si tu arrêtes la machine. (Au niveau du SE, il existe en
général des moyens d'assurer la synchronisation. Sous Posix, par
exemple, en précisant l'option O_DSYNC lors qu'on ouvre le
fichier. Mais il n'y a aucune façon à spécifier cette option à
travers le C++ standard.)

Si tu veux une solution qui fonctionne vraiment, j'ai bien
l'impression que tu vas devoir t'occuper non pas des
différents OS (Windows et Linux en l'occurence), mais des
différents systèmes de fichiers : NTFS et FAT sous Windows, et
les quelques systèmes (courants ou moins courants) sous Linux.

Et même des différents types de disque dur.

J'ai d'ailleurs lu, au hasard de mes recherches, qu'il existe
une implémentation Linux d'un LFS (Log-structured File
System), système qui permet de ne jamais écraser des données
(tant qu'on a de l'espace libre sur le disque) : on se
contente d'écrire les nouvelles données à la suite, ce qui
permet d'obtenir facilement une image du disque tel qu'il
était à une date antérieure, et donc d'obtenir toutes les
versions successives d'un fichier donné.

En somme, comme fait OpenVMS depuis toujours:-). Mais c'est
contraire à la philosophie d'Unix qu'on puisse récupérer après
une erreur. Un utilisateur d'Unix ne fait pas d'erreur:-).

Bon courage pour implémenter ton programme sur un tel système
;-)

Tu devrais aller faire un tour sur fr.comp.securite, histoire
de commencer à étudier les algorithmes à mettre en oeuvre,
avant de t'occuper de l'implémentation en quelque langage que
ce soit.

Ce qui suit est encore plus hors-sujet que le début de mon
message ; toutes mes excuses...

Si je devais mettre sur un disque dur un fichier réellement
confidentiel, qui devra être supprimé ensuite, je le mettrais
sur un disque virtuel (TrueCrypt), avec un mot de passe
temporaire et très long. Au moment d'effacer le fichier, je
"dé-monte" (unmount) le disque virtuel, et je m'empresse
d'oublier le mot de passe. Le disque virtuel (un fichier .tc
sur le disque réel) n'est alors plus qu'un magma
indéchiffrable d'octets, qu'il ne me reste plus qu'à mettre
dans la corbeille.

C'est effectivement la solution la plus sûre. Plutôt que
d'essayer à supprimer l'information après coup, s'assurer
qu'elle n'y est pas d'une façon exploitable par ailleur avant.

En fait, ne suffit-il pas de symplement encrypter les données
lors de l'écriture dans un fichier tout à fait normal ?

La plupart du temps, quand on veut un programme comme celui
démandé, c'est qu'on s'en est rendu compte du problème après le
coup, quand c'est trop tard. Ou qu'on veut pouvoir traiter les
données avec d'autres outils (genre grep) tant qu'elles y sont.
Sinon, les encrypter depuis le début est de loin la meilleur
solution. (Mais ton histoire de disque virtuel encrypté résoudra
le problème d'accès par d'autres programmes, je crois. Est-ce
qu'il existe sur toutes les plateformes ?)

Bien sûr, il est conseillé d'éteindre puis rallumer le PC
après l'opération, pour vider la RAM.

Une autre solution, a posteriori celle-là : détruire
l'intégralité du disque dur avec un outil comme DBAN
<http://dban.sourceforge.net/>.

Utiliser un disque dur externe, et le détruire physiquement
ensuite. (Genre le faire fondre en une masse de métale.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ

11/01/2006 à 11:14

On 11 Jan 2006 01:42:33 -0800, "kanze" :

En fait, ne suffit-il pas de symplement encrypter les données
lors de l'écriture dans un fichier tout à fait normal ?

Ça revient à ça, effectivement.
J'imagine qu'en plus, Truecrypt offre d'autres garanties, du style,
s'assure qu'on ne pourra pas retrouver les données en clair dans le
swap.

(Mais ton histoire de disque virtuel encrypté résoudra
le problème d'accès par d'autres programmes, je crois. Est-ce
qu'il existe sur toutes les plateformes ?)

Il me semble qu'il est raisonnablement portable.
<http://www.truecrypt.org/>

Utiliser un disque dur externe, et le détruire physiquement
ensuite. (Genre le faire fondre en une masse de métale.)

Attention au swap !

Gregory Baudet

11/01/2006 à 11:32

Fabien LE LEZ wrote:

On 11 Jan 2006 01:42:33 -0800, "kanze" :

En fait, ne suffit-il pas de symplement encrypter les données
lors de l'écriture dans un fichier tout à fait normal ?

Ça revient à ça, effectivement.
J'imagine qu'en plus, Truecrypt offre d'autres garanties, du style,
s'assure qu'on ne pourra pas retrouver les données en clair dans le
swap.

S'il s'agit de crypter des données pour que seul 3 utilisateurs réunis
puissent les décoder, la technique du masque jettable (xor avec 3 clés
"aléatoire" aussi longue que le fichier) serait-elle acceptable?
Je pense que ca devrait être une bonne sécurité pour protégé un fichier?
Qu'en pensez vous?

(Mais ton histoire de disque virtuel encrypté résoudra
le problème d'accès par d'autres programmes, je crois. Est-ce
qu'il existe sur toutes les plateformes ?)

Il me semble qu'il est raisonnablement portable.
<http://www.truecrypt.org/>

Utiliser un disque dur externe, et le détruire physiquement
ensuite. (Genre le faire fondre en une masse de métale.)

Attention au swap !

Et quand on charge quelque chose en mémoire en C (sous windows ou
linux), comment peut on être certain que c'est pas chargé dans le swap?

Jean-Marc Bourguet

11/01/2006 à 11:42

Gregory Baudet writes:

S'il s'agit de crypter des données pour que seul 3 utilisateurs réunis
puissent les décoder, la technique du masque jettable (xor avec 3 clés
"aléatoire" aussi longue que le fichier) serait-elle acceptable?
Je pense que ca devrait être une bonne sécurité pour protégé un fichier?
Qu'en pensez vous?

Copie et suivi sur fr.misc.cryptologie.

A ma connaissance, cette technique est la seule dont on est sur que la
securite est limitee uniquement par la securite sur les cles. Il est
important que les cles soient bien aleatoires et utilisee pour un
document unique.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Fabien LE LEZ

11/01/2006 à 11:45

On Wed, 11 Jan 2006 11:32:41 +0100, Gregory Baudet
:

Et quand on charge quelque chose en mémoire en C (sous windows ou
linux), comment peut on être certain que c'est pas chargé dans le swap?

On ne peut pas en C++ standard. Il faut là encore jouer avec des API
spécifiques à l'OS.

Suppression sécurisée de fichier

10 réponses

Veuillez sélectionner un problème