Reprise du message précédent :
Normalement non.
 
Toute opération de lecture ou d'écriture se fait aussi-tôt dans le conteneur.
Après par contre il peut y avoir la présence de bug (mais pas de ce genre à ma connaissance), ou alors tu a démonté trop tôt un conteneur alors que les opérations d'écriture n'étaient pas finies.
Dernière possibilité que je voie: le support physique que tu utilise pour stocker ton conteneur a des secteurs défectueux

merci,  
 
je ne pense pas avoir démonté le conteneur trop tôt
le problème s'est posé hier - et hier j'avais remarqué un autre problème : lorsque je voulais faire une copie du container sur un autre DD (que ce soit en slave ou en usb II)
la copie était d'une lenteur telle que j'ai du arrêter
j'ai relancé la copie ce soir  et elle s'est faite normalement (environ 1 heure pour 230 go )
 
il s'agit d'un DD samsung pas trop vieux - je vais le vérifier demain

Aura-on droit un jour de mettre des "é" par exemples dans les mots de passe?

Oui c'est dommage, je me demande l'impact de l'espace des caractères sur le temps de cassage des mdp, je crois que j'avais vu passer des analyses là dessus ici.
 
Sinon vous êtes plutôt container ou partition ? J'ai un disque portable avec une partition en clair et une autre en chiffré, et Windows propose souvent de formater la partie chiffrée. Travaillant avec des clients ou des collègues à qui je peux passer le disque pour qu'il y dépose des fichiers sur la partie en clair, j'ai toujours peur qu'ils ne cliquent trop rapidement sur "Formater"...
Quels sont les impacts en performance de passer sur une seule partition en claire avec un fichier container de 250Go ?

Faites une recherche sur les message de notre cher artiflo.
Il a fait son mémoire sur TC et a fait des calcul justement sur les longueurs de mot de passe.
 
Sinon pour ce qui est de la performance entre un conteneur fichier et un autre partition...
Tu est en USB !
C'est ton facteur limitant tu peut prendre n'importe quel conteneur tu ne verra pas la différence en usb.
Après si ce serai un disque interne alors là ce cerai différent et je pense qu'en mode partition tu pourrai avoir de meilleur performances.
MAIS !
Tu oublie alors l'influence du chiffrement sur tes accès disque !
J'avais fait une mesure de performance justement sur l'influence du chiffrement et cela à pour effet de lisser les performance (à la baisse évidemment).
 
Ce qui fait qu'au final la différence de performance entre partition et fichier est quasiment négligeable.
Du moins pour les tests et essais que j'ai fait.
 
Ensuite par contre au niveau des erreurs de manipulations je préfère un conteneur fichier que partition.
Cela évite en effet de formater par erreur la partition et sur les petit volume de récupérer les fichier dans la corbeille (ou via un utilitaire si elle à été vidée). Je pense qu'il y a perso moins de risque.
 
 
 
 
 
 
EDIT:
Voila le bilant de mes tests de performance en mode OS chiffré:
http://forum.hardware.fr/forum2.ph [...] 0#t2763686
Ce n'est pas une comparaison des performances entre conteneur partition et fichier mais cela peut peut-être t'aider.

Il n'y a aucune raison que les performances varient de quoi que ce soit entre conteneur et partition. Le seul avantage que la partition peut avoir c'est si on la place au début du disque, ce qui est non trivial à faire avec un fichier. Perso j'utilise des conteneurs, même très gros. ça permet aussi de faire un backup sans l'ouvrir, en cas de besoin.

Je pensais surtout à des problèmes de fragmentation : en mode "partition", j'ai qu'un seul niveau de fragmentation, en mode "fichier", j'ai deux niveaux.

Une fois ton fichier conteneur créé sa fragmentation ne changera pas car sa taille est fixe.
Donc si tu créé (ou copie) ton fichier conteneur sur une partition "neuve" alors ton fichier ne sera pas fragmenté et ne le deviendra pas car sa taille est fixe (il n'y a pas d'ajout de données, que des modifications de clusters).
 
EDIT: asmono, faire un backup d'un conteneur sans l'ouvrir n'est valable que pour les petits conteneurs et est de plus un peut "risqué" en cas de corruption de ton header (dans ce cas ta sauvegarde est corrompue aussi).
Un petit script batch avec un robocopy est plus rapide.

J'ai une petite question pratique concernant le déni plausible que permet TC (et d'autres logiciels de chiffrement).
 
