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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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 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 ?
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
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 wrote:
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 ?
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
<bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
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 ?
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 wrote:
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 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
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
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
-----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
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
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
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
Merci de l'info ! Je connaissais TrustedBird de nom, mais je ne m'étais jamais penché sur ce qu'il apportait...
-- Bruno Tréguier
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
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
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
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
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.
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 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
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.
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.
