Sur le disque dur de mon ordinateur portable, j'ai une partition chiffrée de 20Go environ contenant mes données. En cas de vol de portable, et si l'algo de chiffrement utilisé tient ses promesses, mes données sont inaccessibles.
Dans sa configuration actuelle, le système me demande le mot de passe
au démarrage, et sans cela je n'aurai pas accès à mes données.
J'aurais pu mettre en place un répertoire /home
bidon pour donner le
change dans le cas où des personnes trop curieuses se douteraient de
la présence de données chiffrées à cause de la demande de ce mot de
passe.
Oui mais, est-ce que c'est crédible de jouer l'idiot sur la présence de 20Go de données chiffrées sur le disque ? Pour le savoir j'ai écrit un programme de statistique simplissime qui compte la fréquence d'apparation de chaque valeur d'octet possible (et idem pour les bi-octets) sur une plage de 1Mo, et ce tous les 10Mo. Puis on calcule la distance des fréquences mesurées à une distribution idéale parfaitement aléatoire.
Voici le graphe que j'obtiens pour les monogrammes:

et de même pour les bigrammes:

Si vous avez du mal à distinguer sur les courbes ce qu'il se passe après 3400 environ (ce qui correspond à sauter les 34 premiers gigaoctets du disque), c'est que bingo, vous avez trouvé mes données chiffrées qui ressemblent vachement à du bruit uniforme.
J'ai entendu plusieurs fois à la radio (Digital Planet, sur la BBC, en podcast) qu'il serait possible de refroidir la barette de RAM d'un portable dont les données sur disque sont chiffrées, mais dont la clé se trouve dans la RAM, et de transférer à chaud (ha ha) la barette vers un autre portable. Le froid empêche la DRAM de perdre ses données pendant quelques minutes, et ensuite on peut analyser le contenu de la barette immigrante pour trouver la clé. Donc si quelqu'un veut vraiment te piquer tes données, il y a moyen de le faire (à condition de te chourer ton portable lorsqu'il est en veille ou en marche).
Salut Matthieu. J'ai aussi vu ces résultats passer sur les sites habituels. On va supposer qu'on me piquerait mon portable alors qu'il est éteint depuis longtemps
Et je fais quoi de mon azote liquide, moi ...
Tu le laisses couler sur une barette de RAM et tu observes les soudures qui en prennent un coup car les CTE sont très différentes. Pour cette raison et pour d'autres (il faudrait vraiment descendre à qlqs K) je pense que ça ne marche tout simplement pas.
Je fais bien de l'utiliser pour garder mes M. Freeze au frais.
Bon, j'imagine que tout le monde s'en fout, mais j'ai été choquée par les memset, où non seulement la taille est hardcodée (alors qu'utiliser « sizeof stats » serait plus élégant et plus robuste), mais en plus ils sont suivis par une boucle qui a exactement le même effet.
On dirait que je passe trop de temps sur comp.lang.c moi...
C'est juste que j'ai oublié d'enlever les boucles après avoir décidé d'utiliser memset à la place
Pour la taille hardcodée, aucun scrupule dans ce cas précis.
Aucun scrupule à mettre à zéro les 256/65536 premiers octets d'un tableau d'entiers de forcément plus d'un octet chacun (on ne peut pas faire d'implementation conforme de la librairie standard sans sizeof (int) > sizeof (char)) ? Perso' je trouve ça inacceptable.
Ça suffit comme démonstration du côté plus robuste de sizeof ?
Tu as raison Natacha, j'ai complètement merdé.