Imaginons que le conteneur chiffré fasse 1 Go et que le volume caché à l'intérieur fasse 700 Mo.
Le possesseur de l'archive chiffrée révèle sous la torture ( ) la ou les clés cryptos pour ouvrir le conteneur chiffré mais sans révéler le volume caché.  
 
Certes le volume ne peut pas être rattaché à TC en tant que tel mais j'imagine que les tortionnaires pourront très bien déduire/suspecter sa présence en comparant la taille globale du conteneur chiffré et des données déchiffrées suite à la révélation des 1ères clés, non ?
 
Dans notre cas, ils auront juste à faire la soustraction 1000-300=700 Mo pour savoir que le conteneur contient un volume caché d'environ 700 Mo ?

On ne voit pas la taille d'un volume caché a l'intérieur d'un volume normal. Le volume caché ne se voit pas du tout en fait.
 
C'est pour cela qu'il faut faire très attention quand on écris des data dans le volume normal. Elle risque d'écraser celle du volume caché. D'où la possibilité d'entrer les 2 mots de passe quand on ouvre le volume normal afin que TC nous empêche d'écrire par inadvertance sur le volume caché.

Mmm a te relire j'ai l'impression que tu dis en fait. Que quand on ouvre un conteneur toutes les data sont déchiffrés. Ce n'est absolument pas le cas ! Cela prendrait autant de temps à chaque fois que pour les chiffrer.
 
Je rappel que TC fait de l'on-the-fly encryption. C'est a dire qu'il ne déchiffre que les data que tu utilise en gardant en ram le pass.

