hacher avant de crypte ou crypter avant de hacher

Le
nomail
Bonjour,

Lors d'un cours sur la sécurité des réseaux, le prof avait expliqué
les failles de sécurité qu'il pouvait exister dans l'un des deux cas
de figures et il nous avait expliqué ce qu'il convenait de faire mais
je ne m'en souviens plus. Quelqu'un pourrait-il me le dire svp ?

Est-ce qu'il vaut mieux hacher et crypter un message ensuite ou
crypter avant de hacher ?

Merci pour vos lumières
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Tréguier
Le #23541771
Le 07/07/2011 à 18:08, nomail a écrit :
Bonjour,

Lors d'un cours sur la sécurité des réseaux, le prof avait expliqué
les failles de sécurité qu'il pouvait exister dans l'un des deux cas
de figures et il nous avait expliqué ce qu'il convenait de faire mais
je ne m'en souviens plus. Quelqu'un pourrait-il me le dire svp ?

Est-ce qu'il vaut mieux hacher et crypter un message ensuite ou
crypter avant de hacher ?

Merci pour vos lumières



Bonjour,

Avant même de parler d'un éventuel problème de sécurité, j'avoue avoir
un peu de mal à imaginer en quoi résiderait l'intérêt de hacher un
message après l'avoir chiffré: la fonction de hachage ne préserve pas le
message de toute manière, il s'agit d'une "empreinte" de celui-ci...

L'inverse, en revanche, est couramment utilisé (avec de la crypto
asymétrique): on prend un message, on en calcule le hash, puis on
chiffre ce hash avec la clef privée de l'expéditeur afin d'authentifier
sa provenance.

Vous ne confondriez pas avec le fait de compresser avant ou après le
chiffrement, par hasard ?

--
Bruno Tréguier
nomail
Le #23542431
Bonsoir,

non non, il s'agit bien du probleme chiffrer puis signer ou signer
puis chiffrer mais vous avez raison, je confond avec les fonctions de
hachage qui vérifie l'intégrité, désolé, je me suis mal exprimé.

En fait, le problème est : vaut-il mieux signer puis chiffrer ou
chiffrer puis signer...


Voila,

Désolé pour la méprise

On Thu, 07 Jul 2011 20:51:00 +0200, Bruno Tréguier

Le 07/07/2011 à 18:08, nomail a écrit :
Bonjour,

Lors d'un cours sur la sécurité des réseaux, le prof avait expliqué
les failles de sécurité qu'il pouvait exister dans l'un des deux cas
de figures et il nous avait expliqué ce qu'il convenait de faire mais
je ne m'en souviens plus. Quelqu'un pourrait-il me le dire svp ?

Est-ce qu'il vaut mieux hacher et crypter un message ensuite ou
crypter avant de hacher ?

Merci pour vos lumières



Bonjour,

Avant même de parler d'un éventuel problème de sécurité, j'avoue avoir
un peu de mal à imaginer en quoi résiderait l'intérêt de hacher un
message après l'avoir chiffré: la fonction de hachage ne préserve pas le
message de toute manière, il s'agit d'une "empreinte" de celui-ci...

L'inverse, en revanche, est couramment utilisé (avec de la crypto
asymétrique): on prend un message, on en calcule le hash, puis on
chiffre ce hash avec la clef privée de l'expéditeur afin d'authentifier
sa provenance.

Vous ne confondriez pas avec le fait de compresser avant ou après le
chiffrement, par hasard ?
Bruno Tréguier
Le #23547361
Le 08/07/2011 04:49, nomail a écrit :
Bonsoir,

non non, il s'agit bien du probleme chiffrer puis signer ou signer
puis chiffrer mais vous avez raison, je confond avec les fonctions de
hachage qui vérifie l'intégrité, désolé, je me suis mal exprimé.



Yapadmal. ;-)


En fait, le problème est : vaut-il mieux signer puis chiffrer ou
chiffrer puis signer...



La question est intéressante, effectivement... On trouve beaucoup de
références disant disant que la pratique courante est de signer, puis de
chiffrer. En crypto asymétrique, cela veut dire:

1) Alice, l'expéditrice, chiffre le message avec sa clef privée
2) Alice chiffre ensuite le résultat de l'étape 1) avec la clef publique
de Bob, le destinataire.

En réalité c'est un peu plus compliqué car on n'utilise jamais de la
crypto asymétrique toute seule pour chiffrer la totalité d'un message
(c'est très lent). Dans les faits, on utilise en plus un algo symétrique
et une clef de session choisie aléatoirement (et à usage unique), avec
laquelle on va chiffrer le message envoyé, et c'est cette clef de
session qui, ensuite, sera chiffrée avec la clef publique du
destinataire et envoyée avec le message, mais bon, a priori ça ne change
rien au principe ci-dessus.

Le souci principal, quand on fait les opérations dans cet ordre, c'est
qu'ensuite, Bob peut très bien renvoyer le message à un autre
destinataire, disons Charlie, en faisant croire que c'est Alice qui le
lui a directement envoyé. En effet: il suffit à Bob de déchiffrer le
message de Alice avec sa clef privée, pour le récupérer le message signé
par elle. Il peut bien entendu prendre connaissance du message en le
déchiffrant avec la clef publique de Alice, mais il dispose toujours de
la forme signée, et peut donc sans aucun souci usurper l'identité de
Alice, et renvoyer le message à Charlie en le chiffrant avec la clef
publique de Charlie.

Charlie peut donc légitimement croire que Alice lui a directement envoyé
le message puisque c'est elle qui l'a signé... Il pourrait donc en
déduire que Alice et lui sont les seuls au courant du contenu de ce
message... Sauf que Bob en a aussi connaissance !


Dans l'autre sens (on chiffre d'abord et on signe après), les choses
pourraient sembler plus sûres a priori, mais on n'est pas sauvés pour
autant: il n'y a aucun moyen de certifier, dans un tel cas, que
l'expéditeur connaît le texte qu'il a signé, puisqu'il a été chiffré
avant... Bon, vous me direz, il prend ses responsabilités, ok, mais
juridiquement, ça peut quand-même poser un probème (les affaires de non
répudiation et tout ça).

