Comment faire en sorte que mon disque dur soit illisible sans un mot de passe au démarrage?
Différentes sortes de cryptages? Performantes?
Est-ce que ça a une influence sur un usage normal habituel du PC?
Merci

up

Salut,
Jettes un oeil sur des soft comme DriveCrypt ou BestCrypt. Ce dernier ne crypte pas de partition réelle à ma connaissance.

 
Tu as plusieurs solutions : s'il s'agit d'un disque contenant l'OS, tu devras passer par un rack sécurisé, afin de garder un cryptage transparent. Par contre, s'il s'agit d'un disque supplémentaire, tu peux soit utiliser la même solution, soit crypter de façon logicielle tout ou partie de ton disque en créant des partitions virtuelles, etc. Il y a pas mal de softs qui font ça, comme ceux cités au dessus.
 
Sinon, aucune influence sur l'usage normal des disques, si ce n'est bien sur une certaine diminution des vitesses de lecture / écriture.
 
Edit : exemple de rack crypté :
 
http://www.ldlc.com/articles/AL00000044/page1.html

Le cryptage avec une clef de 40 bits, c'est de la rigolade.
Seule solution raisonnable pour toi: crypter en software avec AES 256 bits.
Sous Linux c'est facile avec dm-crypt intégré au dernier noyau (tu peux essayer la Knoppix).
Evidemment tu n'envisageais pas de "sécuriser" tes données sous Windows, de toute façon ...

kler que le 40bit ca saute en quelque heure

Du cryptage en 40 bits est clairement insuffisant pour un degré de protection correct, mais si c'est pour cacher des données à sa petite soeur ou sa grand-mère, ça suffit 30 fois... Il faudrait qu'il nous dise à quel usage c'est destiné...
 
Par contre, l'usage de l'AES 256 bits est clairement disproportionné et completement inutile ; il est dommage de préconiser un tel degré de chiffrement alors que le 128 bits est tout aussi sûr en pratique pour un bon paquet d'années. En général, les gens qui insistent pour chiffrer avec la plus grande taille de clef possible se montrent en fait de piètres connaisseurs des systèmes cryptographiques.

Juste crypter de telle sorte que si l'on me pique le PC on ne puisse pas récuperer le contenu du dur. Je suis sous Win XP Pro, et ne compte pas pour le moment passer à Linux ou autre.
Merci pour tous les renseignements fournis.

 
Je me doutais un peu de ce genre de besoins... Bref, pas de secret défense hein ?
 
Bon, dans ce cas là, n'importe quel système fera l'affaire, même le rack sécurisé ; si on te pique ton ordi et qu'on récupère un disque illisible il y a peu de chance pour que l'on s'embête à cryptanalyser le contenu... au pire, si c'est possible il est reformaté !
 
Mais le plus simple pour toi, comme tu es sous WinXP, c'est d'utiliser un logiciel qui monte des partitions virtuelles à partir de fichiers cryptés. Tu ne laisses que le système en clair sur le disque, pour démarrer correctement, et tu mets dans ta ou tes partition(s) tout ce que tu estimes devoir rester confidentiel. C'est très simple à utiliser, tu peux par exemple essayer avec ce genre de soft pour voir si le fonctionnement te plait (il en existe d'autres) :
 
http://www.jetico.com
 
Ceci dit, en théorie le niveau de sécurité de ce procédé est bien supérieur à celui du rack sécurisé, à cause des algorithmes plus puissants que l'on peut utiliser.
 
 
 

http://www.phoenixjp.net/news/fr/r [...] 3#news5139
ceci est peut être intéressant pour ton usage

moi perso j utilise bestcrypt et j en suis tres content

