décryptage fichiers

Jean-Claude BELLAMY

13/11/2007 à 14:59

"Gump" a écrit dans le message de
news:47397fb1$0$5066$

|
| Le mot de passe en clair n'est évidemment écrit nulle part, ni dans
| TrueCrypt ni dans Windows, MAIS il y a FORCÉMENT quelque chose qui est
| stocké, à savoir le résultat d'une fonction mathématique (fonction de
| hachage).

Non, pas pour TrueCrypt !
Siiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii !

C'est O-BLI-GA-TOI-RE !
Mathématique !

| Et comme j'ai l'impression que tu n'es pas très au courant de ce que
désigne
| le hachage (il n'y a pasde honte à çà), un petit rappel ne fera pas de
mal !

Mais si, mais si, je connais.
Et bien çà servira aux autres ! ;-)

| Si bien qu'on va se servir du hachage pour :
| - stocker des mots de passe

Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
l'empreinte
de hachage.
NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!

Il ne stocke pas l'empreinte "brute de fonderie", mais il la stocke quand
même !

Si le password est "Gump", cela donne, en SHA1 :
4AB5 4C4B B7D6 4223 29C7 ABC0 C849 3E4B 4B29 6C85

On PEUT ne pas le stocker tel quel, mais (p.ex.) au travers d'un "NOT"
B54A B3B4 4829 BDDC D638 543F 37B6 C1B4 B4D6 937A

Un hachage du password réside dans les 512 1ers octets du fichier TC.

La validation du mot de passe se fait autrement : voir l'aide du
logiciel qui explique cela très bien. J'ai cru pendant longtemps que le
logiciel
comparait l'empreinte du pass que l'on tape avec celle qu'il aurait
stockée. En
fait ça fonctionne autrement : on teste le mot de passe, c'est-à-dire
qu'on le fait
travailler,
?????????????????????????????????

Tu peux m'expliquer çà, un "mot de passe qui travaille" ? ;-)

on lui demande de déchiffrer une bloc spécifique

...qui ne peut être que dans le fichier chiffré, sinon çà n'aurait aucun
sens !

et on examine le résultat,
si le résultat n'est pas conforme à ce qui est attendu, le pass est
recalé.

Mais çà se fait FORCÉMENT avec quelque chose stocké dans le fichier chiffré
!
Réfléchis un peu !
A ce moment là, comment pourrait-on ouvrir 2 fichiers TC chiffrés par
TrueCrypt avec 2 password différents ?

Tu n'as qu'à faire comme moi :

1) Crée un disque virtuel TC, nommé p.ex. "DV1.tc",
en lui attribuant un password P1
2) Monte "DV1.tc"
3) Insère dans ce DV un fichier quelconque
(dans un but de vérification utlérieure)
4) Démonte "DV1.tc"
5) Copie le fichier "DV1.tc" sous le nom "DV2.tc"
(les noms importent peu, il suffit qu'ils soient différents)
6) Sélectionne ce fichier DV2.tc dans TrueCrypt
7) Appuie sur "Volume Tools"/"Change Volume Password"
8) Définis un nouveau password P2
9) Monte "DV2.tc", et vérifie que tu retrouve bien
dedans le fichier inséré au point 3
10) Démonte "DV2.tc"
11) Compare les 2 fichiers DV1.tc et DV2.tc avec
un éditeur hexadécimal (p.ex. "Hex Workshop")
12) Tu constateras alors que seuls les octets compris
entre les offsets 0x000000000 et 0x0000001FF
diffèrent, tout le reste étant IDENTIQUE.

