top ten des erreurs à ne pas commettre lors de la conception d'un logiciel utilisant le chiffrement

machin

19/09/2005 à 15:02

"machin" wrote in message
news:432eb50e$0$12422$

"ouah" wrote in message
news:432e7a1d$

"machin" a écrit dans le message de news:
432e6847$0$12414$

"WinTerMiNator" wrote in message
news:OEhXe.35100$
machin wrote:
Bonjour,

Etant novice sur le sujet, je cherche un site qui indiquerait le
"top

ten" des choses à ne pas faire lorsque l'on utilise du chiffrement.
Je vois sur le net beaucoup de recommendation et de mise en garde
très

généraliste mais jamais d'exemple concret.

On parle de telle ou telle attaque mais sans donner le code
permettant de la réaliser
Mon but est en fait de tester un logiciel en cours de réalisation
pour

tester sa vulnérabilité.

Merci d'avance,

Erreur N°1 à ne pas commettre: écrire son propre logicielde
chiffrement.

ok, et les autres ?

Erreur N°2: se reposer sur un top-ten pour croire que l'on a à faire à
un

machin sécurisé

t' as raison raymond, vaut mieux que des cons comme moi se repose sur des
mecs hypers balèzes comme toi

pardon, je voulais dire : t' as raison raymond, vaut mieux que des cons
comme moi se reposent sur des mecs hypers balèzes comme toi !

Sylvain

19/09/2005 à 23:48

machin wrote on 16/09/2005 15:45:

Bonjour,

Etant novice sur le sujet, je cherche un site qui indiquerait le "top ten"
des choses à ne pas faire lorsque l'on utilise du chiffrement.
Je vois sur le net beaucoup de recommendation et de mise en garde très
généraliste mais jamais d'exemple concret.

<provoc>

en crypto. on rencontre des théoriciens / matheux qui vous disent *après
coup* "évidemment c'est nul" et des techniciens / codeurs qui cherchent
*vainement* les faiblesses de leur implémentation.

la 2nde famille rechignant un peu à se faire brocarder par la première,
votre demande ne fait hélas pas parti des thèmes récurrents.

</provoc>

On parle de telle ou telle attaque mais sans donner le code permettant de la
réaliser
Mon but est en fait de tester un logiciel en cours de réalisation pour
tester sa vulnérabilité.

passé la provoc., posé comme cela la demande reste assez vague.

disposer, par exemple, du code (ou description détaillé) d'une attaque
n'est pas indispensable pour s'en prémunir; de même les tests de
résistance d'un *logiciel* sont (presque par définition) caduques - il
existera toujours un moyen logiciel de détourner/espionner/etc un autre
code (la question aurait été différente pour un token).

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?
- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas ?
- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?
- en signature asym., limiter la taille du message à "très peu" d'octets
(juste un hash et son identifiant) c'est indispensable ou on peut signer
des grands blocs (PKCS: "key size - 11") ?

... y'a des soirs on douterait de toute sa crypto ...

Sylvain.

pornin

20/09/2005 à 09:46

According to Sylvain :

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?

CFB, le vrai, est paramétré en fonction du nombre de bits utilisés dans
la rétroaction ; c'est ce même nombre de bits qui est produit à chaque
invocation du système de chiffrement par blocs sous-jacent. Pour obtenir
des performances décentes (i.e. équivalentes à celles du mode CBC), il
vaut mieux utiliser un bloc complet dans la rétroaction. C'est ce que
spécifie, par exemple, OpenPGP. Je suppose donc qu'on parle de ce mode
en particulier.

Ce rappel étant fait, il s'avère que CBC et CFB ont tous les deux des
"ennuis" quand on chiffre des messages dont la taille cumulée (pour une
clé donnée) dépasse la racine carrée de l'espace des blocs (i.e. 2^32
blocs, soit 32 giga-octets, pour des blocs de 64 bits, comme ce que
fournit 3DES, Blowfish ou CAST5). Au-delà cette limite, il vaut mieux
choisir une nouvelle clé. Par ailleurs, CBC et CFB nécessitent, pour
chaque message, une valeur initiale (IV) choisie aléatoirement selon un
processus imprédictible et cryptographiquement solide.

