Sur le disque dur de ma machine perso, qui est sous
Debian Wheezy, j'utilise la commande « mcrypt » (issue
du paquet éponyme) pour chiffrer/déchiffrer un fichier
texte un peu sensible (c'est un fichier qui contient
des identifiants/mots des passe car je n'ai pas une bonne
mémoire ;)). La commande « mcrypt » permet donc de
chiffrer/déchiffrer un fichier via un mot de passe :
* avec « mcrypt secret.txt », je dois saisir deux fois à
l'identique un mot de passe et cela me génère une version
chiffrée de mon fichier qui s'appelle « secret.txt.nc ».
* avec « mcrypt -d secret.txt.nc », je dois saisir le mot
de passe précédent et alors la version en clair du fichier
est générée (ie le fichier « secret.txt »).
Je me suis fait un petit script shell qui me permet de
modifier ou consulter ce fichier (entre autres choses
le script supprime par exemple le fichier en clair une
fois que je l'ai consulté pour éviter que j'oublie un
jour etc).
Bref, d'un point de vue « ergonomie » ma solution bricolée
me convient très bien, pas de souci. Mais ma question porte
ici sur la « fiabilité » du chiffrement de la commande. En
effet, j'ai bien tenté de consulter la page man de « mcrypt »,
ça parle d'algorithmes etc. mais je dois avouer qu'en crypto
je n'y connais rien du tout.
La chiffrement de « mcrypt » sur Debian Wheezy (version 2.6.8)
est-il fiable ? Est-ce que, si un jour (en 2015/2016) quelqu'un
tombe sur la version chiffrée du fichier, fichier chiffré avec
un mot de passe d'une douzaine de caractères du genre celui-là
« El3;p@Nt3+14 » (rien à voir avec mon mot de passe mais c'est
pour donner une idée), est-ce que je peux avoir la garantie que
ce quelqu'un ne pourra pas déchiffrer le fichier en un temps
raisonnable ?
Parce que si on me dit qu'avec « mcrypt », le petit hacker du
dimanche peut me cracker mon fichier en 30 minutes, ça
m'embêterait un peu. ;)
Sur le disque dur de ma machine perso, qui est sous Debian Wheezy, j'utilise la commande « mcrypt » (issue du paquet éponyme) pour chiffrer/déchiffrer un fichier texte un peu sensible (c'est un fichier qui contient des identifiants/mots des passe car je n'ai pas une bonne mémoire ;)). La commande « mcrypt » permet donc de chiffrer/déchiffrer un fichier via un mot de passe :
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
JBF
-- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Bonjour,
Le 28/08/2015 23:58, Francois Lafont a écrit :
Bonjour à tous,
Sur le disque dur de ma machine perso, qui est sous
Debian Wheezy, j'utilise la commande « mcrypt » (issue
du paquet éponyme) pour chiffrer/déchiffrer un fichier
texte un peu sensible (c'est un fichier qui contient
des identifiants/mots des passe car je n'ai pas une bonne
mémoire ;)). La commande « mcrypt » permet donc de
chiffrer/déchiffrer un fichier via un mot de passe :
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe
avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente
sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un
document mais si ce doc est protégé par mdp, le fichier temporaire l'est
aussi.
JBF
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Sur le disque dur de ma machine perso, qui est sous Debian Wheezy, j'utilise la commande « mcrypt » (issue du paquet éponyme) pour chiffrer/déchiffrer un fichier texte un peu sensible (c'est un fichier qui contient des identifiants/mots des passe car je n'ai pas une bonne mémoire ;)). La commande « mcrypt » permet donc de chiffrer/déchiffrer un fichier via un mot de passe :
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
JBF
-- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Dominique MICOLLET
Bonjour, Francois Lafont wrote:
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ?
$dd if=/dev/zero of=/dev/le_disque_ssd
après sauvegarde des autres données.
Contrairement à un disque dur, une cellule mémoire ssd ne conserve pas la trace fantôme de ses contenus antérieurs dans ses marges.
Cordialement
Dominique
Bonjour,
Francois Lafont wrote:
Mais il n'y a aucun moyen d'effacer véritablement et
de manière certaine une donnée d'un disque SSD ?
$dd if=/dev/zero of=/dev/le_disque_ssd
après sauvegarde des autres données.
Contrairement à un disque dur, une cellule mémoire ssd ne conserve pas la
trace fantôme de ses contenus antérieurs dans ses marges.
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ?
$dd if=/dev/zero of=/dev/le_disque_ssd
après sauvegarde des autres données.
Contrairement à un disque dur, une cellule mémoire ssd ne conserve pas la trace fantôme de ses contenus antérieurs dans ses marges.
Cordialement
Dominique
Damien Wyart
* Francois Lafont in fr.comp.os.linux.configuration:
En fait, dans la page man de mcrypt, je peux voir ceci :
-a --algorithm ALGORITHM The algorithm used to encrypt and decrypt. Unless the bare flag is specified there is no need to specify these for decryption.
The algorithms currently supported are shown with the --list parameter.
Au passage, je n'arrive pas à trouver dans la page man l'algorithme qui est utilisé par défaut.
Dans le code de mcrypt, on trouve ceci :
#define DEFAULT_ALGORITHM "rijndael-128" /* The AES winner */
-- DW
* Francois Lafont <francois.lafont@nospam.invalid> in
fr.comp.os.linux.configuration:
En fait, dans la page man de mcrypt, je peux voir ceci :
-a --algorithm ALGORITHM
The algorithm used to encrypt and decrypt. Unless the
bare flag is specified there is no need to specify these
for decryption.
The algorithms currently supported are shown with the --list parameter.
Au passage, je n'arrive pas à trouver dans la page man l'algorithme
qui est utilisé par défaut.
Dans le code de mcrypt, on trouve ceci :
#define DEFAULT_ALGORITHM "rijndael-128" /* The AES winner */
* Francois Lafont in fr.comp.os.linux.configuration:
En fait, dans la page man de mcrypt, je peux voir ceci :
-a --algorithm ALGORITHM The algorithm used to encrypt and decrypt. Unless the bare flag is specified there is no need to specify these for decryption.
The algorithms currently supported are shown with the --list parameter.
Au passage, je n'arrive pas à trouver dans la page man l'algorithme qui est utilisé par défaut.
Dans le code de mcrypt, on trouve ceci :
#define DEFAULT_ALGORITHM "rijndael-128" /* The AES winner */
-- DW
gump
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe
avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente
sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un
document mais si ce doc est protégé par mdp, le fichier temporaire l'est
aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Jean-Baptiste Faure
Le 31/08/2015 13:50, gump a écrit :
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Le fichier temporaire se dézippe sans problème mais le content.xml est bien chiffré tout comme les autres fichiers xml qui composent le .odt.Il suffit de l'ouvrir avec un éditeur de texte pour le vérifier.
Je n'ai trouvé qu'un manifest.xml dans le sous-dossier /META-INF qui n'est pas chiffré mais ce fichier ne semble pas contenir d'info révélant le contenu du document.
Enfin le fichier temporaire est, en principe, supprimé quand le document est fermé dans LO. Mais ça on a vu que ça ne garantit pas sa disparition.
JBF
-- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Le 31/08/2015 13:50, gump a écrit :
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe
avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente
sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un
document mais si ce doc est protégé par mdp, le fichier temporaire l'est
aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Le fichier temporaire se dézippe sans problème mais le content.xml est
bien chiffré tout comme les autres fichiers xml qui composent le .odt.Il
suffit de l'ouvrir avec un éditeur de texte pour le vérifier.
Je n'ai trouvé qu'un manifest.xml dans le sous-dossier /META-INF qui
n'est pas chiffré mais ce fichier ne semble pas contenir d'info révélant
le contenu du document.
Enfin le fichier temporaire est, en principe, supprimé quand le document
est fermé dans LO. Mais ça on a vu que ça ne garantit pas sa disparition.
JBF
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Est-ce qu'utiliser un document OpenDocument protégé par mot de passe avec LibreOffice ne permettrait pas d'obtenir une sécurité équivalente sans avoir à créer un fichier texte en clair sur le DD ?
LO crée un fichier temporaire dans /tmp lors de l'ouverture d'un document mais si ce doc est protégé par mdp, le fichier temporaire l'est aussi.
Non ! le fichier temporaire déchiffré sera ... en clair !
Le fichier temporaire se dézippe sans problème mais le content.xml est bien chiffré tout comme les autres fichiers xml qui composent le .odt.Il suffit de l'ouvrir avec un éditeur de texte pour le vérifier.
Je n'ai trouvé qu'un manifest.xml dans le sous-dossier /META-INF qui n'est pas chiffré mais ce fichier ne semble pas contenir d'info révélant le contenu du document.
Enfin le fichier temporaire est, en principe, supprimé quand le document est fermé dans LO. Mais ça on a vu que ça ne garantit pas sa disparition.
JBF
-- Seuls des formats ouverts peuvent assurer la pérennité de vos documents
Ascadix
Francois Lafont avait prétendu :
On 31/08/2015 01:00, Ascadix wrote:
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase" n'est pas forcément fiable à tous les coups.
Y a une subtilité, j'ai pas été assez précis.
Je faisais allusion à la commande "ATA Secure Erase" , dans l'article, du coté du 5.4 il est surtout fait référence à un "secure erase" à la sauce façon DBAN avec multiple passes de ré-écriture sur le média (algo au choix, gutman, DoD, random, etc...)
Le "ATA Secure Erase" est mentionné au 5.19, avec juste une réserve quand à faire confiance au fabricant du SSD (ou HDD d'ailleur) si la commande est bien implementé (bug ou volontairement)
puis restore des données
:-) Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Francois Lafont avait prétendu :
On 31/08/2015 01:00, Ascadix wrote:
Backup des données, pas un dd raw hein, une copie des fichiers + le
nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de
clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase"
n'est pas forcément fiable à tous les coups.
Y a une subtilité, j'ai pas été assez précis.
Je faisais allusion à la commande "ATA Secure Erase" , dans l'article,
du coté du 5.4 il est surtout fait référence à un "secure erase" à la
sauce façon DBAN avec multiple passes de ré-écriture sur le média (algo
au choix, gutman, DoD, random, etc...)
Le "ATA Secure Erase" est mentionné au 5.19, avec juste une réserve
quand à faire confiance au fabricant du SSD (ou HDD d'ailleur) si la
commande est bien implementé (bug ou volontairement)
puis restore des données
:-)
Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour
que le fichier en clair soit écrit sur un tmpfs et puis
voilà. :p
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase" n'est pas forcément fiable à tous les coups.
Y a une subtilité, j'ai pas été assez précis.
Je faisais allusion à la commande "ATA Secure Erase" , dans l'article, du coté du 5.4 il est surtout fait référence à un "secure erase" à la sauce façon DBAN avec multiple passes de ré-écriture sur le média (algo au choix, gutman, DoD, random, etc...)
Le "ATA Secure Erase" est mentionné au 5.19, avec juste une réserve quand à faire confiance au fabricant du SSD (ou HDD d'ailleur) si la commande est bien implementé (bug ou volontairement)
puis restore des données
:-) Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