13) Copie le fichier "DV1.tc" sous le nom "DV3.tc"
14) Sélectionne ce fichier "DV3.tc" dans TrueCrypt
15) Monte "DV3.tc",
16) Modifie le fichier inséré en 3
17) Démonte "DV3.tc"
18) Compare les 2 fichiers DV1.tc et DV3.tc avec
un éditeur hexadécimal
19) Tu constateras alors que les octets compris
entre les offsets 0x000000000 et 0x0000001FF
sont toujours les mêmes, et seuls quelques octets
diffèrent, loins dans les fichiers (cela dépend
évidemment de l'ampleur de modifs du fichier inséré,
et de la taille des disques virtuels)
p.ex. chez moi je vois 16 octets différents 2 fois
de suite, à l'offset 0x00014690 et 0x00018A00

De ces expériences on en déduit que les 512 1ers octets varient UNIQUEMENT
en fonction du mot de passe affecté au DV, puisque :
- une modif de pwd modifie ces 512 octets
mais ne touche pas au reste du DV
- une modif du contenu logique du DV ne
touche pas à ces 512 1ers octets.

Et je viens de voir que mes propos sont confirmés par :

http://www.truecrypt.org/docs/?s=volume-format-specification
http://www.truecrypt.org/docs/?s=encryption-scheme

Donc je persiste et signe à AFFIRMER qu'un résultat de fonction du password
(même si ce n'est pas stricto sensu l'empreinte directe issue de SHA 1 ou
autre algorithme de hachage).
Et c'est LOGIQUE !

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

"Gump" <gump@free.fr> a écrit dans le message de
news:47397fb1$0$5066$ba4acef3@news.orange.fr...

|
| Le mot de passe en clair n'est évidemment écrit nulle part, ni dans
| TrueCrypt ni dans Windows, MAIS il y a FORCÉMENT quelque chose qui est
| stocké, à savoir le résultat d'une fonction mathématique (fonction de
| hachage).

Non, pas pour TrueCrypt !
Siiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii !

C'est O-BLI-GA-TOI-RE !
Mathématique !

| Et comme j'ai l'impression que tu n'es pas très au courant de ce que
désigne
| le hachage (il n'y a pasde honte à çà), un petit rappel ne fera pas de
mal !

Mais si, mais si, je connais.
Et bien çà servira aux autres ! ;-)

| Si bien qu'on va se servir du hachage pour :
| - stocker des mots de passe

Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
l'empreinte
de hachage.
NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!

Il ne stocke pas l'empreinte "brute de fonderie", mais il la stocke quand
même !

Si le password est "Gump", cela donne, en SHA1 :
4AB5 4C4B B7D6 4223 29C7 ABC0 C849 3E4B 4B29 6C85

On PEUT ne pas le stocker tel quel, mais (p.ex.) au travers d'un "NOT"
B54A B3B4 4829 BDDC D638 543F 37B6 C1B4 B4D6 937A

Un hachage du password réside dans les 512 1ers octets du fichier TC.

La validation du mot de passe se fait autrement : voir l'aide du
logiciel qui explique cela très bien. J'ai cru pendant longtemps que le
logiciel
comparait l'empreinte du pass que l'on tape avec celle qu'il aurait
stockée. En
fait ça fonctionne autrement : on teste le mot de passe, c'est-à-dire
qu'on le fait
travailler,
?????????????????????????????????

Tu peux m'expliquer çà, un "mot de passe qui travaille" ? ;-)

on lui demande de déchiffrer une bloc spécifique

...qui ne peut être que dans le fichier chiffré, sinon çà n'aurait aucun
sens !

et on examine le résultat,
si le résultat n'est pas conforme à ce qui est attendu, le pass est
recalé.

Mais çà se fait FORCÉMENT avec quelque chose stocké dans le fichier chiffré
!
Réfléchis un peu !
A ce moment là, comment pourrait-on ouvrir 2 fichiers TC chiffrés par
TrueCrypt avec 2 password différents ?

Tu n'as qu'à faire comme moi :