AES-128bits c'est très bien, mais passer à 256 bits est pratiquement gratuit en termes de performances. Mais je suis d'accord qu'il faudrait commencer par parler de savoir si la clef est itérée ou pas (attaques par dictionnaire) avant de se prendre le choux sur la taille de la clef.
Quant à dire que c'est complètement inutile, je n'irais pas jusque là.

 
On part - bien sur - sur l'hypothèse d'une recherche par force brute sur une clef générée aléatoirement, ce qui rend toute attaque limitée par dictionnaire hors de propos.
 
Ceci dit, je maintiens qu'une taille de clef de 256 bits est complètement inutile. Après, c'est vrai que les performances n'en patiront pas du tout, mais la question n'est pas vraiment là ; je voulais simplement dire ceci : supposer qu'une taille de clef de 256 bits produit un cryptosystème plus sécurisé qu'avec une taille de clef de 128 bits est une idée fausse et dangereuse, car même si ça se défend en théorie c'est complètement biaisé en pratique et témoigne justement comme je le disais d'une méconnaissance des systèmes cryptographiques. Pourquoi ?
 
En supposant que l'AES ne présente pas de failles connues et ne permet d'être cassé que par force brute, ce qui est communémment admis aujourd'hui, aucun système actuel sur la planète n'est capable de casser de cette façon une clef de 128 bits, loin s'en faut. Dans le cas, très improbable, où cela serait quand même possible par des moyens non conventionnels et encore inconnus de la communauté scientifique internationale, cela signifierait tout simplement que des clefs de 256 bits tomberaient de la même façon et tout aussi rapidement : les moyens utilisés dans ce cas seraient en effet inconnus et laissent supposer une remise à plat complète de la fiabilité des systèmes de chiffrement, ce qui rend complètement caduque n'importe quelle considération de sécurité en rapport avec des tailles de clefs.
 
Donc, pour conclure :  
 
- non seulement ce n'est pas raisonnable de faire croire que l'AES 256 bits est le seul moyen SUR de cacher des informations, parce que ça dépend complètement des besoins de l'utilisateur, et je ne crois pas qu'une attaque disposant de moyens style PNB des états-unis ne concerne l'auteur de ce topic (ainsi par exemple le rack 40 bits est tout à fait adapté à ses besoins),
 
- et en plus préconiser du 256 bits est un mauvais conseil parce qu'en général il repose sur une mauvaise appréciation des systèmes cryptographiques, comme je l'ai expliqué au dessus. Mais c'est pour le principe, si on comprend bien ce qui se passe rien n'empêche bien sûr de l'utiliser.
 
Bref, c'était aussi l'occasion de pousser un coup de gueule contre les intégristes de la plus grande taille de clef possible...
 