Je me suis peut-être mal exprimé, disons que mon cas s'applique dans le cas où quelqu'un fait pression sur le créateur de l'archive chiffrée pour en obtenir les clés et ensuite les données, un cas hypothétique peut-être.

 
Le postulat est mauvais (c'est pas méchant hein), TC ne déchiffre pas tout le conteneur quand tu rentre ton mot de passe. TC ne déchiffre que les premiers octet qui contiennent la vrai clés (faut lire le PBKDF2). Et quand bien même par la suite TC ne déchiffre que les données que tu souhaite consulter (on-the-fly-encryption). Il est donc impossible de faire de soustraction.

 
Il faut créer le conteneur en taille fixe (un peu contraignant il est vrai). J'ai testé un coup avec le conteneur qui grandit au fur et à mesure du remplissage et effectivement ça fragmente à mort. Après, le chiffrement consiste de toute façon à faire du "mélange" donc quelque part tous les fichiers sont fragmentés (sur des zones proches tout de même).

Sinon, Stoned, ça marche bien, pour ouvrir une partition chifrée?

 
On doit de toute façon avoir un backup du header. Et si on a un très gros conteneur (500Go disons) et un chiffrement bourrin (serpent-aes-twofish disons), le tout sur un PC peu puissant, backuper d'un conteneur ouvert à un autre va tuer le CPU et prendre 100 ans.

Le volume caché ne peut pas faire plus de la moitié du total il me semble.

Sinon, le déni plausible est quand même relatif, si en face t'as qq1 qui connaît TC, il connaît de toute façon cette fonction. Et il me semble même que le header est à un endroit fixe donc il doit y avoir moyen de prouver qu'il est là.

Je pense que ça peut être utile aux USA quand la TSA (l'organisation qui assure la sécurité des vols) te demande le mdp, ils iront pas chercher trop loin (en fait ils ne le demanderont sûrement pas, par contre si le PC demande un mdp au boot, là oui, et on peut avoir un OS caché).

Pas forcément, j'ai un volum caché de 15go dans un container de 17go..

Lors de la première sauvegarde ou lors d'une sauvegarde complète. OR avec un robocopy (je préfère à xcopy) tu peut ne copier que les nouveau fichiers ou les fichiers modifiés et donc là hop super rapide.
 

Mais dans ce cas tu ne peut pas remplir le conteneur "normal" avec plus de 2Go de data sous peine d'écraser des data contenues dans le caché.
 

oui.
mais si j'active "protect hidden volume against damage caused by writing to outer volume", il m'en empechera, non?

A condition d'entrer le mot de passe du conteneur caché !

ça a dû changer dans une révision récente, avant je crois que c'était la moitié.

limdul : moi j'utilise SyncBack. Mais j'ai appliqué le scénario décrit quand j'étais pas chez moi, avec juste mon vieux portable.

conteneur NTFS volume caché NTFS => volume caché limité à 50% du conteneur
conteneur FAT32 volume caché NTFS => pas de limitation du volume caché

Tien, j'aurai plutôt pensé l'inverse !

c'est vrai, mon conteneur est bien fat32 et le volume caché est bien ntfs, je confirme la non-limitation.

Mon idole http://www.schneierfacts.com/facts/top

Sinon je vois que des solutions de type NAS avec processeur de chiffrement hardware AES apparaissent sur le marché (le SYNOLOGY DS211 par exemple).
 
Des gens aurait déjà testé ?

Absolument pas.
 
Et si c'est le genre de chiffrement "transparent" où quand tout est dans la configuration matérielle d'origine aucun mot de passe n'est demandé (comme le chiffrement utilisé par vista) et que le mot de passe n'est demandé que s'il y a un changement matériel je trouve pas ça top.
 
Car celons mon point de vue, au lieu de "voler" juste le disque dur et te retrouver avec un disque chiffre et inutilisable bas là tu prend le NAS complet et quand tu le branche chez toi tu accède a toutes les data en clair

Non cela ne fonctionne pas tout à fait comme cela (sinon j'en aurai même pas parlé ).
 
Selon la doc du constructeur il y a 2 mode de démarrage du NAS avec partition chiffré :
 
1 / A chaque démarrage du NAS tu dois rentrer ton mdp pour monter les partitions (Bon)
2 / Au démarrage du NAS ton mdp est automatiquement utilisé pour monté les partitions (Très mauvais, ce que tu craignais)
 
Je vais essayer de trouver quel techno ils ont employés pour le chiffrement AES.

je voulais savoir si il existe une appli comme truecript (fichier container, etc) sur plate forme android (tablettes, pc portables) ?
j'ai entendu parler de B-Folder, vous connaissez ?
http://www.androidzoom.com/android [...] c_qqj.html

à propos de la discussion récente sur la façon de backuper un conteneur, il me semble que c'est moi il y a un an ou deux qui avait dit d'utiliser un autre conteneur avec son propre mot de passe, pour des raisons de sécurité. Mais je crois qu'à l'époque je croyais que le mdp chiffrait les données, alors qu'en fait il ne chiffre que le header.
 
Mon conseil n'en reste pas moins vrai, le même mdp pour 2 headers différents reste un léger risque. Mais du coup, 1 mdp identique pour 2 headers identiques ne devrait pas poser de pb. Donc faire un premier backup en copiant le conteneur, puis les backups suivants en ouvrant les conteneurs et en mettant à jour le contenu.
 
Mon raisonnement tient la route ?
 
PS : j'ai une très mauvaise mémoire donc limiter le nombre de mdp est un avantage.

Je suis d'accord.

juste une question comme ça, la version 512b de serpent, mentionnée sur wiki ( ) existe elle/ est elle trouvable qq part?
AES ça existe en 512b?

J'ai jamais vu ni l'un ni l'autre.

Il est vrai que le même mot de passe chiffrant deux en-tête différents entrainerai une baisse de sécurité (plus un mot de passe est utilisé et plus il s'affaiblit) d'autant plus qu'en récupérant deux en-tête chiffrés avec le même mot de passe on pourrait alors surement analyser certaines différences et casser plus facilement le mot de passe.
 
La stratégie que tu donne me semble donc bonne à moi aussi.
Une première sauvegarde grâce à une copie complète du conteneur puis ensuite ouvrir les deux conteneur pour juste mettre à jour les différences.

Bonsoir,
Juste un petit mot pour ce topic qui est formidable et depuis 5ans.
Bravo à tous.

 
C'est surtout grace aux participants réguliers, merci a eux

Hello !
 
Dites, une question sans doutes bête mais bon:
 
Imaginons que j'ai créé un conteneur, avec dedans tout ce qui a de plus classique: image, vidéo, fichier genre word excel.
 
Si je monte ce conteneur, et que je consulte les images qui sont dedans.
Celle ci vont forcément se retrouver dans le cache du pc, ou le fichier d'échange, ou je ne sais pas trop quoi.
 
Alors meme si apres je démonte mon conteneur, et que les fichiers ne sont plus accessible, on doit quand meme pouvoir voir que j'ai consulter les fichiers en question non ? Dans les fichiers récents ou autre.
 
Y'a un truc que j'ai loupé ou.... ?
 

non c'est bien ça, les raccourcis seront bien conservés même si les objets pointés par ces raccourcis ne sont plus accessibles (cause conteneur démonté)
 
un petit coup de ccleaner est alors le bienvenu pour 'nettoyer'.