De ce point de vue, CFB n'est pas meilleur que CBC, ni l'inverse. CFB
a l'avantage de ne pas nécessiter de padding, contrairement à CBC. A
contrario, CBC a été beaucoup plus étudié que CFB, et sa sécurité est
mieux comprise ; CBC peut aussi être utilisé pour fabriquer d'autres
types de protocoles, comme par exemple un MAC.

La meilleure réponse que je connaisse à la question "CFB vs CBC",
c'est que CTR est meilleur que les deux. Il a grosso-modo les mêmes
limitations en termes de taille de messages cumulés, mais il ne
nécessite pas des IV aléatoires ; on peut utiliser une allocation
incrémentale de base (on ne doit pas réutiliser la même valeur
du compteur, mais on n'a pas besoin que les valeurs du compteur
soient imprédictibles), ce qui peut être un gros avantage dans
certaines situations. De plus, il ne nécessite pas de padding et est
parallélisable.

L'usage d'un algorithme à blocs de 128 bits (comme l'AES) permet de
repousser la limitation en taille de message dans les limbes.

- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas ?

OAEP dispose d'une preuve de sécurité. Pas la version précédente (dite
"PKCS#1 v1.5", par opposition à OAEP, qui est dans PKCS#1 à partir de la
version 2.0).

Mais PKCS#1 v1.5 est supporté par beaucoup plus de logiciels, et il
est largement déployé. Ce qui veut dire qu'il ne doit pas être trop
fragile (il a subi "l'épreuve du feu" pendant plus de dix ans, et pour
le moment il ne s'en tire pas trop mal) et que par ailleurs, s'il est
cassé, ça mettrait tellement le boxon qu'il n'est pas suicidaire de
s'en servir (je veux dire que, du point de vue d'une entreprise, un
cassage de PKCS#1 v1.5 ne la mettrait pas en difficulté vis-à-vis de ses
concurrentes, puisqu'elles s'en servent aussi).

Idéalement, on utilise la signature au sein d'un protocole qui permet de
spécifier l'algorithme choisi dans un paramètre envoyé avec la signature
(c'est ce qui se fait, par exemple, dans X.509 et tout ce qui tourne
autour), ce qui permet d'envisager un passage progressif à OAEP.

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?

Un MAC, c'est un MAC, et HMAC n'est pas plus "faux" que CBC-MAC.

Il existe quelques algorithmes de MAC dédiés, construits spécialement
pour l'occasion, mais ils sont assez récents. Le sujet est "chaud" et
il y a pas mal de publications sur le sujet ; on commence maintenant
à comprendre comment il faut définir leur sécurité.

Les façons traditionnelles de construire des MACs sont par assemblage
d'autres algorithmes ; on peut le faire, par exemple, avec des fonctions
de hachage (HMAC) ou avec des algorithmes de chiffrement par blocs
(3DES, AES...). HMAC dispose d'une preuve de sécurité (qui n'a pas
une portée délirante, mais qui est quand même mieux que rien), il est
spécifié depuis déjà quelques temps (cf RFC 2104, qui date du début
1997) et largement implémenté et déployé (par exemple dans SSL). Ses
performances sont bonnes (typiquement deux à quatre fois la vitesse
d'un CBC-MAC). En bref, HMAC c'est plutôt bien. CBC-MAC est à réserver,
de mon point de vue, aux cas où on a déjà une implémentation d'un
algorithme de chiffrement et qu'il est impératif de s'en resservir (par
exemple, on est très limité en taille de code, ou alors on a un circuit
spécialisé pour le chiffrement mais pas pour le hachage). CBC-MAC est
aussi un peu traître, parce qu'il est tentant d'utiliser la même clé
pour le calcul du MAC et pour le chiffrement des données elles-mêmes, ce
qui détruit subrepticement la sécurité du MAC.

Ce qui n'empêche pas de surveiller ce qui se fait actuellement dans le
monde de la recherche. Un sujet à la mode, c'est la fabrication de modes
de chiffrement utilisant un algorithme de chiffrement par blocs, et qui
combinent chiffrement et MAC.

- en signature asym., limiter la taille du message à "très peu"
d'octets (juste un hash et son identifiant) c'est indispensable ou on
peut signer des grands blocs (PKCS: "key size - 11") ?

"Key size - 11" n'est pas si grand que ça (117 octets pour une clé RSA
de 1024 bits) et cette taille est réduite dans d'autres paddings (comme
PSS, spécifié dans PKCS#1 v2.1). C'est vite limitatif.

