Reprise du message précédent :

+

=

• Donc on est obligé de choisir FAT32 pour le formatage du container, si on veut créer un container caché après?
• On ne peut pas stocker un fichier supérieur à 4Gb dans un container en FAT32?
• Donc si mon HDD 1To est partitionné en FAT32, je ne pourrais créer des container que de 4Go.

→ Donc en gros mon HDD je le met en NTFS
→ et je crée un container FAT32 de 999Go
→ dans lequel je crée un container caché de 998Go

Question :
▫ Ce container caché peut-il être NTFS? Peut-on créer un container NTFS caché dans un container FAT32?
▫ Si oui, donc je pourrais mettre des fichiers de plus de 4Go ou pas? (dans le container caché NTFS qui est dans un FAT32?).

Bon bah faute de réponse dans l'immédiat, j'vais mettre de côté l'utilisation de TrueCrypt, pour ces raisons importantes :

• Le flou/la complexité des notions de formatage des containers imbriqués.
• Les performances/pertes de place du FAT32 :

             * Diminution de l'espace total.
             * Fichiers de 4Go maximum.
             * Difficulté à accéder aux dossier contenant un grand nombre de fichiers.
             * Perte important de performance dûe à la fragmentation.
             * ...? etc etc (voir http://ixbtlabs.com/articles/ntfs/index3.html  pour plus d'infos).

• Le temps nécessaire au chiffrement d'un très gros volume (et pas question de faire des morceaux de 150Go...).
• La récupération de données fortement diminuée à cause du chiffrement.

Bref, mieux vaut réfléchir à un excellent moyen de détruire son HDD en -10 sec en cas de danger, plutôt que d'avoir un SATA hybride et constament lent...

Je ne suis pas d'accord avec la plupart de tes points, et voici pourquoi:
 

• Pourquoi faire des containers imbriqués ? Evidemment ca complique les choses, mais c'est surtout inutile imho.
• Les limitations du FAT32, tu les a dans tous les cas, avec ou sans TrueCrypt. Pareil pour la fragmentation. Par ailleurs, un volume monté se defragmente au meme titre qu'un volume non crypté. Enfin un fichier container ne se fragmente pas tant qu'il est seul sur le disque
• Le temps de formatage d'un disque est certes élevé, mais il s'agit d'une procedure a faire une seul fois. Par ailleurs, ca ne prends pas beaucoup plus de temps qu'un formatage complet.
• Evidemment, puisque c'est le but principal du chiffrement: rendre impossible la recuperation de données sans mot de passe. Mais le probleme ne vient pas du chiffrement en lui-meme, mais plutot du manque de backup. Autrement dit, c'est un faux-probleme d'apres moi.  

Pour conclure, vu la vitesse des disques actuels (je prends l'exemple de mon dernier Caviar Black 640), la perte de performances est négligeable pour une utilisation "normale". Meme avec des applications lourdes installées sur un volume encrypté, ca tourne correctement. Evidemment, le but n'est pas de faire des benchmarks ou d'etre le plus rapide

Moi ce qui m'intéresse, c'est de créer un container caché. Donc c'est du FAT32, et donc je me demande si ça va transformer mon SATA en un truc tout pourrave qui va mettre 10mn à afficher les milliers de fichiers qu'il y aura dessus, ou pas, et si ça va ramer comme un porc dès que je lancerais une appli' lourde, ou pas (vitesse lecture du FAT32...).
Je sais pas non-plus la compatibilité des appli' avec le FAT32, etc.

J'ai jamais utilisé du FAT32, et à en croire les comparaison avec le NTFS, ça convient pas à des disques trèèèès gros (genre 1To), et encore moins aux disques bourrés de fichiers.

Et combien de place je vais "potentiellement" perdre à cause de la taille des clusters? Bref....

Sans oublier les 12H de chiffrement d'affilée !!!! Est-ce qu'on peut "mettre en pause" + hibernate pour dormir?? Mon PC est dans ma chambre et j'ai l'ouïe fine, lol.

ParadoX a répondu au principal. Je ne vais pas reprendre tout ce que tu as dit car il y a beaucoup de répétition :
 

 
C'est pas malin de faire comme cela et c'est bien pour cela que le OTFE a été inventé. Dans le cas d'un dossier chiffré qui contient des fichier en claire cela reviendrais à déchiffrer tout le dossier à chaque fois que tu l'ouvre puis le rechiffrer quand tu le ferme. Si ton dossier fait 100 go tu imagine le temps que cela prendrais ? L'avantage de l'OTFE c'est que tu chiffre et déchiffre uniquement les fichiers dont tu as besoin et donc c'est immédiats.
 

 
Non, car une des 3 lois du chiffrement de disque impose que le chiffrement ne dois pas prendre de la place sur le disque. Ou vraiment très très peu. Et c'est pour cela qu'on utilise des algorithmes de chiffrement par bloc et non par flux pour le chiffrement de disque.
 

 
Chaque application est différente, certaines ont besoin de faire des accés constant aux fichiers, d'autres pas en chargeant tout dans la mémoire au démarrage. Comme je l'ai déjà dit si tu utilise l'AES sans cascadé les algortihmes de chiffrement la perte de performance devrais être la plus faible. Mais tu aura une perte de performance quoi qu'il se passe.
 

 
Tout dépend de ton processeur et ton HDD. Pour ma part chiffrer 500go avec un core 2 duo 3ghz et un seagate 7200.11 m'avait pris 3 heures l'année dernière (de mémoire). Et puis quand bien même tu lance le chiffrement le matin, tu va te promener, draguer des filles, et paf le soir c'est finis
 

 
Il faut bien que tu comprenne un truc. Le chiffrement de disque a été prévus pour rendre tes données confidentiels en les chiffrant. Et forcément les opérations de chiffrement/déchiffrement prennent de la ressource à ta machine. Si tu veux de surcroit stocker tes données dans des volumes caché sans perdre de l'espace sur ton disque attend toi à des performances forcément amoindris. Il faut faire des compromis.
 
Beaucoup de tes questions peuvent trouver leurs réponses en testant toi même.
 
Test donc et reviens nous avec tes chiffres

Merci à toi artiflo pour les précisions.
Je ne suis cependant pas d'accord sur le chiffrement du dossier plutôt que des données : car ce que j'avais en tête, c'était de chiffrer juste "l'accès", et pas l'entièreté du dossier comme tu le soulignais. D'ailleurs, en fait j'ai trouvé réponse à cette question je ne sais plus où sur le web, où on expliquais simplement que le chiffrage des données plutôt que de l'accès permettait d'éviter la lecture des données par quelqu'un qui CONTOURNERAIT l'accès.
En gros, ok, si y'a un password juste pour l'accès du dossier windows => on prend un autre OS ou quelconque moyen de lire les données sans passer par l'ouverture du dossier.

Bref, sinon tu as raison en un sens, c'est un peu à moi en tant qu'utilisateur de partager mon expérience.

Mais le dilemne, c'est :
- j'ai un HDD d'1To vierge
- j'ai des données qui attendent d'être transférées dessus, de quoi le remplir au tiers
- alors soit je crée un container caché de 999Go dessus en FAT32, j'y place les données, et que ça me plaise ou non bah je pourrais plus revenir en arrière : car avant d'avoir un retour sur les performances, il va se passer du temps, et ça signifie que les HDD que j'aurais libéré en copiant leurs données sur le 1To vont accueillir de nouvelles données . Donc plus de retour en arrière possible.
- ou bien je ne chiffre pas le 1To et en attendant d'avoir un retour d'un autre utilisateur, j'y place des données (bah oui forcémment ). Mais dans ce cas je ne pourrais plus crée de container qui y prenne tout la place maximum.

Bref, c'est un dilemne assez perso en somme, et je sais qu'il m'appartient à moi et à moi seul de le résoudre.
Mais franchement ça m'aurait vraiment aidé qu'on me dise :
- nan j'ai essayé, le FAT32 dans une partition de 999Go c'est vraiment la galère, il met 10mn à l'ouvrir et c'est ultra-lent pour la lecture des fichiers.
- ou ouai c'est génial ! Ca marche du tonnerre !! Pas vu de baisse significative de perfs !!

 
C'est exact, protéger uniquement l'accès et pas les données est un non-sens. Dans l'exemple que tu donne, il suffit de prendre n'importe quel bootCD linux pour avoir accés a toutes tes données.
 

 
Je ne comprend pas ce qui te rebute à tester et de surcroit si ton HDD est vierge.  
Tu es pas obligé de formater le tera pour les test. Tu fais uniquement quelques dizaine de go de quoi mettre ce que tu veux tester dedans (surement des jeux, des films, de la zik et des apply) et tu test. Cela devrait pas te prendre longtemps, en quelques heures c'est fait

Au final j'crois que le truc le plus rebuttant dans le FAT32, c'est le scandisk après chaque plantage du PC ou reboot sauvage. Ca, à mon avis sur un HDD 1To ça devient vite chiant...

Par contre j'ai une question en rapport avec le fait de créer une partition chiffrée, et le fait qu'elle ne soit pas reconnu dans Windows XP (impliquant le problème du formatage proposée à chaque fois) : est-ce que finalement ça constituerait un élément efficace de protection?

Je veux dire : si quelqu'un se ramène pour te chourrer ton HDD , qu'il le branche sur XP (ou un autre OS), et qu'il soit reconnu comme "non alloué", est-ce qu'il pourra se rendre compte qu'il y a quand même des données dessus?

edit : j'ai la réponse à ma question dans le screenshot concerné, fournit en page1, on voit bien "100% frei", donc ça veut dire que l'OS peut quand même déterminer s'il y a des données dessus.

Alors question : ok, y'a des données dessus, mais comment ils peuvent voir qu'il y a un container TrueCrypt et exiger le mpd? ^^

D'ailleurs la question pourrait être simplement : comment monter une partition chiffrée qui n'est pas reconnu par l'OS (comment aller chercher la partition)? Je demande ça, parce que je ne crois pas que celà aie été expliqué, il a juste été donné le moyen d'utiliser un batch...

Ce dont tu parle s'appel le "déni plausible" ou "plausible deniability". On en a abondamment parlé les pages précédentes.  
 
Tous les volumes créer par truecrypt sont sensé apparaitre comme étant des bits aléatoires. En pratique c'est pas forcément vrai : http://www.artiflo.net/2009/05/det [...] -fi-tools/
 
D'où l'intérêt de faire ce que tu fais en créant un volume chiffré caché dans un autre volume chiffré.

Ô miracle, je viens de trouver une info exceptionnelle qu'il serait bon d'incruster dans le topic :
"Depuis les versions 5.0 et ultérieures, le volume caché peut être hébergé au sein d'un volume de type NTFS (dans ce cas, la taille du volume caché ne pourra excéder la moitié de celle du volume externe)."
source : http://fr.wikipedia.org/wiki/TrueCrypt
 
Sinon, ma question était simple :
- Je fait en sorte que tout ma partition de mon HDD soit chiffrée.
- Elle n'est pas reconnue comme formatée sous Windows.
- On peut toutefois voir un certain pourcentage d'espace libre ou pris sur le HDD.
- Soit. Mais comment diable soupçonner qu'il s'agisse d'un container Truecrypt? Il n'y a aucun fichier dedans, et l'explorateur ne peut pas explorer puisqu'aucune lettre de lecteur n'est allouée !!!
 
Il faut donc lancer truecrypt, désigner le HDD physiquement, et... rentrer un mdp. Mais si on n'a pas le mpd, comment soupçonner l'existence d'un quelconque container TrueCrypt puisque rien ne s'ouvrira !?
 
J'ai peut-être loupé un wagon? Expliquez-moi en détail l'ouverture d'une partition chiffrée, puisque le topic n'en parle pas (il parle seulement de l'ouverture d'un fichier-container à aller chercher dans l'explorateur, chose impossible avec une partition tout entière invisible sous l'explorateur !)

Bon, j'en ai marre des euphémismes et des détours. (lol)

En gros dites-moi, si on chiffre entièrement une partition, quel schéma est vrai :

Schéma 1 :
a - La police débarque chez toi pour X raisons
b - Tu as des données "sensibles" dans ta partition chiffrée.
c - La police réquisitionne ton HDD, voit qu'il n'apparait pas dans l'explorateur, mais par contre voit quand même qu'il y a un certain pourcentage d'occupation de place, donc qu'il y a des données.
d - ... Ils viennent direct vers toi en te demandant le pass TrueCrypt??
e - Toi : "mais comment vous savez que c'est du TrueCrypt dessus?"
f -  là je sais pas quoi mettre justement !

Schéma 2 :
a - idem
b - idem
c - idem
d - Il viennent te voir et te demande "De quel type de données s'agit-il?"
e - Toi : "Euh je sais pas, y'a des données dessus? On peut y accéder par l'explorateur? C'est quel type de données? Je comprend pas, moi j'ai rien sous l'explorateur, je viens d'acheter le disque je l'ai pas encore formaté. D'ailleurs vous voyez bien, y'a pas de lettre de lecteur. Donc ça doit être des données résiduelles..."
f - La police : "Bon, René, refiles-lui son disqueu-dur, on peut rien contre lui. Lâche ce disqueu-dur stp René".

Sérieux j'suis grave ou pas? Quand on a un fichier de taille X sans extension, on peut le lire avec un éditeur universel, et puis si on n'y arrive pas et que ça indique que c'est crypté, bah là ok c'est normal, y'a de quoi exiger un mdp.
Mais si y'a rien que des données "fantômatiques" qu'on ne peut même pas tenter d'ouvrir?

edit : rien à voir avec le déni plausible. Le déni plausible c'est de ne pas pouvoir prouver l'existence d'un container caché, au sein d'un container maître dont on connait l'existence. Mais la subtilité de ma question portait justement sur la reconnaissance d'un quelconque container TC.

si je ne m'abuse, quand tu es perquisitionné, les flics ne partent pas directement avec ton dur, ils constatent d'abord sur place l'infraction...
 
du coup, un simple chiffrement n'est pas suffisant si ton volume est monté... mode paranoia ON : un interrupteur de prise radiocommandé sur la multiprise de l'ordi, placé à cote de la porte d'entree et si les flics debarquent, tu coupes le jus

loooool, pas mal, je prend note. ^^

Je n'aime pas parler de flic, je préfère parler d'attaquant.
 

 
Sans dec ! Je vois pas en quoi cela t'aide pour ton cas...
 

 
Mais on s'en tape de comment windows la reconnait ta partition. Tout ce qui compte ce sont les bits de données qu'il y a dedans.
 

 
Oui un gros wagon, monter une partition chiffrer ou un volume chiffré c'est la même chose. Si au lieu de posé des questions tu essayer par toi même ça irait plus vite.
 

 
On s'en tape de ce que voit ton explorateur windows. Les attaquants, viennent, prennent ton ordis puis copie tout ton disque bit à bit. Le but du jeu étant que les volume TC ne ressemble qu'a des bit aléatoire. Ce que j'ai déjà dit plus haut. Dans ce cas la tu utilise les répertoires chiffré caché ce que tu veux faire depuis le début. Comme cela tu donne aux attaquant uniquement le mot de passe de la partition chiffré leure. La partition chiffré qui contient véritablement les données reste caché. RTFM !
 

 
C'est pas des débiles les attaquants, si ils viennent chez toi c'est qu'ils ont une bonne raison. Ton disque ils le prennent et ils font une copie bit à bit ils s'en tappent de ce que tu va leur raconter. C'est ton disque qui va parler à ta place.
 

 
??? Tu te drogue ? Gros délire là...
 

 
Le deni plausible c'est la capacité de ne pas pouvoir différencier un fichier/volume/partition/whatever chiffré d'un espace de donnée aléatoire. Et donc j'apportais dans mon post plus haut, la preuve que le deni plausible ne pouvait plus s'appliquer avec TC et donc il faut utiliser les volumes caché chiffrer dans d'autre volume. Ce que tu veux faire depuis le début.
 

 
Quand les attaquants viennent chez toi ils prennent ton ordis, l'amènent au poste puis copie bit à bit tout tes disques. Donc effectivement si tu ton HDD est monté il vaut mieux avoir un raccourci sur le bureau pour le démonter vite.

Donc on va voir lequel de nous deux fume vraiment :
1 - selon toi une partition chiffrée est un espace de données aléatoires -__- (dixit "le but du jeu étant que les volume TC ne ressemble qu'a des bit aléatoire." )
2 - selon toi, le déni plausible est de ne pas pouvoir différencier un volume d'un espace de données aléatoires, chose désormais révolue : ON PEUT LES DIFFERENCIER !
3 - selon toi, il faut que j'utilise un volume caché (sous entendu : pour ne pas différencier les données)... qui est sensé être caché dans des données aléatoires.

@__@ selon toi les points 2 et 3 ne serait-ils pas contradictoires?

Et le point 1, genre... tout à fait étrange.

Explications :
Si un volume caché est sensé se cacher dans les données aléatoires d'un volume maître, ça veut bien dire que le volume maître est constitué de :
- données non-aléatoires
- et... de données aléatoires

Donc ma partition maître serait faite de données non-aléatoires+aléatoires. Non?

Ma question n'était pas dénuée d'un certain sens : à défaut d'être lisibles puisque chiffrées, des données ont au moins à être "perçues" comme telles. Désolé si la seule représentation que j'ai de "données", ce soit celle de... fichiers !
Fichiers qu'on puisse "détecter dans l'explorateur", même si illisible et sans extension.

Finalement, c'est dommage, à peu de choses près l'idéal aurait été atteint : si on ne voyait pas ce foutu "free space available" dans l'OS ou dans un soft, il serait impossible de se dire qu'il y a des données [chiffrées] sur une partition "non allouée"...

Tout d'abord, je te le répète pour la deuxième fois : RTFM !
 

 
Ce n'est pas selon moi, mais c'est selon la doc de truecrypt. C'est un espace de donnée apparaissant comme étant des données aléatoire : http://www.truecrypt.org/docs/?s=plausible-deniability
 

 
Sans dec, c'est moi qui ai écris les premiers articles à ce sujet... ICI et ICI
 

 
Oui, et ce n'est toujours pas selon moi, mais selon la doc de TC http://www.truecrypt.org/docs/hidden-volume
Un volume caché chiffré contenue dans un volume chiffré est pour l'instant indétectable.
 

 
Détecter un volume chiffré dans un disque c'est possible, détecter un volume chiffré caché dans un autre volume chiffré c'est pour l'instant impossible.
 

 
Et non, tu devrai lire la doc pour comprendre comment est fait un volume TC http://www.truecrypt.org/docs/?s=v [...] ification.
 

 
Là il te manque un gros bagage informatique si la seule représentations des données pour toi ce sont des fichiers détectable avec l'explorateur.
 

 
Je n'aime pas trop ta façon d'affirmer des choses alors que ne tu ne l'ai maitrise pas. Cela fait plusieurs post que tu le fais.  
 
Je répond une dernière fois à ton besoin :
1 / Tu chiffre ton disque de 1to
2 / Tu créer un volume caché dedans occupant x% de l'espace disque.
3 / Tu met des fichiers quelconque dans le volume chiffré leurre.
4 / Tu met tous tes fichiers confidentiel dans le volume chiffré caché.
 
Exemple :
Un attaquant détecte que tu as un disque/volume chiffré, il t'oblige à lui remettre le mdp.  
Tu donne le mdp du volume leurre, le volume caché reste indetectable (pour l'instant) l'attaquant n'a accès qu'a tes donnée leurre et il ne peux pas savoir que le disque contient un second volume chiffré caché.
 
En général lorsque je dis 2 fois RTFM à la même personne, je ne prend plus la peine de lui répondre si je dois le dire une troisième fois.

Gluonk, Artiflo a raison. Merci de ne pas sortir des phrases telles que "Donc on va voir lequel de nous deux fume vraiment". Ce topic est la pour aider les gens, et ce ds la bonne humeur. D'ailleurs, comme tu le dis toi-meme, "Merci à tous ceux qui donnent de leur temps pour aider les autres."

Ouai mais bon, j'ai un droit de réponse à un truc du genre "t'as fumé". Stout. L'avait qu'à pas commencer
 
Et désolé, mais le lien qu'il m'a filé traite de la fin du déni plausible. Or :
- si le déni plausible c'est un volume caché dans les données aléatoires d'un volume maitre...
- ... alors le soft qui met fin au déni plausible bah il s'attaque au volume caché (et pas au volume maître , enfin quoi mince!).
 
Ca dans l'article c'est pas clairement mentionné, mais c'est sous-entendu.
Et quand Artiflo m'envoit un tel lien puis deux heures plus tard me dit que j'ai qu'à créer un container caché, bah il se contredit.
 

Donc ton article sur le déni plausible en danger raconte des bobards. -_-
 
Et pour moi (désolé, oui, j'ai certainement faux mais c'est ce que j'ai compris après avoir potassé, et en tous cas j'me contredit pas d'un post à un autre) :
- un volume est constitué de données aléatoires + non aléatoires.
- un volume caché se cache PRECISEMMENT dans les données aléatoires d'un volume maître, ce qui veut dire qu'il se cache dans une partie spécifique faites de données aléatoires, ce qui doit FORCEMMENT etre différenciable de données non-aléatoires (>< )
- car si un volume n'était constitué QUE de données aléatoires, alors l'article susmentionné n'aurait pas traité du déni plausible, mais des volumes TC tout court, toutes catégories confondues !!
edit : c'est bon j'ai compris le principe des données aléatoires TC, enfin j'pense...
 
C'est spé, mais t'façons on s'en fout au final, c'est du domaine du détail inutile. J'veux bien qu'il m'explique clairement Artiflo, mais bon il a pas l'air super enchanté une fois qu'il s'ennerve et qu'on lui montre par A+B une contradiction (qui n'en ai peut-être pas une, mais vraiment tout ça n'est pas clair).
 

Moi j'aime pas beaucoup ta façon non-plus, au regard de ton orthographe
 

J'écoute pas la radio

En plus j'men fout du volume caché, ça fait une plombe que j'ai abandonné l'idée d'utiliser ça, à cause du FAT32 ou du NTFS avec condition amputatrice.

J'était partit juste sur une question simple concernant la reconnaissance de données, avec l'exemple du HDD non alloué mais où on peut voir quelquechose comme "20% free space", ce qui trahit la présence de... quelquechose.
Je me posait la question de quel est le statut de ce quelquechose, rapport aux moyen d'en définir l'intégrité (pour moi l'intégrité c'est un fichier ou une partition RECONNAISSABLE, même si indéchiffrable).

Bref, apparemment j'suis un gros naze avec mes questions trop métaphysiques

edit : merci à vous bien entendu pour avoir eu la gentillesse de répondre à mes questions, même si elles sont tordues !

edit : un autre truc tordu sorti tout droit d'mon cerveau à conneries plausibles : et si on inventait des HDD avec un système interne qui autoriserait ou non l'OS/Software à checker la data dessus?
- Avec un système "passàlacon©Gluonk" : un pass pour accéder au HDD en lecture, un autre pour l'écriture
- si on rentre le bon pass lecture, on a la vraie taille d'espace libre affichée, et on accède aux fichiers.
- mauvais pass lecture = là ça affiche "100% free", donc les données sont indétectables. Toute copie est obsolète.
- intérêt n°1 : quelqu'un vous demande le pass-lecture, vous lui en donnez un faux. Le "système" du HDD mentira et fera comme si il est vierge.
- intérêt n°2 : quelqu'un qui a entré le mauvais pass-lecture ne peut toutefois pas écrire par mégardre sur le HDD faussement vierge, à moins d'exiger le pass-écriture s'il en a l'autorité/(justification)...
- nécessité : le "système" intégré au HDD ne doit pas pouvoir être contourné. En gros, si le système interne ne peut pas dialoguer, il bloque le HDD : "jte comprend pas, tu m'lis pas."
- faille : on démonte le bordel, on fout les plateaux dans un HDD qui n'a pas ce système de protection.

tu te fais du mal...
Perso, j'ai fait joujou avec un conteneur de 10Go pour le fun et je me suis vite rendu compte que c'est pas les 2 mp3 et 3 vidéos de vacances chopées sur le net qui vont me faire envoyer en taule...
A moins d'avoir un gros truc à se reprocher, des données perso sur sa clé USB, ou se balader avec les plans de l'A380 sur son portable je vois pas à quoi ça peut bien servir de se prendre la tête à ce point  

Tu viens de trouver par toi-même 3 excellentes raisons de se poser plus de questions qu'on voudrait qu'on s'en pose...

Gluonk: Arette de jouer a l'avocat du diable, on parle ici de securité de données personnelles... Tes questions sont un peu redondantes/tordues, je trouve, et je ne dois pas etre le seul. Personne ne t'a traité de quoique ce soit ici
 

 
 
Bon mini mise a jour du 1er post, avec le lien du Blog de Artiflo

Juste un petit post pour info :
 
creation d'un container de 650Go en raid 1  
AES-Blowfish-Serpent (hash whirlpool)  
avec un pentium E2160 et 1Go RAM (OS Ubuntu 9)
 
>> 8Mo/s soit env 23h  

Ouch AES-Blowfish-Serpent la belle clé de 768 bits

dois-je conclure que du coup, pour tous mes echanges au niveau du container, je n'obtiendrai pas de debits au dela ?

Non, là pour chiffré tu es limité par ton processeur.  
 
Pour aprés chiffrer et déchiffrer en OTFE tu aura des meilleurs débit, a moins que :
 

• tu ais acheté des disques pourris.
• tu as un contrôleur RAID pourrav style ceux embarqués dans les cartes mère  
• tu es en RAID 1 logiciel et là je crois pas contre que tu fais une erreur

je suis bien en raid 1 logiciel mais c'est volontaire (le proc est largement dimensionné pour cela et je ne suis pas "controleur RAID  dependant" )
on verra bien ce week end, je ferai les premiers essais

Je suis intéressé par le résultat de tes test en RAID1 logiciel linux + TC avec 3 algo de chiffrement. Si tu peux indiqué le modèle de tes HDD se serait super ^^.  
Pense bien a faire les test avant/après chiffrement

Je viens de faire une tentative de réponse par le calcul à childerik concernant la capacité d'un attaquant à casser un mot de passe de x caractères. Le calcul est grossier, c'est juste pour donner une idée.
 
http://www.artiflo.net/2009/07/les [...] -de-passe/
 
Comme d'hab, c'est un brouillon ^^.
 
Extrait :
"Sur ce tableau où la puissance de calcul du plus gros supercalculateur recensé en Juin 2009 est reporté, il apparait qu’un mot de passe de 8 caractères alphanumérique aura l’ensemble de ses combinaisons testé en seulement 0.19 secondes. Si ce même mot de passe utilise des caractères ASCII, il faudra alors 5.51 secondes..."
 
Tous mes articles sur le chiffrement ici : http://www.artiflo.net/category/chiffrement/

Pas forcément de rapport avec la qualité de ton article, mais j'ai pensé à ça en le lisant :

le alt est pas mal non plus    
[/hs]

 
bon............................. TC (ou mon RAID) s'est viandé à................................... 12sec de la fin de la creation du container.............................. soit 23h de calcul pour ...nada...
 
je vais repartir pour un tour, on verra bien
du coup cela me laisse la possibilite de "bencher" vaguement les perfs avant - apres :
 
avant :  
transfert d'une ISO de 4Go : env 50 Mo/sec
transfert 1.6Go de photos : env 60Mo/sec
 
machine :
raid 1 composé de 1 samsung sataII 750go et 1 WD sata II 1To (partitionné en 2 partoches dont 1 de 750go : celle du RAID)
le samsung est connecté à un port sata de la CM, le WD est connecté à un port sata d'une promise tx4 300
raid 1 logiciel sous ubuntu 9
pentium E2160 @1go  RAM
 
a suivre

Exelent the chosen, on se fournis chez le même ^^.
 
C'est bizarre qu'il ai planté à 12sec de la fin, soit c'est un hasard soit ça cache un autre problème.

c'est ce que je me dit... au reboot fsck a trouve un probleme sur un inode et l'a corrige (longuement)
je suis reparti, encore 22 heures

suite du "bench" :
iso 4Go : env 18Mo/sec
1.6 Go photos : env 16-16.5 Mo/sec
 
je vais peut etre revoir à la baisse le chiffrement du containeur principal

Effectivement  
 
AES simple suffit imho

De même que paradox, casser une clé de 256bits par la force brute c'est impossible au aujourd'hui. Comme j'ai expliqué avant, et ça risque de rester impossible encore 10 ans.
Par contre il est probable qu'une vulnérabilité apparaisse d'ici à ses 10 prochaines année. Et le "cascadage" d'algorithme sert à cela, non pas protéger du brute force (même si il le fait sans le vouloir), mais a protéger contre la découverte d'une faille sur un algorithme. Les autres algorithme étant là pour protéger les autres d'une découverte de faille. Pour la petite histoire, pour le DES, les kakie se sont toujours vantés de connaitre une vulnérabilité avant les universitaires. Surement un tout petit peu de vérité un beaucoup d'intox.
 
Pour ce qui est du choix de l'algo de chiffrement l'AES à de meilleurs perf que tous les autres, mais les 2 autres au niveau algorithmique sont très bon aussi. Serpent étant le plus "sure" et twofish le plus "beau" et rijndael étant un compromis des 2 autres. Eli et bruce sont mes idoles, je serais incapable de les départager.
 
Tu pourrais aussi essayer de benché les ressources proco (à vus de nez en pourcentage) avant et après chiffrement durant tes test de transferts de fichier

le triple chiffrement etait surtout là pour me rassurer, particulierement au sujet de failles comme vous en parlez. Par contre, une petite question à ce sujet.
 
Imaginons un container chiffré en AES avec un container caché chiffré sous un autre protocole. Si AES tombe, est-ce que la partie chiffrée par l'autre protocole apparaitra comme evidente (c'est a dire qu'il sera evident qu'il y aura des d'autres donnees chiffrees) ou bien on pourra considerer que ces donnees "aleatoires" ne sont que la base du chiffrement du 1er container en AES ?
 
concernant les bench des ressources proco, j'y avais pensé mais mon moniteur systeme m'affiche 50% de temps UC utilisees sans rien faire : y'a peut etre un petit soucis de ce cote là...
 
en tout etat de cause, je vais creer un container cache en AES dans le 1er container juste histoire de quantifier la perte de perf.
 
Je vous tiens au jus
 
EDIT : hidden container de 550Go en AES : 12h

 
Si une faille est découverte cela permet pas forcément de trouver la clé immédiatement, mais de réduire le temps qu'il faut pour trouver la clé.
TC fonctionne avec des fichier header qui contiennent toutes les infos pour ouvrir les volumes. Chaque volume a son fichier header chiffré. Donc si l'algo qui est utilisé pour chiffré le volume leurre (outer) est cassé, le header du volume caché chiffré dans un autre algo restera sure.
 

 
RAID logiciel caca ?
 

 
Cela me parait normal au vue de la config proco/disk/raid.

le temps ne me fait plus peur, le serveur vis sa vie, moi la mienne
 
je doute que ce soit le raid logiciel qui utilise 50% d'UC, le monitoring s'est fait sans rien qui tourne; ni transfert de fichier... et le logiciel de monitoring des processus ne m'indique pas 50% d'util mais plutot entre 7 et 13%... prob de logiciel ?? je demanderai à des specialistes.
 
sinon quelqu'un fait tourner TC sous linux ici ? car je trouve que je perds des tonnes de go avec ext3. entre le formatage ext3 de la partoche puis de nouveau ext3 dans le container puis dans le container cache, on en bouffe pour pas grand chose... vous avez une idee pour economiser un peu ?