(C'est pour réagir sur ce que tu avais dit au début : "Seule solution raisonnable pour toi: crypter en software avec AES 256 bits." )
 
Ah, et j'oubliais : sous entendre que l'on ne peut rien sécuriser sous Windows c'est moyen et ça enlève aussi beaucoup de crédibilité... à moins qu'il ne s'agisse d'un troll ?

OK.
 
 

Pas d'accord. Certaines attaques contre DFC par exemple accéléraient la recherche de clef mais sans la rendre linéaire pour autant. Mais si je me souviens bien (cf site du NIST sur AES) c'était dans le cas de clefs mal choisies. Rien ne dit qu'on ne trouvera pas un moyen de chercher une clef 128bits en O(2^64) tandis que la même méthode appliqué à 256bits laisserait encore O(2^128). Bref si on peut avoir strictement plus de sécurité gratuitement, même si peut-être ça ne servira à rien, c'est strictement mieux. Parce que peut-être que ça ne servira pas à rien.
 
 
 

Ce n'est pas non plus ce que j'ai dit. J'ai juste dit que 40 bits c'était de la rigolade, mais que quitte à crypter avec AES, autant le faire avec 256 bits, c'est gratuit et ne peut pas être pire.
Pour ma part je n'utilise pas AES, j'utilise ça.
 

OK sur le principe de ton argument. Un XOR 1024 bits, par exemple, ne vaut rien, bien qu'il fasse 1024 bits. Ce qui compte, c'est de comprendre ce que fait le cipher. Et de choisir une clef aléatoire, en mode ecb (cf loop-aes qui est en mode ... plain !)
 

OK, c'était un peu rapide, mais je maintiens l'idée, notamment sur AES256 plutôt que AES128. D'ailleurs en théorie AES aurait pu être développé en 512bits, et Serpent pourrait je crois avoir une taille arbitraire, mais dans les deux cas ça a été jugé totalement inutile, c'est donc que tu as raison sur le fond.
 

Ôôôôôh ! Un gros Troll des montagnes ! Oops j'ai été démasqué ...
 

 
Ecartons dès à présent le problème des clefs mal choisies, certes réccurent dans les systèmes de chiffrement symétriques par bloc. Il peut être très facilement contourné lors de la génération de clef. Et même si on ne fait rien, les probabilités d'engendrer de telles clefs sont extrêmement faibles et ne gènent personne.
 
 

 
Justement, tout le fond du problème est là et c'est cet argument qui n'est pas recevable. Tu me dis que rien ne prouve que l'on ne puisse pas abaisser la cryptanalyse de l'AES 128 à une complexité de O(2^64) : bien que cette considération soit vraie en théorie, c'est quand même un peu fort et ça équivaut à casser complètement l'AES ! Diviser une complexité de cryptanalyse par 2^64 ce n'est pas rien, la discussion n'a alors plus lieu d'être... même pour 256 bits de clef d'ailleurs, parce que l'algo est devenu inutilisable (tu ferais encore confiance à un tel algo ?).  
 
Donc, c'est pour ça que 128 bits de clef c'est équivalent à 256 bits de clef en pratique. N'oublie pas que cette discussion porte sur les conséquences d'une attaque par force brute uniquement et non sur une attaque de l'algorithme, réputée de toute façon très improbable pour l'AES. Le seul argument retenu dans le monde de la cryptographie à ce sujet c'est : si on peut casser du 128 bits, à l'heure actuelle (par un système de recherche exhaustive), alors on peut casser du 256 de la même façon et à peu près dans le même laps de temps, parce que les moyens d'attaque sont alors non conventionnels et insoupçonnables. L'algo n'est plus sûr. Point. Et donc l'exemple que tu cites, le seul qui puisse justifier un passage de 128 à 256, ne traite pas du même problème puisqu'il ne repose pas sur les mêmes hypothèses de travail.
 
Et à ce sujet il faut rappeler que même le bon vieux DES, malgré ses défauts, n'a pu être cryptanalysé de façon satisfaisante : ce qui le rends inutilisable c'est simplement la faible taille de sa clef avec les années qui passent.
 

 
Bien sur, rien ne t'empêche d'utiliser du 256 bits, il faut juste savoir ce qui se passe et pourquoi ça ne t'apporte rien fondamentalement en terme de sécurité, malgré l'illusion que cela peut procurer. Mais tu as raison, ça ne peut pas être pire en tout cas
 
 

 
Voila, effectivement c'est l'idée !

Tu dis que si AES est cassé, ce sera forcément dans les principes mêmes de l'algo, donc que la taille de la clef importera peu. C'est un acte de foi (que je trouve raisonnable par ailleurs), mais un acte de foi quand même. Contre-exemple (même si de telles choses ont été exclues par les plus éminents spécialistes actuels pour AES).
 

Euh ... en es-tu si sûr ? Extrait:

Ca je suis tout-à-fait d'accord. La cryptographie, ça n'est pas juste "cliquer ici pour sécuriser vos données", il faut comprendre ce qui se passe.

 
Non, ce n'est pas tout à fait ça. Voici le principe : pour cette discussion, j'écarte d'emblée le fait que l'AES ne soit peut être pas un algo sûr. Dans nos hypothèses il l'est. Après, on peut discuter de ça, bien sûr, mais c'est un autre sujet (et c'est extrêmement improbable, comme tu le dis toi même, donc c'est aussi peut être une discussion moins intéressante, mais bon pourquoi pas ?).
 
Donc, dans notre cadre, la seule façon de casser l'AES c'est par une recherche exhaustive sur l'espace des clefs (taille 2^127 en moyenne). Ce que je dis, c'est qu'il est impossible avec les moyens actuels existants d'effectuer une telle recherche. Ou alors, si on peut quand même (style parano-NSA-etc...), les moyens mis en oeuvre sont radicalement innovants et inconnus (Tout est permis comme supposition : la mécanique quantique, etc.). La conséquence est que la sureté des algorithmes ne dépend alors plus de la taille des clefs... et 256 bits ne sera donc pas mieux que 128.
 
Voila, c'est ce genre de considération qui est aujourd'hui communément admise en cryptologie sur la sécurité de l'AES et consors, s'ils sont étudiés depuis des années et réputés sûrs. En résumé :
 
-> 128 bits c'est largement suffisant, et si c'est cassé sans exploiter de failles dans l'algo c'est inutile d'utiliser des clefs plus grandes... Il faut de toute façon tout remettre à plat !
 
 

 
Oui. Tu fais ici allusion aux techniques de cryptanalyse différentielles (Biham / Shamir) et ensuite linéaires (Matsui) apparues au début des années '90. Elles révèlent effectivement un certain nombre de faiblesses dans le DES mais elles sont inexploitables en pratique, mis à part de rares cas particuliers (elles nécessitent d'énormes complexité en espace et des hypothèses de travail assez précises pour être menées à bien). Je parlais surtout de l'existence d'une faiblesse exploitable (à part la force brute) qui pouvait mettre en danger n'importe quel texte chiffré par le DES, mais justement une telle faiblesse n'existe pas...
 
