La commande mcrypt est-elle « fiable » ?

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 ?

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

Francois Lafont a exprimé avec précision :

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.

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 ... :-)

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

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

On 29/08/2015 00:34, gump wrote:

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 ? ;-)

Oh oui, un tel délai serait largement suffisant. ;)

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

Ok, merci pour ces précisions.
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.

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.)

--
François Lafont

On 29/08/2015 00:52, gump wrote:

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.

Oui, c'est vrai tu as raison.

Il faut le "déchiqueter" en utilisant shred ( tu peux peut-être l'inclure dans ton script )

Ah oui, merci bien, je ne connaissais pas. Une fois de plus
sur ce groupe de discussion, j'ai appris quelque chose. Après
une consultation rapide de la page man de shred, il me semble
que je peux remplacer mon « rm -f secret.txt » par ça :

shred --remove --verbose --zero secret.txt

Est-ce que c'est suffisant pour empêcher définitivement la
récupération du fichier en clair secret.txt ?

Et si tu l'as déjà simplement supprimé,

Oui, pour le coup ça m'est arrivé un paquet de fois maintenant. ;)

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

Je te remercie pour l'info (je ne connaissais pas non plus secure-delete)
mais là pour le coup, c'est un peu feignant de ma part mais je me dis qu'avec
le temps, les traces du fichier en clair que j'ai semées finiront par
disparaître. Bon, j'ai sûrement tort, là j'avoue c'est de la pure paresse.
On va dire que jusqu'ici j'étais pas dans les clous avec le rm mais
qu'avec shred désormais ça ira mieux. ;) (même si on est d'accord j'ai
sûrement des traces du fichier en clair qui traîneront encore quelques
temps.)

Merci beaucoup gump pour tous ces tuyaux très utiles.

En fin de discussion, je posterai mon script shell, histoire de partager
et d'avoir d'éventuelles critiques.

--
François Lafont

On 29/08/2015 00:37, Ascadix wrote:

Coté algo, sous réserve que ça soit correctement implémenté, ça semble d'une résistance "dans l'air du temps".

Ok.

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,

Oui, c'est dans cet usage que je suis.

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.

Oui, c'est la remarque que faisait également gump plus haut,
à juste titre. Il me semble que sa proposition d'utiliser
shred règle le souci, non ? (enfin si on met de côté les
traces du fichier faites auparavant en utilisant rm avant
d'utiliser shred).

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

Ça semble sans doute un programme très bien mais il s'utilise
via une interface graphique, non ? J'avoue que je suis assez
attaché à l'idée de pouvoir tout faire en console et aussi en
utilisant mon petit vim que j'aime beaucoup. ;)

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 ... :-)

Oulà, mais ça c'est seulement que je serai recherché par le FBI
et la NSA. ;) Et en plus, si mon ordi est éteint, sauf erreur, il
me semble qu'on ne pourra rien trouver dans la swap et dans la
RAM de mon ordi (quoi que dans la swap j'ai un doute mais a priori
ma machine ne swappe pas).

Merci pour ta réponse.

--
François Lafont

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.

On 29/08/2015 02:34, gump wrote:

Suis-je bête ! Rijndael, c'est AES ! ( le mot Rijndael désigne les deux inventeurs de cet algorithme, Joan Daemen et Vincent Rijmen ).

Ah ok, je ne savais pas.

Tu peux prendre rijndael-128, ce sera amplement suffisant et plus rapide que rijndael-256.

Ben, j'ai testé le rijndael-256 et dans mon cas c'est pour
ainsi dire instantané alors j'ai pris celui-là tant qu'à faire.

Ci-dessous, voici du coup mon script pour consulter/éditer
mon fichier secret.txt. Le script suppose que le fichier
chiffré secret.txt.nc a été créé manuellement une première
fois et ensuite, on appelle le script ainsi :

le-script secret.txt # on fournit un chemin relatif/absolu vers secret.txt

Personnellement, je me suis fais un petit alias.
Je suis ouvert à toute critique... ;) J'ai un petit
doute sur le fait qu'avec la commande trap j'arrive
bien à faire exécuter la fonction cleanup en toutes
circonstances.

Merci de ton aide gump.
François Lafont

--------------------------------------------------
#!/bin/sh

export PATH="/usr/local/bin:/usr/bin:/bin"
PASS_FILE="$1"

if ! which mcrypt >/dev/null 2>&1
then
echo "Sorry, mcrypt is not installed." >&2
exit 1
fi

if [ ! -e "$PASS_FILE.nc" ]
then
echo "Sorry the file "$PASS_FILE.nc" doesn't exist. Bye." >&2
exit 1
fi

cleanup () {
printf "nCleanup...n"
if [ -e "$PASS_FILE" ]
then
echo "Shred the clear file..."
shred --remove --zero "$PASS_FILE"
fi
if [ -e "$PASS_FILE.nc.old" ]
then
echo "Remove the old version of the encrypted file..."
rm -f "$PASS_FILE.nc.old"
fi
if [ -e "$PASS_FILE.nc" ]
then
echo "Set the good UniX rights for the encrypted file..."
chmod 0400 "$PASS_FILE.nc"
else
echo "WARNING... There is something wrong." >&2
echo "The encrypted file exist no longer." >&2
fi
}

trap cleanup EXIT INT TERM

echo -n "What do you want to do?
- to view the file, press v
- to edit the file, press e
Your choice: "

read answer

if ! echo -n "$answer" | grep -qE -e '^(v|e)$'
then
echo "Sorry, your choice is incorrect. Bye." >&2
exit 1
fi

if ! mcrypt --quiet --decrypt "$PASS_FILE.nc"
then
# Bad password, stop.
echo "Sorry, bad password. Bye." >&2
exit 1
fi

case "$answer" in

"v")
vim -n "$PASS_FILE"
;;

"e")
mv "$PASS_FILE.nc" "$PASS_FILE.nc.old"

if vim -n "$PASS_FILE"
then
printf "nEncryption..."
printf "n=============n"
if mcrypt --algorithm 'rijndael-256' --quiet "$PASS_FILE"
then
exit 0
else
mv "$PASS_FILE.nc.old" "$PASS_FILE.nc"
exit 1
fi
else
echo "Sorry, problem during the edition, the new version will be not encrypted." >&2
mv "$PASS_FILE.nc.old" "$PASS_FILE.nc"
exit 1
fi
;;

*)
echo "Ooops..."
exit 1
;;

esac
--------------------------------------------------

Salut,

Francois Lafont a écrit le 29/08/2015 01:39 :

(enfin si on met de côté les
traces du fichier faites auparavant en utilisant rm avant
d'utiliser shred).

Regarder si le logiciel d'édition si tu en utilises un ne laisse pas une
trace par exemple fichier.txt~

--
Stéphane

Reste là le pb potentiel de retrouver une partie du cotenu dans le swap,

Oui. Mais le paquet secure-delete que j'ai indiqué permet aussi
d'effacer le swap de manière sécurisée ( voir la page de Korben ). Il
faut le démonter avant par un swapoff et puis le remonter par un swapon.