Il y a aussi d'autres problèmes liés à des aspects beaucoup plus
techniques, qui permettent, dans certains cas, de "forger" une signature
sur un message totalement différent de l'original, c'est décrit ici:
http://www.cl.cam.ac.uk/~rja14/Papers/robustness.pdf (mais attention,
c'est très technique et en anglais).

En gros, pour être un peu plus sûr de la confidentialité et de
l'authenticité d'un message, il faudrait faire un "sandwich": signer,
chiffrer, puis re-signer, ou l'inverse: chiffrer, signer, puis
re-chiffrer. ;-)

Voir là également: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps

--
Bruno Tréguier
Aéris
Le #23547441
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 09/07/2011 12:17, Bruno Tréguier a écrit :
En gros, pour être un peu plus sûr de la confidentialité et de
l'authenticité d'un message, il faudrait faire un "sandwich": signer,
chiffrer, puis re-signer, ou l'inverse: chiffrer, signer, puis
re-chiffrer. ;-)



C'est d'ailleurs ce que fait TrustedBird, le module de sécurité pour
Thunderbird développé par la Gendarmerie Nationale :
? Encryption/Signing with triple wrapping

http://adullact.net/plugins/mediawiki/wiki/milimail/index.php/Triple_Wrapping

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOGDJQAAoJEK8zQvxDY4P9r5gIAKgxM6jsnHkWveq+M8XgFPIp
ozTEyOyfDhKIZdW+WInkau6iRwbocQV+i0CypxVvJAQQDCDe+7bR+HrPBKhoAyy9
9n9ghY37DazDE8YIzrjTr+RviRI+hZA0XcLaP2Mc36kdeLqLXXDdihofFNltcApv
t5HPd20rLHEV6KItOiUxYekXkIcw5gTm/3FnRViFEK+DiRAxEoOo2qeYcF0K8YYj
U3dGp84LwsApN/S13HsEmHYRl3431CbqTWUhJS2EfSB9l3sx/WCWX6Jtn3x6cBE+
/X4Srh5Vm2GXVmzislIW4aUifNSW9A7hsAyF9mN+sWCem9X1CQIeri4JPhptsnQ =pQ6W
-----END PGP SIGNATURE-----
Bruno Tréguier
Le #23547431
Le 09/07/2011 à 12:49, Aéris a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 09/07/2011 12:17, Bruno Tréguier a écrit :
En gros, pour être un peu plus sûr de la confidentialité et de
l'authenticité d'un message, il faudrait faire un "sandwich": signer,
chiffrer, puis re-signer, ou l'inverse: chiffrer, signer, puis
re-chiffrer. ;-)



C'est d'ailleurs ce que fait TrustedBird, le module de sécurité pour
Thunderbird développé par la Gendarmerie Nationale :
? Encryption/Signing with triple wrapping

http://adullact.net/plugins/mediawiki/wiki/milimail/index.php/Triple_Wrapping



Merci de l'info ! Je connaissais TrustedBird de nom, mais je ne m'étais
jamais penché sur ce qu'il apportait...

--
Bruno Tréguier
nomail
Le #23551871
Bonsoir,

Merci beaucoup d'avoir pris le temps de répondre.

Je viens de rentrer de week-end et je me penche des demain matin sur
votre réponse et je me permettrai de vous poser quelques questions si
j'en ai et dans le cas où vous auriez un peu de temps pour y répondre.


Merci encore
Bruno Tréguier
Le #23552041
Le 11/07/2011 02:54, nomail a écrit :
Bonsoir,

Merci beaucoup d'avoir pris le temps de répondre.

Je viens de rentrer de week-end et je me penche des demain matin sur
votre réponse et je me permettrai de vous poser quelques questions si
j'en ai et dans le cas où vous auriez un peu de temps pour y répondre.


Merci encore



Aucun problème, mais ne perdez pas de vue le fait que je ne suis pas un
spécialiste de la crypto, ce n'est pour moi qu'un outil parmi d'autres
dans le domaine de la sécurité, il n'est donc pas dit que je puisse
répondre à toutes vos interrogations. Cela dit il y a d'autres
intervenants réguliers ici qui s'y connaissent bien, et vous avez aussi
le newsgrpoup fr.misc.cryptologie à votre disposition si vous le souhaitez.

--
Bruno Tréguier
Publicité
Poster une réponse
Anonyme