Ne pas utiliser de fonction de hachage a quelques inconvénients.
Notamment, ça détruit la plupart des preuves de sécurité. Par ailleurs,
cela signifie que la publication de la signature implique celle des
données signées, ce qui est incompatible avec certains protocoles
(timestamp, par exemple, où on voudrait que le signataire n'ait pas
accès à ce qu'il signe).

En bref : non, n'enlevez pas la fonction de hachage. Cette fonction
permet justement d'envisager l'algorithme de signature comme travaillant
sur des messages de taille arbitraire, ce qui est bien.

--Thomas Pornin

According to Sylvain <noSpam@mail.net>:

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?

CFB, le vrai, est paramétré en fonction du nombre de bits utilisés dans
la rétroaction ; c'est ce même nombre de bits qui est produit à chaque
invocation du système de chiffrement par blocs sous-jacent. Pour obtenir
des performances décentes (i.e. équivalentes à celles du mode CBC), il
vaut mieux utiliser un bloc complet dans la rétroaction. C'est ce que
spécifie, par exemple, OpenPGP. Je suppose donc qu'on parle de ce mode
en particulier.

Ce rappel étant fait, il s'avère que CBC et CFB ont tous les deux des
"ennuis" quand on chiffre des messages dont la taille cumulée (pour une
clé donnée) dépasse la racine carrée de l'espace des blocs (i.e. 2^32
blocs, soit 32 giga-octets, pour des blocs de 64 bits, comme ce que
fournit 3DES, Blowfish ou CAST5). Au-delà cette limite, il vaut mieux
choisir une nouvelle clé. Par ailleurs, CBC et CFB nécessitent, pour
chaque message, une valeur initiale (IV) choisie aléatoirement selon un
processus imprédictible et cryptographiquement solide.

De ce point de vue, CFB n'est pas meilleur que CBC, ni l'inverse. CFB
a l'avantage de ne pas nécessiter de padding, contrairement à CBC. A
contrario, CBC a été beaucoup plus étudié que CFB, et sa sécurité est
mieux comprise ; CBC peut aussi être utilisé pour fabriquer d'autres
types de protocoles, comme par exemple un MAC.

La meilleure réponse que je connaisse à la question "CFB vs CBC",
c'est que CTR est meilleur que les deux. Il a grosso-modo les mêmes
limitations en termes de taille de messages cumulés, mais il ne
nécessite pas des IV aléatoires ; on peut utiliser une allocation
incrémentale de base (on ne doit pas réutiliser la même valeur
du compteur, mais on n'a pas besoin que les valeurs du compteur
soient imprédictibles), ce qui peut être un gros avantage dans
certaines situations. De plus, il ne nécessite pas de padding et est
parallélisable.

L'usage d'un algorithme à blocs de 128 bits (comme l'AES) permet de
repousser la limitation en taille de message dans les limbes.

- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas ?

OAEP dispose d'une preuve de sécurité. Pas la version précédente (dite
"PKCS#1 v1.5", par opposition à OAEP, qui est dans PKCS#1 à partir de la
version 2.0).

Mais PKCS#1 v1.5 est supporté par beaucoup plus de logiciels, et il
est largement déployé. Ce qui veut dire qu'il ne doit pas être trop
fragile (il a subi "l'épreuve du feu" pendant plus de dix ans, et pour
le moment il ne s'en tire pas trop mal) et que par ailleurs, s'il est
cassé, ça mettrait tellement le boxon qu'il n'est pas suicidaire de
s'en servir (je veux dire que, du point de vue d'une entreprise, un
cassage de PKCS#1 v1.5 ne la mettrait pas en difficulté vis-à-vis de ses
concurrentes, puisqu'elles s'en servent aussi).

