Re: Truecrypt et table de caractères

Sylvain a écrit :
> Gump wrote on 09/03/2008 01:12:

> - utiliser des keyfiles [1] qui sont mixés via un calcul de CRC avec
>   le passphrase (s'il existe).
> [1] un keyfile peut apporter facilement de l'entropie mais peut souffir
>  + d'un manque de confidentialité (s'il est visible sur le disque
>    contenant le container ou la partition chiffré),
>  + d'un manque de protection physique, si c'est un fichier facilement
>    effacable

ca ressemble à un "salt"
un intérêt que je vois du keyfile c'est que ca permet d'éviter qu'un 
attaquant ne se constitue une fois pour toute une table des clés 
associées à un mot de passe donné. des sortes de rainbow-table.
ce genre d'attaque est super effeicace. tu passe 2 ans (ou tu la remplie 
en continue) à remplir une table des clés obtenues a partir d'un mot de 
passe, et à chaque tentative de déchiffrement tu tente de déchiffrer 
avec les clés associées dans l'ordre du plus probable au moins probable...
a note que les mots de passe aléatoires seront alors stockés après les 
mots "manuels", mais par ordre de taille... on testera les 8 caractères 
avant les 9...

le pire c'est que si tu connais un clair probable (cas utile avec le 
header ou si le chiffrement c'est pas en chainage de bloc), tu peux même 
faire une attaque de dictionnaire sur le chiffré.

pour chaque clé stockée, associée a un mot de passe probable, to poura 
calculer le chiffré de quelques clair probables.

ensuite si tu retrouve un bloc chiffré correspondant, tu peux alors 
remonter à la clé et donc au mot de passe.

avec un "salt" ou un keyfile, il faut que tu te refasse une clé à chaque 
fois d'après chaque mot de passe. plus long. et il faut que tu te 
refasse alors aussi la table des chiffrés de clairs probables.




> on voudra, à tout le moins, stocker son keyfile sur une clé USB.
> autre solution le stocker sur carte à puce qui garantira la sécurité
> physique (pas d'effacement par mégarde) et logique (protection de la
> lecture du fichier par PIN/passphrase qui pourra ici être court car
> associé à un compteur d'essai limité) - j'ai fini il y a peu un tel
> add-on pour TrueCrypt, j'en reparlerai peut être ici sous peu.

ca c'est une bonne idée, du multi-facteur.

associé un "je sais" a un "je possède".

ajoute une clé biométrique pour le "je suis" et tu as un truc assez solide.

en plus c'est très bien d'associer des mots de passe à nombre de 
tentatives fini.

le défaut des trucs chiffrés c'est que tu peux tenter un nombreinfini de 
fois.

si tu as un dispositif qui s'efface après quelques tentatives, l'attaque 
massive est impossible. il faut toucher dans le mille.

mais réflexion hors sujet

tu es à la merci d'une faiblesse du hardware.


  la faiblesse du truecrypt et de tous les systèmes de chiffrement de 
disque par ordinateur sans dispositif crypto externe, c'est que l'on 
sait facilement lire la DRAM 30 minutes après l'arrêt de l'ordinateur 
(si on refroidit la DRAM, ou quelque minutes à température ambiante).

le seul truc qui marche c'est le dispositif de chiffrement à clé 100% 
protégé (carte a puce typiquement, ou équivalent usb). or puisqu'on ne 
peut plus faire confiance à la DRAM ca veut dire que le dispositif doit 
TOUT chiffrer en temps réel.

contrairement aux réseaux on ne peut se contenter d'un chiffrement par 
clé de session.

une alternative que je verrais ce serait la compartimentation des clés, 
c'est a dire de chiffrer chaque fichier, chaque dossier, par une clé 
distincte que l'on déchiffrerait avec la clé maitresse stockées dans un 
dispositif hardware (carte a puce, dongle usb).

ainsi à tout instant on aurait en mémoire que la clé des fichiers 
ouverts, qui sont probablement de toute façon déjà dans les caches 
mémoire de l'OS.

une autre idée ce serait une mémoire type SRAM, rapide, mais qui 
s'efface vraiment instantanément, et que l'on ai pas à recopier en DRAM.

outre le hard ca demanderais une programmation qui véite de recopier des 
dérivé de la clé hors de la SRAM (genre les différentes BOX des algo 
dérivées de la clé)