quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à la
fin du déchiffrement)
quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à la
fin du déchiffrement)
quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à la
fin du déchiffrement)
quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à
la
fin du déchiffrement)
quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à
la
fin du déchiffrement)
quel type de cipher recommenderiez-vous pour chiffrer et calculer un MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg à
la
fin du déchiffrement)
lorsqu'on effectue un chiffrement en CBC (3DES par exemple), on va
commencer par padder jusqu'à avoir une taille multiple de 8 octets.
Dans certains cas le padding peut même rajouter systématiquement un
bloc particulier (constant ou fonction de la longueur). A la fin du
déchiffrement CBC, on ne va retrouver le bon padding que s'il n'a pas
eu d'erreur (on a bien la bonne clé et on n'a loupé aucun bloc).
AMHA c'est déjà un moyen honorable de valider le message déchiffré,
non ?
lorsqu'on effectue un chiffrement en CBC (3DES par exemple), on va
commencer par padder jusqu'à avoir une taille multiple de 8 octets.
Dans certains cas le padding peut même rajouter systématiquement un
bloc particulier (constant ou fonction de la longueur). A la fin du
déchiffrement CBC, on ne va retrouver le bon padding que s'il n'a pas
eu d'erreur (on a bien la bonne clé et on n'a loupé aucun bloc).
AMHA c'est déjà un moyen honorable de valider le message déchiffré,
non ?
lorsqu'on effectue un chiffrement en CBC (3DES par exemple), on va
commencer par padder jusqu'à avoir une taille multiple de 8 octets.
Dans certains cas le padding peut même rajouter systématiquement un
bloc particulier (constant ou fonction de la longueur). A la fin du
déchiffrement CBC, on ne va retrouver le bon padding que s'il n'a pas
eu d'erreur (on a bien la bonne clé et on n'a loupé aucun bloc).
AMHA c'est déjà un moyen honorable de valider le message déchiffré,
non ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sylvain wrote:quel type de cipher recommenderiez-vous pour chiffrer et calculer un
MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg
à la
fin du déchiffrement)
HMAC ?
Algo de MAC base sur une fonction de hash (comme SHA-1, ou MD5 mais
moins recommande), definie par une RFC [1] comme :
Hash(clef XOR opad, Hash(clef XOR ipad, text))
(ipaq et opad etant des constantes definies par le standard)
[1] http://www.ietf.org/rfc/rfc2104.txt
HTH,
- --
clem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sylvain wrote:
quel type de cipher recommenderiez-vous pour chiffrer et calculer un
MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg
à la
fin du déchiffrement)
HMAC ?
Algo de MAC base sur une fonction de hash (comme SHA-1, ou MD5 mais
moins recommande), definie par une RFC [1] comme :
Hash(clef XOR opad, Hash(clef XOR ipad, text))
(ipaq et opad etant des constantes definies par le standard)
[1] http://www.ietf.org/rfc/rfc2104.txt
HTH,
- --
clem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sylvain wrote:quel type de cipher recommenderiez-vous pour chiffrer et calculer un
MAC,
idéalement en une seule passe ? (MAC devant garantir l'intégrité du msg
à la
fin du déchiffrement)
HMAC ?
Algo de MAC base sur une fonction de hash (comme SHA-1, ou MD5 mais
moins recommande), definie par une RFC [1] comme :
Hash(clef XOR opad, Hash(clef XOR ipad, text))
(ipaq et opad etant des constantes definies par le standard)
[1] http://www.ietf.org/rfc/rfc2104.txt
HTH,
- --
clem
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
je pourrais remplacer ce bloc signature finale par un XOR de tous les blocks
mais je traite de patterns répétitifs qui pourraient s'annuler (moins sur le
chiffré que sur le clair...), ou encore faire un classique MAC-DES3, cela
m'impose *hélas* de réaliser deux passes (paralléles ou non) avec 2 ciphers
différents; je ne peux pas non plus utiliser de hash car je ne dispose que
de 8 octets pour la signature; de plus s'agissant de code embarqué (avec un
tout petit µproc) j'espérais un moyen de faire qu'une seule passe.
d'autres pistes ?...
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
je pourrais remplacer ce bloc signature finale par un XOR de tous les blocks
mais je traite de patterns répétitifs qui pourraient s'annuler (moins sur le
chiffré que sur le clair...), ou encore faire un classique MAC-DES3, cela
m'impose *hélas* de réaliser deux passes (paralléles ou non) avec 2 ciphers
différents; je ne peux pas non plus utiliser de hash car je ne dispose que
de 8 octets pour la signature; de plus s'agissant de code embarqué (avec un
tout petit µproc) j'espérais un moyen de faire qu'une seule passe.
d'autres pistes ?...
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
je pourrais remplacer ce bloc signature finale par un XOR de tous les blocks
mais je traite de patterns répétitifs qui pourraient s'annuler (moins sur le
chiffré que sur le clair...), ou encore faire un classique MAC-DES3, cela
m'impose *hélas* de réaliser deux passes (paralléles ou non) avec 2 ciphers
différents; je ne peux pas non plus utiliser de hash car je ne dispose que
de 8 octets pour la signature; de plus s'agissant de code embarqué (avec un
tout petit µproc) j'espérais un moyen de faire qu'une seule passe.
d'autres pistes ?...
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter (..)
le hmac exigerait de plus trop de mémoire (..)
je dispose d'un DES3 et un XOR(64bits) n'est pas un problème
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter (..)
le hmac exigerait de plus trop de mémoire (..)
je dispose d'un DES3 et un XOR(64bits) n'est pas un problème
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
2) le code "chiffrant" s'exécute dans un DSP et le
code "déchiffrant" dans une carte à puce, je préfère limiter
les algos à porter (..)
le hmac exigerait de plus trop de mémoire (..)
je dispose d'un DES3 et un XOR(64bits) n'est pas un problème
François, Johann, all,
merci pour vos réponses.
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des
blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré
et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
François, Johann, all,
merci pour vos réponses.
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des
blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré
et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
François, Johann, all,
merci pour vos réponses.
j'utilise actuellement (pour le chiffrement) un DES3-CBC avec un aléa
utilisé comme IV et comme "signature" en l'insérant à la fin du clair.
je n'ai réalisé que recemment que - comme expliqué par François - des
blocs
faux au milieu du chiffré donne un clair incorrect (et dans mon cas je ne
peux pas le savoir, ie pas d'hypothèse sur le clair) uniquement pour le(s)
bloc(s) invalide(s) et le suivant (car le XOR ne porte que sur un chiffré
et
le bloc suivant).
ce "défaut" me donne une "signature" finale juste mais un message
globalement faux (avec un risque de fournir des infos à l'attaquant si je
traite son message choisi).
est-il plus judicieux d'ajouter le MAC à la fin du clair et de
le chiffrer avec lui ou de ne pas toucher au MAC et de l'ajouter
tel quel à la fin du chiffré ?
est-il plus judicieux d'ajouter le MAC à la fin du clair et de
le chiffrer avec lui ou de ne pas toucher au MAC et de l'ajouter
tel quel à la fin du chiffré ?
est-il plus judicieux d'ajouter le MAC à la fin du clair et de
le chiffrer avec lui ou de ne pas toucher au MAC et de l'ajouter
tel quel à la fin du chiffré ?