Idéalement, on utilise la signature au sein d'un protocole qui permet de
spécifier l'algorithme choisi dans un paramètre envoyé avec la signature
(c'est ce qui se fait, par exemple, dans X.509 et tout ce qui tourne
autour), ce qui permet d'envisager un passage progressif à OAEP.

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?

Un MAC, c'est un MAC, et HMAC n'est pas plus "faux" que CBC-MAC.

Il existe quelques algorithmes de MAC dédiés, construits spécialement
pour l'occasion, mais ils sont assez récents. Le sujet est "chaud" et
il y a pas mal de publications sur le sujet ; on commence maintenant
à comprendre comment il faut définir leur sécurité.

Les façons traditionnelles de construire des MACs sont par assemblage
d'autres algorithmes ; on peut le faire, par exemple, avec des fonctions
de hachage (HMAC) ou avec des algorithmes de chiffrement par blocs
(3DES, AES...). HMAC dispose d'une preuve de sécurité (qui n'a pas
une portée délirante, mais qui est quand même mieux que rien), il est
spécifié depuis déjà quelques temps (cf RFC 2104, qui date du début
1997) et largement implémenté et déployé (par exemple dans SSL). Ses
performances sont bonnes (typiquement deux à quatre fois la vitesse
d'un CBC-MAC). En bref, HMAC c'est plutôt bien. CBC-MAC est à réserver,
de mon point de vue, aux cas où on a déjà une implémentation d'un
algorithme de chiffrement et qu'il est impératif de s'en resservir (par
exemple, on est très limité en taille de code, ou alors on a un circuit
spécialisé pour le chiffrement mais pas pour le hachage). CBC-MAC est
aussi un peu traître, parce qu'il est tentant d'utiliser la même clé
pour le calcul du MAC et pour le chiffrement des données elles-mêmes, ce
qui détruit subrepticement la sécurité du MAC.

Ce qui n'empêche pas de surveiller ce qui se fait actuellement dans le
monde de la recherche. Un sujet à la mode, c'est la fabrication de modes
de chiffrement utilisant un algorithme de chiffrement par blocs, et qui
combinent chiffrement et MAC.

- en signature asym., limiter la taille du message à "très peu"
d'octets (juste un hash et son identifiant) c'est indispensable ou on
peut signer des grands blocs (PKCS: "key size - 11") ?

"Key size - 11" n'est pas si grand que ça (117 octets pour une clé RSA
de 1024 bits) et cette taille est réduite dans d'autres paddings (comme
PSS, spécifié dans PKCS#1 v2.1). C'est vite limitatif.

Ne pas utiliser de fonction de hachage a quelques inconvénients.
Notamment, ça détruit la plupart des preuves de sécurité. Par ailleurs,
cela signifie que la publication de la signature implique celle des
données signées, ce qui est incompatible avec certains protocoles
(timestamp, par exemple, où on voudrait que le signataire n'ait pas
accès à ce qu'il signe).

En bref : non, n'enlevez pas la fonction de hachage. Cette fonction
permet justement d'envisager l'algorithme de signature comme travaillant
sur des messages de taille arbitraire, ce qui est bien.

--Thomas Pornin

Vous avez filtré cet utilisateur ! Consultez son message

According to Sylvain :

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?

CFB, le vrai, est paramétré en fonction du nombre de bits utilisés dans
la rétroaction ; c'est ce même nombre de bits qui est produit à chaque
invocation du système de chiffrement par blocs sous-jacent. Pour obtenir
des performances décentes (i.e. équivalentes à celles du mode CBC), il
vaut mieux utiliser un bloc complet dans la rétroaction. C'est ce que
spécifie, par exemple, OpenPGP. Je suppose donc qu'on parle de ce mode
en particulier.

Ce rappel étant fait, il s'avère que CBC et CFB ont tous les deux des
"ennuis" quand on chiffre des messages dont la taille cumulée (pour une
clé donnée) dépasse la racine carrée de l'espace des blocs (i.e. 2^32
blocs, soit 32 giga-octets, pour des blocs de 64 bits, comme ce que
fournit 3DES, Blowfish ou CAST5). Au-delà cette limite, il vaut mieux
choisir une nouvelle clé. Par ailleurs, CBC et CFB nécessitent, pour
chaque message, une valeur initiale (IV) choisie aléatoirement selon un
processus imprédictible et cryptographiquement solide.

