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)
le hash (ou hmac) n'est pas applicable 1) je n'ai pas la place de l'insérer dans ma trame d'échange
S'il y a déjà une place pour un MAC, rien n'empêche de tronquer le résultat de HMAC à la taille disponible.
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
Un MAC à base de DES(3) semble indiqué, sauf problème de temps machine. Sur ce plan, si le DES est triple ET en soft du/des côtés qui manque(nt) de temps, il est probable que lusage de DESX, qui est presque 3 fois plus rapide que DES3, est la meilleure solution. Voir la fin de de mon autre post
Mais dans/avec de nombreuses cartes à puce et/ou DES en hardware, simple DES est à peine moins couteux que triple DES, et la pas de miracle.
François Grieu
coté carte, l'implémentation est en effet matériel avec un temps de (à la louche) 1 ms / octet; le traitement d'une trame rajoute 1/4 de sec. c'est acceptable si c'est la meilleure solution, code DSP c'est en soft mais ça tourne plus vite avec un rendement a peut près comparable; le problème viendrait malgré tout de cette 1/2 sec. dans un process qui ne devrait pas dépasser la seconde.
le DESX coté soft serait une bonne solution ... mais n'est pas cablé coté carte ... évidemment.
Sylvain.
"Francois Grieu" <fgrieu@francenet.fr> a écrit dans le message de news:
fgrieu-D5D1EE.10510110112004@individual.net...
"Sylvain" dit:
le hash (ou hmac) n'est pas applicable
1) je n'ai pas la place de l'insérer dans ma trame d'échange
S'il y a déjà une place pour un MAC, rien n'empêche de tronquer
le résultat de HMAC à la taille disponible.
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
Un MAC à base de DES(3) semble indiqué, sauf problème de temps
machine. Sur ce plan, si le DES est triple ET en soft du/des
côtés qui manque(nt) de temps, il est probable que lusage de DESX,
qui est presque 3 fois plus rapide que DES3, est la meilleure
solution. Voir la fin de de mon autre post
<fgrieu-2E2440.08413910112004@individual.net>
Mais dans/avec de nombreuses cartes à puce et/ou DES en hardware,
simple DES est à peine moins couteux que triple DES, et la pas
de miracle.
François Grieu
coté carte, l'implémentation est en effet matériel avec un temps de (à la
louche) 1 ms / octet; le traitement d'une trame rajoute 1/4 de sec. c'est
acceptable si c'est la meilleure solution, code DSP c'est en soft mais ça
tourne plus vite avec un rendement a peut près comparable; le problème
viendrait malgré tout de cette 1/2 sec. dans un process qui ne devrait pas
dépasser la seconde.
le DESX coté soft serait une bonne solution ... mais n'est pas cablé coté
carte ... évidemment.
le hash (ou hmac) n'est pas applicable 1) je n'ai pas la place de l'insérer dans ma trame d'échange
S'il y a déjà une place pour un MAC, rien n'empêche de tronquer le résultat de HMAC à la taille disponible.
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
Un MAC à base de DES(3) semble indiqué, sauf problème de temps machine. Sur ce plan, si le DES est triple ET en soft du/des côtés qui manque(nt) de temps, il est probable que lusage de DESX, qui est presque 3 fois plus rapide que DES3, est la meilleure solution. Voir la fin de de mon autre post
Mais dans/avec de nombreuses cartes à puce et/ou DES en hardware, simple DES est à peine moins couteux que triple DES, et la pas de miracle.
François Grieu
coté carte, l'implémentation est en effet matériel avec un temps de (à la louche) 1 ms / octet; le traitement d'une trame rajoute 1/4 de sec. c'est acceptable si c'est la meilleure solution, code DSP c'est en soft mais ça tourne plus vite avec un rendement a peut près comparable; le problème viendrait malgré tout de cette 1/2 sec. dans un process qui ne devrait pas dépasser la seconde.
le DESX coté soft serait une bonne solution ... mais n'est pas cablé coté carte ... évidemment.
Sylvain.
Sylvain
"Francois Grieu" a écrit dans le message de news:
"Sylvain" expose:
A ma conaissance, il n'existe pas de méthode qui assure complètement chiffrement et intégrité avec seulement un chiffrement DES par bloc de donnée.
Il y a toutefois des solutions moins couteuses que CBC-MAC-DES3: par exemple les MACs ISO/IEC 9797-1 algorithmes 2, 3 et 4. Pour n blocks, CBC-MAC-DES3 coute 3*n opérations DES, ces algorithmes ont respectivement un coût n+1, n+2, et n+2 opérations. L'idée de base est de faire un CBC-MAC simple, et d'ajouter quelque part une autre clé.
la variante "algo 2" de 9797-1 est assez répandu dans les cartes (étant un algo de base des appli bancaires); elle constituerait donc une bonne solution. les attaques statistiques ne sont pas trop à craindre (peu de messages, aucune info connue a priori).
merci pour toutes vos réponses.
Sylvain.
"Francois Grieu" <fgrieu@francenet.fr> a écrit dans le message de news:
fgrieu-2E2440.08413910112004@individual.net...
"Sylvain" expose:
A ma conaissance, il n'existe pas de méthode qui assure complètement
chiffrement et intégrité avec seulement un chiffrement DES par bloc
de donnée.
Il y a toutefois des solutions moins couteuses que CBC-MAC-DES3: par
exemple les MACs ISO/IEC 9797-1 algorithmes 2, 3 et 4. Pour n blocks,
CBC-MAC-DES3 coute 3*n opérations DES, ces algorithmes ont respectivement
un coût n+1, n+2, et n+2 opérations. L'idée de base est de faire un
CBC-MAC simple, et d'ajouter quelque part une autre clé.
la variante "algo 2" de 9797-1 est assez répandu dans les cartes (étant un
algo de base des appli bancaires); elle constituerait donc une bonne
solution. les attaques statistiques ne sont pas trop à craindre (peu de
messages, aucune info connue a priori).
A ma conaissance, il n'existe pas de méthode qui assure complètement chiffrement et intégrité avec seulement un chiffrement DES par bloc de donnée.
Il y a toutefois des solutions moins couteuses que CBC-MAC-DES3: par exemple les MACs ISO/IEC 9797-1 algorithmes 2, 3 et 4. Pour n blocks, CBC-MAC-DES3 coute 3*n opérations DES, ces algorithmes ont respectivement un coût n+1, n+2, et n+2 opérations. L'idée de base est de faire un CBC-MAC simple, et d'ajouter quelque part une autre clé.
la variante "algo 2" de 9797-1 est assez répandu dans les cartes (étant un algo de base des appli bancaires); elle constituerait donc une bonne solution. les attaques statistiques ne sont pas trop à craindre (peu de messages, aucune info connue a priori).
merci pour toutes vos réponses.
Sylvain.
WinTerMiNator
"Sylvain" a écrit dans le message de news: 419136af$0$18539$
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).
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 ?...
Sylvain.
1. Du "standard tout fait", utiliser GnuPG, un algorithme avec blocs de 128 bits (comme AES) et forcer l'option "mdc": des blocs de contrôle seront insérés tout au long du message chiffré, ce qui garantit son intégrité lors du déchiffrement.
2. "A la main", prendre un sceau crypto du fichier clair; le concaténer au fichier clair; chiffrer le tout. Après déchiffrement, séparer fichier / sceau; reprendre un sceau du fichier clair, comparer.
-- Michel Nallino aka WinTerMiNator http://www.winterminator.fr.st (Internet et sécurité) http://www.gnupgwin.fr.st (GnuPG pour Windows) Adresse e-mail invalide; pour me contacter: http://www.cerbermail.com/?vdU5HHs5WG
"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
419136af$0$18539$8fcfb975@news.wanadoo.fr...
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).
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 ?...
Sylvain.
1. Du "standard tout fait", utiliser GnuPG, un algorithme avec blocs de 128
bits (comme AES) et forcer l'option "mdc": des blocs de contrôle seront
insérés tout au long du message chiffré, ce qui garantit son intégrité lors
du déchiffrement.
2. "A la main", prendre un sceau crypto du fichier clair; le concaténer au
fichier clair; chiffrer le tout. Après déchiffrement, séparer fichier /
sceau; reprendre un sceau du fichier clair, comparer.
--
Michel Nallino aka WinTerMiNator
http://www.winterminator.fr.st (Internet et sécurité)
http://www.gnupgwin.fr.st (GnuPG pour Windows)
Adresse e-mail invalide; pour me contacter:
http://www.cerbermail.com/?vdU5HHs5WG
"Sylvain" a écrit dans le message de news: 419136af$0$18539$
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).
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 ?...
Sylvain.
1. Du "standard tout fait", utiliser GnuPG, un algorithme avec blocs de 128 bits (comme AES) et forcer l'option "mdc": des blocs de contrôle seront insérés tout au long du message chiffré, ce qui garantit son intégrité lors du déchiffrement.
2. "A la main", prendre un sceau crypto du fichier clair; le concaténer au fichier clair; chiffrer le tout. Après déchiffrement, séparer fichier / sceau; reprendre un sceau du fichier clair, comparer.
-- Michel Nallino aka WinTerMiNator http://www.winterminator.fr.st (Internet et sécurité) http://www.gnupgwin.fr.st (GnuPG pour Windows) Adresse e-mail invalide; pour me contacter: http://www.cerbermail.com/?vdU5HHs5WG
Francois Grieu
Sylvain a dit:
la variante "algo 2" de 9797-1 est assez répandu dans les cartes (étant un algo de base des appli bancaires)
A ma conaissance, c'est l'algorithme 3 qui est répandu en environnement bancaire [*]; il se nomme parfois "Retail MAC".
"Retail MAC" utilise en général le padding 2 de ISO/IEC 9797-1: 1 bit à 1 puis éventuellement des bit à 0 jusqu'à la prochaine frontière de bloc; c'est peut-être ce que Sylvain avait en tête avec "algo 2".
L'algorithme 3 a l'avantage par rapport à l'algorithme 2 de ne pas être vulnérable à une attaque "meet in the middle", du type de celle, classique, contre double-DES (demandant au demeurant tant de mémoire qu'elle est largement théorique).
Comme je l'ai dit, les algorithmes 2 et 3 sont à éviter dès lors que le nombre de messages protégés par le même clé est "grand" [par exemple la probabilité qu'une attaque soit montable avec 2^30 messages connus (soit un milliard) est environ 2^-5 (3,1%)]. L'attaque elle-même est ensuite du niveau simple-DES, à un petit facteur près.
François Grieu
[*] ref: EMV 4.1 Book 2 - Security and Key Management http://www.emvco.com
Sylvain a dit:
la variante "algo 2" de 9797-1 est assez répandu dans les cartes
(étant un algo de base des appli bancaires)
A ma conaissance, c'est l'algorithme 3 qui est répandu en
environnement bancaire [*]; il se nomme parfois "Retail MAC".
"Retail MAC" utilise en général le padding 2 de ISO/IEC 9797-1:
1 bit à 1 puis éventuellement des bit à 0 jusqu'à la prochaine
frontière de bloc; c'est peut-être ce que Sylvain avait en tête
avec "algo 2".
L'algorithme 3 a l'avantage par rapport à l'algorithme 2
de ne pas être vulnérable à une attaque "meet in the middle",
du type de celle, classique, contre double-DES (demandant
au demeurant tant de mémoire qu'elle est largement théorique).
Comme je l'ai dit, les algorithmes 2 et 3 sont à éviter
dès lors que le nombre de messages protégés par le même clé
est "grand" [par exemple la probabilité qu'une attaque soit
montable avec 2^30 messages connus (soit un milliard) est
environ 2^-5 (3,1%)]. L'attaque elle-même est ensuite du
niveau simple-DES, à un petit facteur près.
François Grieu
[*] ref: EMV 4.1 Book 2 - Security and Key Management
http://www.emvco.com
la variante "algo 2" de 9797-1 est assez répandu dans les cartes (étant un algo de base des appli bancaires)
A ma conaissance, c'est l'algorithme 3 qui est répandu en environnement bancaire [*]; il se nomme parfois "Retail MAC".
"Retail MAC" utilise en général le padding 2 de ISO/IEC 9797-1: 1 bit à 1 puis éventuellement des bit à 0 jusqu'à la prochaine frontière de bloc; c'est peut-être ce que Sylvain avait en tête avec "algo 2".
L'algorithme 3 a l'avantage par rapport à l'algorithme 2 de ne pas être vulnérable à une attaque "meet in the middle", du type de celle, classique, contre double-DES (demandant au demeurant tant de mémoire qu'elle est largement théorique).
Comme je l'ai dit, les algorithmes 2 et 3 sont à éviter dès lors que le nombre de messages protégés par le même clé est "grand" [par exemple la probabilité qu'une attaque soit montable avec 2^30 messages connus (soit un milliard) est environ 2^-5 (3,1%)]. L'attaque elle-même est ensuite du niveau simple-DES, à un petit facteur près.
François Grieu
[*] ref: EMV 4.1 Book 2 - Security and Key Management http://www.emvco.com
Sylvain
"WinTerMiNator" a écrit dans le message de news:
1. Du "standard tout fait", utiliser GnuPG, un algorithme avec blocs de 128
bits (comme AES) et forcer l'option "mdc": des blocs de contrôle seront insérés tout au long du message chiffré, ce qui garantit son intégrité lors
du déchiffrement.
super ! vous avez un portage "tout fait" sur C51 de ce GnuPG ? évidemment il devra être certifié FIPS et résister à toutes les attaques lumière ;)
Sylvain.
"WinTerMiNator" <me@privacy.net> a écrit dans le message de news:
2vjhc5F2kcso9U1@uni-berlin.de...
1. Du "standard tout fait", utiliser GnuPG, un algorithme avec blocs de
128
bits (comme AES) et forcer l'option "mdc": des blocs de contrôle seront
insérés tout au long du message chiffré, ce qui garantit son intégrité
lors
du déchiffrement.
super ! vous avez un portage "tout fait" sur C51 de ce GnuPG ?
évidemment il devra être certifié FIPS et résister à toutes les attaques
lumière
;)