1) Crée un disque virtuel TC, nommé p.ex. "DV1.tc",
en lui attribuant un password P1
2) Monte "DV1.tc"
3) Insère dans ce DV un fichier quelconque
(dans un but de vérification utlérieure)
4) Démonte "DV1.tc"
5) Copie le fichier "DV1.tc" sous le nom "DV2.tc"
(les noms importent peu, il suffit qu'ils soient différents)
6) Sélectionne ce fichier DV2.tc dans TrueCrypt
7) Appuie sur "Volume Tools"/"Change Volume Password"
8) Définis un nouveau password P2
9) Monte "DV2.tc", et vérifie que tu retrouve bien
dedans le fichier inséré au point 3
10) Démonte "DV2.tc"
11) Compare les 2 fichiers DV1.tc et DV2.tc avec
un éditeur hexadécimal (p.ex. "Hex Workshop")
12) Tu constateras alors que seuls les octets compris
entre les offsets 0x000000000 et 0x0000001FF
diffèrent, tout le reste étant IDENTIQUE.

13) Copie le fichier "DV1.tc" sous le nom "DV3.tc"
14) Sélectionne ce fichier "DV3.tc" dans TrueCrypt
15) Monte "DV3.tc",
16) Modifie le fichier inséré en 3
17) Démonte "DV3.tc"
18) Compare les 2 fichiers DV1.tc et DV3.tc avec
un éditeur hexadécimal
19) Tu constateras alors que les octets compris
entre les offsets 0x000000000 et 0x0000001FF
sont toujours les mêmes, et seuls quelques octets
diffèrent, loins dans les fichiers (cela dépend
évidemment de l'ampleur de modifs du fichier inséré,
et de la taille des disques virtuels)
p.ex. chez moi je vois 16 octets différents 2 fois
de suite, à l'offset 0x00014690 et 0x00018A00

De ces expériences on en déduit que les 512 1ers octets varient UNIQUEMENT
en fonction du mot de passe affecté au DV, puisque :
- une modif de pwd modifie ces 512 octets
mais ne touche pas au reste du DV
- une modif du contenu logique du DV ne
touche pas à ces 512 1ers octets.

Et je viens de voir que mes propos sont confirmés par :

http://www.truecrypt.org/docs/?s=volume-format-specification
http://www.truecrypt.org/docs/?s=encryption-scheme

Donc je persiste et signe à AFFIRMER qu'un résultat de fonction du password
(même si ce n'est pas stricto sensu l'empreinte directe issue de SHA 1 ou
autre algorithme de hachage).
Et c'est LOGIQUE !

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Vous avez filtré cet utilisateur ! Consultez son message

"Gump" a écrit dans le message de
news:47397fb1$0$5066$

|
| Le mot de passe en clair n'est évidemment écrit nulle part, ni dans
| TrueCrypt ni dans Windows, MAIS il y a FORCÉMENT quelque chose qui est
| stocké, à savoir le résultat d'une fonction mathématique (fonction de
| hachage).

Non, pas pour TrueCrypt !
Siiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii !

C'est O-BLI-GA-TOI-RE !
Mathématique !

| Et comme j'ai l'impression que tu n'es pas très au courant de ce que
désigne
| le hachage (il n'y a pasde honte à çà), un petit rappel ne fera pas de
mal !

Mais si, mais si, je connais.
Et bien çà servira aux autres ! ;-)

| Si bien qu'on va se servir du hachage pour :
| - stocker des mots de passe

Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
l'empreinte
de hachage.
NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!

Il ne stocke pas l'empreinte "brute de fonderie", mais il la stocke quand
même !

Si le password est "Gump", cela donne, en SHA1 :
4AB5 4C4B B7D6 4223 29C7 ABC0 C849 3E4B 4B29 6C85

On PEUT ne pas le stocker tel quel, mais (p.ex.) au travers d'un "NOT"
B54A B3B4 4829 BDDC D638 543F 37B6 C1B4 B4D6 937A

Un hachage du password réside dans les 512 1ers octets du fichier TC.