De ce point de vue, CFB n'est pas meilleur que CBC, ni l'inverse. CFB
a l'avantage de ne pas nécessiter de padding, contrairement à CBC. A
contrario, CBC a été beaucoup plus étudié que CFB, et sa sécurité est
mieux comprise ; CBC peut aussi être utilisé pour fabriquer d'autres
types de protocoles, comme par exemple un MAC.

La meilleure réponse que je connaisse à la question "CFB vs CBC",
c'est que CTR est meilleur que les deux. Il a grosso-modo les mêmes
limitations en termes de taille de messages cumulés, mais il ne
nécessite pas des IV aléatoires ; on peut utiliser une allocation
incrémentale de base (on ne doit pas réutiliser la même valeur
du compteur, mais on n'a pas besoin que les valeurs du compteur
soient imprédictibles), ce qui peut être un gros avantage dans
certaines situations. De plus, il ne nécessite pas de padding et est
parallélisable.

L'usage d'un algorithme à blocs de 128 bits (comme l'AES) permet de
repousser la limitation en taille de message dans les limbes.

- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas ?

OAEP dispose d'une preuve de sécurité. Pas la version précédente (dite
"PKCS#1 v1.5", par opposition à OAEP, qui est dans PKCS#1 à partir de la
version 2.0).

Mais PKCS#1 v1.5 est supporté par beaucoup plus de logiciels, et il
est largement déployé. Ce qui veut dire qu'il ne doit pas être trop
fragile (il a subi "l'épreuve du feu" pendant plus de dix ans, et pour
le moment il ne s'en tire pas trop mal) et que par ailleurs, s'il est
cassé, ça mettrait tellement le boxon qu'il n'est pas suicidaire de
s'en servir (je veux dire que, du point de vue d'une entreprise, un
cassage de PKCS#1 v1.5 ne la mettrait pas en difficulté vis-à-vis de ses
concurrentes, puisqu'elles s'en servent aussi).

Idéalement, on utilise la signature au sein d'un protocole qui permet de
spécifier l'algorithme choisi dans un paramètre envoyé avec la signature
(c'est ce qui se fait, par exemple, dans X.509 et tout ce qui tourne
autour), ce qui permet d'envisager un passage progressif à OAEP.

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?

Un MAC, c'est un MAC, et HMAC n'est pas plus "faux" que CBC-MAC.

Il existe quelques algorithmes de MAC dédiés, construits spécialement
pour l'occasion, mais ils sont assez récents. Le sujet est "chaud" et
il y a pas mal de publications sur le sujet ; on commence maintenant
à comprendre comment il faut définir leur sécurité.