La seule faiblesse importante du DES c'est la petite taille des clefs utilisées, ce qui a été contourné avec la mise en place du 3-DES.
 
 

 
Nous y sommes

Fouyouuuuuuuuuuuu, je me garde un ptit quart d'heure ce soir pour relire et comprendre tout ça. Merci pour ces infos interessantes...

Juste une ptite question, qui peut avoir l'air bébéte...
Si j'utilise un logiciel pour crypter mon dur, il me faudra rentrer un mot de passe à l'ouverture de cession? Sans lequel je ne pourrais pas accéder à mes données? C'est le principe de fonctionnement?

 
Disons que ça a un peu dévié du sujet initial... Ne t'en fais pas, tout n'est pas primordial pour toi dans cette discussion ; en fait le plus important c'est de comprendre ses besoins et les solutions que l'on veut mettre en oeuvre. Donc, d'après tes besoins, et pour faire simple et pas cher, essaye d'utiliser des logiciels de gestion de partitions virtuelles cryptées. Je te remets le lien pour l'exemple :
 
http://www.jetico.com
 
Voila, après si tu as la moindre question, n'hésite pas

 
Oups... j'avais pas vu ta réponse !
 
Bon, si tu utilises un tel logiciel, comme je te l'ai dit le plus simple c'est de laisser le disque en clair, comme d'habitude, et de créer des fichiers "conteneurs" d'une taille que tu définiras et qui contiendront tes fichiers sensibles. Ensuite, après avoir ouvert ta session tout à fait normalement, tu ouvriras ces fichiers conteneurs avec le mot de passe associé (choisi lors de la création de ces fichiers) et tu verras se monter une partition virtuelle comme si tu venais de rajouter un autre disque, et tu pourras utiliser tout ça de façon totalement transparente ! Tu n'auras qu'à déplacer dans ces partitions virtuelles tous les fichiers que tu souhaites protéger...
 
Ensuite, si tu rebootes ou si tu démontes manuellement ces partitions, tes fichiers deviennent inaccessibles.
 
Voila ! On peut faire différemment, comme crypter des partitions entières existantes mais bon l'utilisation des fichiers conteneurs est sans doute plus simple...