La validation du mot de passe se fait autrement : voir l'aide du
logiciel qui explique cela très bien. J'ai cru pendant longtemps que le
logiciel
comparait l'empreinte du pass que l'on tape avec celle qu'il aurait
stockée. En
fait ça fonctionne autrement : on teste le mot de passe, c'est-à-dire
qu'on le fait
travailler,
?????????????????????????????????

Tu peux m'expliquer çà, un "mot de passe qui travaille" ? ;-)

on lui demande de déchiffrer une bloc spécifique

...qui ne peut être que dans le fichier chiffré, sinon çà n'aurait aucun
sens !

et on examine le résultat,
si le résultat n'est pas conforme à ce qui est attendu, le pass est
recalé.

Mais çà se fait FORCÉMENT avec quelque chose stocké dans le fichier chiffré
!
Réfléchis un peu !
A ce moment là, comment pourrait-on ouvrir 2 fichiers TC chiffrés par
TrueCrypt avec 2 password différents ?

Tu n'as qu'à faire comme moi :

1) Crée un disque virtuel TC, nommé p.ex. "DV1.tc",
en lui attribuant un password P1
2) Monte "DV1.tc"
3) Insère dans ce DV un fichier quelconque
(dans un but de vérification utlérieure)
4) Démonte "DV1.tc"
5) Copie le fichier "DV1.tc" sous le nom "DV2.tc"
(les noms importent peu, il suffit qu'ils soient différents)
6) Sélectionne ce fichier DV2.tc dans TrueCrypt
7) Appuie sur "Volume Tools"/"Change Volume Password"
8) Définis un nouveau password P2
9) Monte "DV2.tc", et vérifie que tu retrouve bien
dedans le fichier inséré au point 3
10) Démonte "DV2.tc"
11) Compare les 2 fichiers DV1.tc et DV2.tc avec
un éditeur hexadécimal (p.ex. "Hex Workshop")
12) Tu constateras alors que seuls les octets compris
entre les offsets 0x000000000 et 0x0000001FF
diffèrent, tout le reste étant IDENTIQUE.

13) Copie le fichier "DV1.tc" sous le nom "DV3.tc"
14) Sélectionne ce fichier "DV3.tc" dans TrueCrypt
15) Monte "DV3.tc",
16) Modifie le fichier inséré en 3
17) Démonte "DV3.tc"
18) Compare les 2 fichiers DV1.tc et DV3.tc avec
un éditeur hexadécimal
19) Tu constateras alors que les octets compris
entre les offsets 0x000000000 et 0x0000001FF
sont toujours les mêmes, et seuls quelques octets
diffèrent, loins dans les fichiers (cela dépend
évidemment de l'ampleur de modifs du fichier inséré,
et de la taille des disques virtuels)
p.ex. chez moi je vois 16 octets différents 2 fois
de suite, à l'offset 0x00014690 et 0x00018A00

De ces expériences on en déduit que les 512 1ers octets varient UNIQUEMENT
en fonction du mot de passe affecté au DV, puisque :
- une modif de pwd modifie ces 512 octets
mais ne touche pas au reste du DV
- une modif du contenu logique du DV ne
touche pas à ces 512 1ers octets.

Et je viens de voir que mes propos sont confirmés par :

http://www.truecrypt.org/docs/?s=volume-format-specification
http://www.truecrypt.org/docs/?s=encryption-scheme

Donc je persiste et signe à AFFIRMER qu'un résultat de fonction du password
(même si ce n'est pas stricto sensu l'empreinte directe issue de SHA 1 ou
autre algorithme de hachage).
Et c'est LOGIQUE !

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Gump

13/11/2007 à 22:22

| > Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
| > l'empreinte
| > de hachage.
| NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!
|

Il va falloir des boules Quiès pour te lire, bientôt !

Il se peut tout à fait que tu aies raison, bien entendu : ça s'est déjà vu ;-)
Je me replongerai là-dedans quand j'aurai le temps.