Les façons traditionnelles de construire des MACs sont par assemblage
d'autres algorithmes ; on peut le faire, par exemple, avec des fonctions
de hachage (HMAC) ou avec des algorithmes de chiffrement par blocs
(3DES, AES...). HMAC dispose d'une preuve de sécurité (qui n'a pas
une portée délirante, mais qui est quand même mieux que rien), il est
spécifié depuis déjà quelques temps (cf RFC 2104, qui date du début
1997) et largement implémenté et déployé (par exemple dans SSL). Ses
performances sont bonnes (typiquement deux à quatre fois la vitesse
d'un CBC-MAC). En bref, HMAC c'est plutôt bien. CBC-MAC est à réserver,
de mon point de vue, aux cas où on a déjà une implémentation d'un
algorithme de chiffrement et qu'il est impératif de s'en resservir (par
exemple, on est très limité en taille de code, ou alors on a un circuit
spécialisé pour le chiffrement mais pas pour le hachage). CBC-MAC est
aussi un peu traître, parce qu'il est tentant d'utiliser la même clé
pour le calcul du MAC et pour le chiffrement des données elles-mêmes, ce
qui détruit subrepticement la sécurité du MAC.

Ce qui n'empêche pas de surveiller ce qui se fait actuellement dans le
monde de la recherche. Un sujet à la mode, c'est la fabrication de modes
de chiffrement utilisant un algorithme de chiffrement par blocs, et qui
combinent chiffrement et MAC.

- en signature asym., limiter la taille du message à "très peu"
d'octets (juste un hash et son identifiant) c'est indispensable ou on
peut signer des grands blocs (PKCS: "key size - 11") ?

"Key size - 11" n'est pas si grand que ça (117 octets pour une clé RSA
de 1024 bits) et cette taille est réduite dans d'autres paddings (comme
PSS, spécifié dans PKCS#1 v2.1). C'est vite limitatif.

