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;+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 ?
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 ?
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;+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 ?
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 :
* 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;+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. ;)
Merci d'avance pour votre aide.
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 :
* 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. ;)
Merci d'avance pour votre aide.
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 :
* 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;+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. ;)
Merci d'avance pour votre aide.
Le mot de passe lui-même est très solide, il a une entropie d'environ 78 bits. Pour une attaque par force brute ( la seule, ici, puisque c'est une suite totalement aléatoire ), avec un super calculateur, prévoir plusieurs milliards d'années : ça te suffit ? ;-)
Par contre, je ne sais pas quel algorithme est utilisé par mcrypt. Si c'est AES, tu peux être tranquille. Si c'est un algorithme plus ancien, il vaut sans doute mieux voir une autre solution.
NB : je viens de voir ceci :
https://en.wikipedia.org/wiki/Mcrypt
Je lis qu'on pourrait choisir l'algo à la commande :
mcrypt -a blowfish myfilename # Encrypts myfilename to myfilename.nc using the Blowfish encryption algorithm.
Regarde si tu peux mettre aes dans la commande ... Essaie d'abord, bien sûr, avec un fichier sans intérêt au cas où ça foirerait. Donc ça donnerait ;
mcrypt -a aes secret.txt
Le mot de passe lui-même est très solide, il a une entropie d'environ 78 bits. Pour une attaque par force brute ( la seule, ici, puisque c'est une suite totalement aléatoire ), avec un super calculateur, prévoir plusieurs milliards d'années : ça te suffit ? ;-)
Par contre, je ne sais pas quel algorithme est utilisé par mcrypt. Si c'est AES, tu peux être tranquille. Si c'est un algorithme plus ancien, il vaut sans doute mieux voir une autre solution.
NB : je viens de voir ceci :
https://en.wikipedia.org/wiki/Mcrypt
Je lis qu'on pourrait choisir l'algo à la commande :
mcrypt -a blowfish myfilename # Encrypts myfilename to myfilename.nc using the Blowfish encryption algorithm.
Regarde si tu peux mettre aes dans la commande ... Essaie d'abord, bien sûr, avec un fichier sans intérêt au cas où ça foirerait. Donc ça donnerait ;
mcrypt -a aes secret.txt
Le mot de passe lui-même est très solide, il a une entropie d'environ 78 bits. Pour une attaque par force brute ( la seule, ici, puisque c'est une suite totalement aléatoire ), avec un super calculateur, prévoir plusieurs milliards d'années : ça te suffit ? ;-)
Par contre, je ne sais pas quel algorithme est utilisé par mcrypt. Si c'est AES, tu peux être tranquille. Si c'est un algorithme plus ancien, il vaut sans doute mieux voir une autre solution.
NB : je viens de voir ceci :
https://en.wikipedia.org/wiki/Mcrypt
Je lis qu'on pourrait choisir l'algo à la commande :
mcrypt -a blowfish myfilename # Encrypts myfilename to myfilename.nc using the Blowfish encryption algorithm.
Regarde si tu peux mettre aes dans la commande ... Essaie d'abord, bien sûr, avec un fichier sans intérêt au cas où ça foirerait. Donc ça donnerait ;
mcrypt -a aes secret.txt
Attention : tu as écrit un script pour effacer le fichier en clair, mais tu oublies qu'il reste récupérable ! Il n'est pas véritablement effacé, il est seulement rayé de la table des fichiers.
Il faut le "déchiqueter" en utilisant shred ( tu peux peut-être l'inclure dans ton script )
Et si tu l'as déjà simplement supprimé,
il faudrait traiter de la même façon l'espace libre de ta partition : voir secure-delete, ça marche sous Ubuntu ça devrait sous une Debian, pour effacer toutes les traces conservées dans l'espace libre. Voir chez Korben :
http://korben.info/comment-faire-un-bon-menage-de-printemps-sur-son-disque-dur-sous-linux.html
Attention : tu as écrit un script pour effacer le fichier en clair, mais tu oublies qu'il reste récupérable ! Il n'est pas véritablement effacé, il est seulement rayé de la table des fichiers.
Il faut le "déchiqueter" en utilisant shred ( tu peux peut-être l'inclure dans ton script )
Et si tu l'as déjà simplement supprimé,
il faudrait traiter de la même façon l'espace libre de ta partition : voir secure-delete, ça marche sous Ubuntu ça devrait sous une Debian, pour effacer toutes les traces conservées dans l'espace libre. Voir chez Korben :
http://korben.info/comment-faire-un-bon-menage-de-printemps-sur-son-disque-dur-sous-linux.html
Attention : tu as écrit un script pour effacer le fichier en clair, mais tu oublies qu'il reste récupérable ! Il n'est pas véritablement effacé, il est seulement rayé de la table des fichiers.
Il faut le "déchiqueter" en utilisant shred ( tu peux peut-être l'inclure dans ton script )
Et si tu l'as déjà simplement supprimé,
il faudrait traiter de la même façon l'espace libre de ta partition : voir secure-delete, ça marche sous Ubuntu ça devrait sous une Debian, pour effacer toutes les traces conservées dans l'espace libre. Voir chez Korben :
http://korben.info/comment-faire-un-bon-menage-de-printemps-sur-son-disque-dur-sous-linux.html
Coté algo, sous réserve que ça soit correctement implémenté, ça semble d'une résistance "dans l'air du temps".
Le pb potentiel que je vois, c'est plutot ta façon de l'utiliser.
Si tu "mcrypt" un fichier pour le communiquer à qq'un par un média qqconque et que tu veux protéger pendant le transfert, c'est ok.
Mais en usage sur un stockage local comme tu fais,
avec ton cycle régulier chiffrage / déchifrage , tu écris fréquement le contenu en clair sur ton disque donc si qq'un te fauche ton disque, il peux potentiellement fouiner dans l'espaces libéré et trouver des morceaux de ton texte en clair.
Pour ce genre d'usage, à échelle du particulier, on utilise plutot des softs dans le genre de KeePass:
http://doc.ubuntu-fr.org/keepassx
http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/
https://packages.debian.org/sid/keepass2
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap, ou que qq'un attaque ta RAM à la bombe à froid pour en dumper le contenu ... :-)
Coté algo, sous réserve que ça soit correctement implémenté, ça semble d'une résistance "dans l'air du temps".
Le pb potentiel que je vois, c'est plutot ta façon de l'utiliser.
Si tu "mcrypt" un fichier pour le communiquer à qq'un par un média qqconque et que tu veux protéger pendant le transfert, c'est ok.
Mais en usage sur un stockage local comme tu fais,
avec ton cycle régulier chiffrage / déchifrage , tu écris fréquement le contenu en clair sur ton disque donc si qq'un te fauche ton disque, il peux potentiellement fouiner dans l'espaces libéré et trouver des morceaux de ton texte en clair.
Pour ce genre d'usage, à échelle du particulier, on utilise plutot des softs dans le genre de KeePass:
http://doc.ubuntu-fr.org/keepassx
http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/
https://packages.debian.org/sid/keepass2
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap, ou que qq'un attaque ta RAM à la bombe à froid pour en dumper le contenu ... :-)
Coté algo, sous réserve que ça soit correctement implémenté, ça semble d'une résistance "dans l'air du temps".
Le pb potentiel que je vois, c'est plutot ta façon de l'utiliser.
Si tu "mcrypt" un fichier pour le communiquer à qq'un par un média qqconque et que tu veux protéger pendant le transfert, c'est ok.
Mais en usage sur un stockage local comme tu fais,
avec ton cycle régulier chiffrage / déchifrage , tu écris fréquement le contenu en clair sur ton disque donc si qq'un te fauche ton disque, il peux potentiellement fouiner dans l'espaces libéré et trouver des morceaux de ton texte en clair.
Pour ce genre d'usage, à échelle du particulier, on utilise plutot des softs dans le genre de KeePass:
http://doc.ubuntu-fr.org/keepassx
http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/
https://packages.debian.org/sid/keepass2
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap, ou que qq'un attaque ta RAM à la bombe à froid pour en dumper le contenu ... :-)
En tout cas, j'ai ceci sur ma console :
~$ mcrypt --list
cast-128 (16): cbc cfb ctr ecb ncfb nofb ofb
gost (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-128 (32): cbc cfb ctr ecb ncfb nofb ofb
twofish (32): cbc cfb ctr ecb ncfb nofb ofb
arcfour (256): stream
cast-256 (32): cbc cfb ctr ecb ncfb nofb ofb
loki97 (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-192 (32): cbc cfb ctr ecb ncfb nofb ofb
saferplus (32): cbc cfb ctr ecb ncfb nofb ofb
wake (32): stream
blowfish-compat (56): cbc cfb ctr ecb ncfb nofb ofb
des (8): cbc cfb ctr ecb ncfb nofb ofb
rijndael-256 (32): cbc cfb ctr ecb ncfb nofb ofb
serpent (32): cbc cfb ctr ecb ncfb nofb ofb
xtea (16): cbc cfb ctr ecb ncfb nofb ofb
blowfish (56): cbc cfb ctr ecb ncfb nofb ofb
enigma (13): stream
rc2 (128): cbc cfb ctr ecb ncfb nofb ofb
tripledes (24): cbc cfb ctr ecb ncfb nofb ofb
Pas de "aes" dans la liste. C'est problématique ?
Il n'y a pas un algo « solide » dans cette liste ?
(Les "cbc", les "cfb", je ne vois pas trop ce que
c'est non plus.)
En tout cas, j'ai ceci sur ma console :
~$ mcrypt --list
cast-128 (16): cbc cfb ctr ecb ncfb nofb ofb
gost (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-128 (32): cbc cfb ctr ecb ncfb nofb ofb
twofish (32): cbc cfb ctr ecb ncfb nofb ofb
arcfour (256): stream
cast-256 (32): cbc cfb ctr ecb ncfb nofb ofb
loki97 (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-192 (32): cbc cfb ctr ecb ncfb nofb ofb
saferplus (32): cbc cfb ctr ecb ncfb nofb ofb
wake (32): stream
blowfish-compat (56): cbc cfb ctr ecb ncfb nofb ofb
des (8): cbc cfb ctr ecb ncfb nofb ofb
rijndael-256 (32): cbc cfb ctr ecb ncfb nofb ofb
serpent (32): cbc cfb ctr ecb ncfb nofb ofb
xtea (16): cbc cfb ctr ecb ncfb nofb ofb
blowfish (56): cbc cfb ctr ecb ncfb nofb ofb
enigma (13): stream
rc2 (128): cbc cfb ctr ecb ncfb nofb ofb
tripledes (24): cbc cfb ctr ecb ncfb nofb ofb
Pas de "aes" dans la liste. C'est problématique ?
Il n'y a pas un algo « solide » dans cette liste ?
(Les "cbc", les "cfb", je ne vois pas trop ce que
c'est non plus.)
En tout cas, j'ai ceci sur ma console :
~$ mcrypt --list
cast-128 (16): cbc cfb ctr ecb ncfb nofb ofb
gost (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-128 (32): cbc cfb ctr ecb ncfb nofb ofb
twofish (32): cbc cfb ctr ecb ncfb nofb ofb
arcfour (256): stream
cast-256 (32): cbc cfb ctr ecb ncfb nofb ofb
loki97 (32): cbc cfb ctr ecb ncfb nofb ofb
rijndael-192 (32): cbc cfb ctr ecb ncfb nofb ofb
saferplus (32): cbc cfb ctr ecb ncfb nofb ofb
wake (32): stream
blowfish-compat (56): cbc cfb ctr ecb ncfb nofb ofb
des (8): cbc cfb ctr ecb ncfb nofb ofb
rijndael-256 (32): cbc cfb ctr ecb ncfb nofb ofb
serpent (32): cbc cfb ctr ecb ncfb nofb ofb
xtea (16): cbc cfb ctr ecb ncfb nofb ofb
blowfish (56): cbc cfb ctr ecb ncfb nofb ofb
enigma (13): stream
rc2 (128): cbc cfb ctr ecb ncfb nofb ofb
tripledes (24): cbc cfb ctr ecb ncfb nofb ofb
Pas de "aes" dans la liste. C'est problématique ?
Il n'y a pas un algo « solide » dans cette liste ?
(Les "cbc", les "cfb", je ne vois pas trop ce que
c'est non plus.)
Suis-je bête ! Rijndael, c'est AES ! ( le mot Rijndael désigne les deux inventeurs de cet algorithme, Joan Daemen et Vincent Rijmen ).
Tu peux prendre rijndael-128, ce sera amplement suffisant et plus rapide que rijndael-256.
Suis-je bête ! Rijndael, c'est AES ! ( le mot Rijndael désigne les deux inventeurs de cet algorithme, Joan Daemen et Vincent Rijmen ).
Tu peux prendre rijndael-128, ce sera amplement suffisant et plus rapide que rijndael-256.
Suis-je bête ! Rijndael, c'est AES ! ( le mot Rijndael désigne les deux inventeurs de cet algorithme, Joan Daemen et Vincent Rijmen ).
Tu peux prendre rijndael-128, ce sera amplement suffisant et plus rapide que rijndael-256.
(enfin si on met de côté les
traces du fichier faites auparavant en utilisant rm avant
d'utiliser shred).
(enfin si on met de côté les
traces du fichier faites auparavant en utilisant rm avant
d'utiliser shred).
(enfin si on met de côté les
traces du fichier faites auparavant en utilisant rm avant
d'utiliser shred).
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap,
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap,
Reste là le pb potentiel de retrouver une partie du cotenu dans le swap,