Cependant, voici un extrait de la FAQ officielle :

Q: Is some hash of my password stored somewhere?

A: No.

Q: How does TrueCrypt verify that the correct password was entered?

See the section Encryption Scheme (chapter Technical Details) in the documentation.

Je me demande si tu ne déduis pas trop vite lorsque tu affirmes :

"De ces expériences on en déduit que les 512 1ers octets varient UNIQUEMENT
en fonction du mot de passe affecté au DV, puisque :
- une modif de pwd modifie ces 512 octets
mais ne touche pas au reste du DV
- une modif du contenu logique du DV ne
touche pas à ces 512 1ers octets."

Cela ne veut pas forcément dire que ces 512 premiers octets ( jusqu'au 1FF, donc )

contiennent un hash ou un hash modifié du password ! Peut-être que lorsqu'on change

le passw, ce premier secteur est tout simplement réencodé avec le nouveau pass.

Mais bon, je ne suis évidemment sûr de rien.

D'autre part, si l'on regarde le premier tableau de la page que tu signales :

http://www.truecrypt.org/docs/?s=volume-format-specification

soit le détail des 512 premiers offsets, on n'y voit absolument pas qu'il renferme

quelque trace que ce soit du password.

Gump

14/11/2007 à 00:09

| > Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
| > l'empreinte
| > de hachage.
| NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!
|

Il va falloir des boules Quiès pour te lire, bientôt !

Il se peut tout à fait que tu aies raison, bien entendu : ça s'est déjà vu ;-)
Je me replongerai là-dedans quand j'aurai le temps.

Cependant, voici un extrait de la FAQ officielle :

Q: Is some hash of my password stored somewhere?

A: No.

Q: How does TrueCrypt verify that the correct password was entered?

See the section Encryption Scheme (chapter Technical Details) in the documentation.

Je te crois sur parole quant à tes expériences sur les containers.
Je me demande si tu ne déduis pas trop vite lorsque tu affirmes :

"De ces expériences on en déduit que les 512 1ers octets varient UNIQUEMENT
en fonction du mot de passe affecté au DV, puisque :
- une modif de pwd modifie ces 512 octets
mais ne touche pas au reste du DV
- une modif du contenu logique du DV ne
touche pas à ces 512 1ers octets."

Cela ne veut pas forcément dire que ces 512 premiers octets ( jusqu'au 1FF, donc )

contiennent un hash ou un hash modifié du password ! Peut-être que lorsqu'on change

le passw, ce premier secteur est tout simplement réencodé avec le nouveau pass.

Mais bon, je ne suis évidemment sûr de rien.

D'autre part, si l'on regarde le premier tableau de la page que tu signales :

http://www.truecrypt.org/docs/?s=volume-format-specification

soit le détail des 512 premiers offsets, on n'y voit absolument pas qu'il renferme

quelque trace que ce soit du password.

Gump

14/11/2007 à 00:12

Oups ! message envoyé deux fois suite à plantage de ma ligne téléphonique
pendant près de 2 heures...Je l'ai reécrit mais il avait quand même
été envoyé : Merci FT !

Gump

Roger LEDIG

14/11/2007 à 09:29

Bonjour

Encore le bons sens, Un ordinateur, n'est jamais sur, pour garder un vrai
secret.

Le cryptage sert essentiellement aux transmissions, et seule le possesseurs
clé privé peut l'ouvrir, donc cette clé doit pouvoir se transmettre.

Ce Gump est aussi de mauvaise foi.

Cordialement

Roger

"Gump" a écrit dans le message de groupe de discussion :
473a2f68$0$5101$

Oups ! message envoyé deux fois suite à plantage de ma ligne téléphonique
pendant près de 2 heures...Je l'ai reécrit mais il avait quand même
été envoyé : Merci FT !

Gump

Jean-Claude BELLAMY

14/11/2007 à 09:54

"Gump" a écrit dans le message de
news:473a2eb7$0$5085$

| > Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
| > l'empreinte
| > de hachage.
| NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!
|

Il va falloir des boules Quiès pour te lire, bientôt !
;-)

Il se peut tout à fait que tu aies raison, bien entendu : ça s'est déjà vu
;-)
Je me replongerai là-dedans quand j'aurai le temps.
Cependant, voici un extrait de la FAQ officielle :
Q: Is some hash of my password stored somewhere?
A: No.