Ne pas utiliser de fonction de hachage a quelques inconvénients.
Notamment, ça détruit la plupart des preuves de sécurité. Par ailleurs,
cela signifie que la publication de la signature implique celle des
données signées, ce qui est incompatible avec certains protocoles
(timestamp, par exemple, où on voudrait que le signataire n'ait pas
accès à ce qu'il signe).

En bref : non, n'enlevez pas la fonction de hachage. Cette fonction
permet justement d'envisager l'algorithme de signature comme travaillant
sur des messages de taille arbitraire, ce qui est bien.

--Thomas Pornin

machin

20/09/2005 à 10:33

"Sylvain" wrote in message
news:432f3223$0$1731$

machin wrote on 16/09/2005 15:45:
Bonjour,

Etant novice sur le sujet, je cherche un site qui indiquerait le "top
ten"

des choses à ne pas faire lorsque l'on utilise du chiffrement.
Je vois sur le net beaucoup de recommendation et de mise en garde très
généraliste mais jamais d'exemple concret.

<provoc>

en crypto. on rencontre des théoriciens / matheux qui vous disent *après
coup* "évidemment c'est nul" et des techniciens / codeurs qui cherchent
*vainement* les faiblesses de leur implémentation.

la 2nde famille rechignant un peu à se faire brocarder par la première,
votre demande ne fait hélas pas parti des thèmes récurrents.

</provoc>

On parle de telle ou telle attaque mais sans donner le code permettant
de la

réaliser
Mon but est en fait de tester un logiciel en cours de réalisation pour
tester sa vulnérabilité.

passé la provoc., posé comme cela la demande reste assez vague.

disposer, par exemple, du code (ou description détaillé) d'une attaque
n'est pas indispensable pour s'en prémunir; de même les tests de
résistance d'un *logiciel* sont (presque par définition) caduques - il
existera toujours un moyen logiciel de détourner/espionner/etc un autre
code (la question aurait été différente pour un token).

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?
- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas
?

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?
- en signature asym., limiter la taille du message à "très peu" d'octets
(juste un hash et son identifiant) c'est indispensable ou on peut signer
des grands blocs (PKCS: "key size - 11") ?

... y'a des soirs on douterait de toute sa crypto ...

Sylvain.

ben alors ...
Je crois que je vais donc me pencher sur des sources public d'autres applis
pour voir comment ils envisagent le problème

En tout cas, merci pour votre éclairage

"Sylvain" <noSpam@mail.net> wrote in message
news:432f3223$0$1731$8fcfb975@news.wanadoo.fr...

machin wrote on 16/09/2005 15:45:

Bonjour,

Etant novice sur le sujet, je cherche un site qui indiquerait le "top
ten"

des choses à ne pas faire lorsque l'on utilise du chiffrement.
Je vois sur le net beaucoup de recommendation et de mise en garde très
généraliste mais jamais d'exemple concret.

<provoc>

en crypto. on rencontre des théoriciens / matheux qui vous disent *après
coup* "évidemment c'est nul" et des techniciens / codeurs qui cherchent
*vainement* les faiblesses de leur implémentation.

la 2nde famille rechignant un peu à se faire brocarder par la première,
votre demande ne fait hélas pas parti des thèmes récurrents.

</provoc>

On parle de telle ou telle attaque mais sans donner le code permettant
de la

réaliser
Mon but est en fait de tester un logiciel en cours de réalisation pour
tester sa vulnérabilité.

passé la provoc., posé comme cela la demande reste assez vague.

disposer, par exemple, du code (ou description détaillé) d'une attaque
n'est pas indispensable pour s'en prémunir; de même les tests de
résistance d'un *logiciel* sont (presque par définition) caduques - il
existera toujours un moyen logiciel de détourner/espionner/etc un autre
code (la question aurait été différente pour un token).

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?
- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas
?

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?
- en signature asym., limiter la taille du message à "très peu" d'octets
(juste un hash et son identifiant) c'est indispensable ou on peut signer
des grands blocs (PKCS: "key size - 11") ?

... y'a des soirs on douterait de toute sa crypto ...

Sylvain.

ben alors ...
Je crois que je vais donc me pencher sur des sources public d'autres applis
pour voir comment ils envisagent le problème

En tout cas, merci pour votre éclairage

Vous avez filtré cet utilisateur ! Consultez son message

"Sylvain" wrote in message
news:432f3223$0$1731$

machin wrote on 16/09/2005 15:45:
Bonjour,

Etant novice sur le sujet, je cherche un site qui indiquerait le "top
ten"

des choses à ne pas faire lorsque l'on utilise du chiffrement.
Je vois sur le net beaucoup de recommendation et de mise en garde très
généraliste mais jamais d'exemple concret.

<provoc>

en crypto. on rencontre des théoriciens / matheux qui vous disent *après
coup* "évidemment c'est nul" et des techniciens / codeurs qui cherchent
*vainement* les faiblesses de leur implémentation.

la 2nde famille rechignant un peu à se faire brocarder par la première,
votre demande ne fait hélas pas parti des thèmes récurrents.

</provoc>

On parle de telle ou telle attaque mais sans donner le code permettant
de la

réaliser
Mon but est en fait de tester un logiciel en cours de réalisation pour
tester sa vulnérabilité.

passé la provoc., posé comme cela la demande reste assez vague.

disposer, par exemple, du code (ou description détaillé) d'une attaque
n'est pas indispensable pour s'en prémunir; de même les tests de
résistance d'un *logiciel* sont (presque par définition) caduques - il
existera toujours un moyen logiciel de détourner/espionner/etc un autre
code (la question aurait été différente pour un token).

reste tout de même les choix des mécanismes (plus que de leur
implémentation), et là je rejoins votre perpléxité à trouver des
conseils clairs; par exemple:

- en chiffrement sym., un cipher CFB s'est mieux que CBC ou pas ?
- en chiffrement asym., un padding PKCS1 OAEP c'est mieux que PKCS1 ou pas
?

- en signature sym., un HMAC avec compteur (Open OTP) c'est aussi bien
qu'en vrai MAC (3DES, AES) avec sequence counter ou pas ?
- en signature asym., limiter la taille du message à "très peu" d'octets
(juste un hash et son identifiant) c'est indispensable ou on peut signer
des grands blocs (PKCS: "key size - 11") ?

... y'a des soirs on douterait de toute sa crypto ...

Sylvain.

ben alors ...
Je crois que je vais donc me pencher sur des sources public d'autres applis
pour voir comment ils envisagent le problème

En tout cas, merci pour votre éclairage

Sylvain

20/09/2005 à 22:58

Thomas Pornin wrote on 20/09/2005 09:46:

[...]
--Thomas Pornin

merci bcp pour votre temps et vos commentaires / conseils précieux.

Sylvain.

top ten des erreurs à ne pas commettre lors de la conception d'un logiciel utilisant le chiffrement

5 réponses

Veuillez sélectionner un problème