Oui, j'ai lu moi-aussi !
Et relis ce que j'ai écrit précédemment, à savoir que le hash DIRECT du
password n'est pas stocké TEL QUEL, mais à l'aide de subtiles
transformations, une fonction (au sens mathématique) du password est stockée
dans les 512 1ers octets.

La FAQ de TrueCrypt joue sur les mots avec ce "no" !

Q: How does TrueCrypt verify that the correct password was entered?
See the section Encryption Scheme (chapter Technical Details) in the
documentation.

J'ai lu aussi ...

[...]
D'autre part, si l'on regarde le premier tableau de la page que tu
signales :

http://www.truecrypt.org/docs/?s=volume-format-specification

soit le détail des 512 premiers offsets, on n'y voit absolument pas qu'il
renferme
quelque trace que ce soit du password.
Du password directement, non, bien sûr.

Mais il réside dans ces 512 octets une fonction du password, et c'est
INCONTOURNABLE.

Ce que je conteste dans tes propos, c'est quand tu déclares que TrueCrypt
est supérieur à EFS parce qu'il n'y a rien émanant du password dans un
fichier "truecrypté".

Au niveau du détail, TrueCrypt et EFS certes diffèrent, mais dans le
principe, ils sont strictement analogues.

Dans EFS, l'empreinte SHA1 du password du compte en cours ne figure pas
TELLE QUELLE dans le fichier contenant la clef privée
(%userprofile%Application DataMicrosoftCryptoRSA), puisque cette clef
est chiffrée avec une clef de session dérivée d'une clef "maître" de 512
bits générée par hachage HMAC et SHA1 à partir du mot de passe du compte
utilisateur (ouf!)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

"Gump" <gump@free.fr> a écrit dans le message de
news:473a2eb7$0$5085$ba4acef3@news.orange.fr...

| > Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
| > l'empreinte
| > de hachage.
| NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!
|

Il va falloir des boules Quiès pour te lire, bientôt !
;-)

Il se peut tout à fait que tu aies raison, bien entendu : ça s'est déjà vu
;-)
Je me replongerai là-dedans quand j'aurai le temps.
Cependant, voici un extrait de la FAQ officielle :
Q: Is some hash of my password stored somewhere?
A: No.

Oui, j'ai lu moi-aussi !
Et relis ce que j'ai écrit précédemment, à savoir que le hash DIRECT du
password n'est pas stocké TEL QUEL, mais à l'aide de subtiles
transformations, une fonction (au sens mathématique) du password est stockée
dans les 512 1ers octets.

La FAQ de TrueCrypt joue sur les mots avec ce "no" !

Q: How does TrueCrypt verify that the correct password was entered?
See the section Encryption Scheme (chapter Technical Details) in the
documentation.

J'ai lu aussi ...

[...]
D'autre part, si l'on regarde le premier tableau de la page que tu
signales :

http://www.truecrypt.org/docs/?s=volume-format-specification

soit le détail des 512 premiers offsets, on n'y voit absolument pas qu'il
renferme
quelque trace que ce soit du password.
Du password directement, non, bien sûr.

Mais il réside dans ces 512 octets une fonction du password, et c'est
INCONTOURNABLE.

Ce que je conteste dans tes propos, c'est quand tu déclares que TrueCrypt
est supérieur à EFS parce qu'il n'y a rien émanant du password dans un
fichier "truecrypté".

Au niveau du détail, TrueCrypt et EFS certes diffèrent, mais dans le
principe, ils sont strictement analogues.

Dans EFS, l'empreinte SHA1 du password du compte en cours ne figure pas
TELLE QUELLE dans le fichier contenant la clef privée
(%userprofile%Application DataMicrosoftCryptoRSA), puisque cette clef
est chiffrée avec une clef de session dérivée d'une clef "maître" de 512
bits générée par hachage HMAC et SHA1 à partir du mot de passe du compte
utilisateur (ouf!)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Vous avez filtré cet utilisateur ! Consultez son message

"Gump" a écrit dans le message de
news:473a2eb7$0$5085$

| > Et bien, non, justement pas pour TrueCrypt : il ne stocke même pas
| > l'empreinte
| > de hachage.
| NANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN !!!!
|

Il va falloir des boules Quiès pour te lire, bientôt !
;-)

Il se peut tout à fait que tu aies raison, bien entendu : ça s'est déjà vu
;-)
Je me replongerai là-dedans quand j'aurai le temps.
Cependant, voici un extrait de la FAQ officielle :
Q: Is some hash of my password stored somewhere?
A: No.

Oui, j'ai lu moi-aussi !
Et relis ce que j'ai écrit précédemment, à savoir que le hash DIRECT du
password n'est pas stocké TEL QUEL, mais à l'aide de subtiles
transformations, une fonction (au sens mathématique) du password est stockée
dans les 512 1ers octets.

La FAQ de TrueCrypt joue sur les mots avec ce "no" !

Q: How does TrueCrypt verify that the correct password was entered?
See the section Encryption Scheme (chapter Technical Details) in the
documentation.

J'ai lu aussi ...

[...]
D'autre part, si l'on regarde le premier tableau de la page que tu
signales :

http://www.truecrypt.org/docs/?s=volume-format-specification

soit le détail des 512 premiers offsets, on n'y voit absolument pas qu'il
renferme
quelque trace que ce soit du password.
Du password directement, non, bien sûr.

Mais il réside dans ces 512 octets une fonction du password, et c'est
INCONTOURNABLE.

Ce que je conteste dans tes propos, c'est quand tu déclares que TrueCrypt
est supérieur à EFS parce qu'il n'y a rien émanant du password dans un
fichier "truecrypté".

Au niveau du détail, TrueCrypt et EFS certes diffèrent, mais dans le
principe, ils sont strictement analogues.

Dans EFS, l'empreinte SHA1 du password du compte en cours ne figure pas
TELLE QUELLE dans le fichier contenant la clef privée
(%userprofile%Application DataMicrosoftCryptoRSA), puisque cette clef
est chiffrée avec une clef de session dérivée d'une clef "maître" de 512
bits générée par hachage HMAC et SHA1 à partir du mot de passe du compte
utilisateur (ouf!)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Gump

14/11/2007 à 12:20

|
| Ce Gump est aussi de mauvaise foi.
|
| Cordialement
|

??? Tu pourrais développer ? En quoi suis-je "de mauvaise foi "??
Nous parlons de questions techniques concernant les logiciels ou
systèmes de chiffrement, tu peux expliquer où tu vois de la mauvaise foi ?
Je veux bien qu'on critique mais prière d'argumenter, c'est le minimum !

Gump

Alain Naigeon

14/11/2007 à 20:41

"Roger LEDIG" a écrit dans le message de news:

Bonjour

Encore le bons sens, Un ordinateur, n'est jamais sur, pour garder un vrai
secret.

Le cryptage sert essentiellement aux transmissions, et seule le
possesseurs clé privé peut l'ouvrir, donc cette clé doit pouvoir se
transmettre.

Ok, mais l'idée du paillasson ou du pot de géraniums est peu simpliste :-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France

décryptage fichiers

8 réponses

Veuillez sélectionner un problème