[newbie] sha1 deux méthode & rfc 3174

Le
ptilou
Bonjour,

est que quelqu'un peut m'éclairer sur sha1, non sur les problème de
collision, mais sur la méthode employé pour obtenir la clés de
hachage ?
( j'ai lu vaguement rfc 3174 et il y aurait deux méthode ? )

Merci

Ptilou
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Francois Grieu
Le #574376
Dans l'article "ptilou"
est que quelqu'un peut m'éclairer sur sha1, non sur les problème de
collision, mais sur la méthode employée pour obtenir la clés de
hachage ?
( j'ai lu vaguement rfc 3174 et il y aurait deux méthode ? )


Le termé "clé de hachage" est impropre. Dire "résultat du hachage".

La méthode 2 est une simple optimisation de la méthode 1;
ou plutôt la méthode 1 est un intermédiaire pour exposer la
méthode 2, qu'en pratique toute les implémentations rapides
utilisent.
Bien sur les deux méthodes donnent le même résultat, sauf quand
l'implémentation est fausse, ce qui n'est pas si exceptionnel.


François Grieu

ptilou
Le #574375
Bonsoir,

On Mar 5, 5:53 pm, Francois Grieu
Dans l'article "ptilou"
est que quelqu'un peut m'éclairer sur sha1, non sur les problème de
collision, mais sur la méthode employée pour obtenir la clés de
hachage ?
( j'ai lu vaguement rfc 3174 et il y aurait deux méthode ? )


Le termé "clé de hachage" est impropre. Dire "résultat du hachage".

La méthode 2 est une simple optimisation de la méthode 1;
ou plutôt la méthode 1 est un intermédiaire pour exposer la
méthode 2, qu'en pratique toute les implémentations rapides
utilisent.
Bien sur les deux méthodes donnent le même résultat, sauf quand
l'implémentation est fausse, ce qui n'est pas si exceptionnel.



Peut tu éclairer ma lanterne à propos d'implémentation fausse ?

Merci

Ptilou


Sylvain
Le #574374
ptilou wrote on 05/03/2007 19:48:

Bien sur les deux méthodes donnent le même résultat, sauf quand
l'implémentation est fausse, ce qui n'est pas si exceptionnel.


Peut tu éclairer ma lanterne à propos d'implémentation fausse ?


François indique que le résultat est identique si (bien sur)
l'implémentation n'est pas buggée, ta lanterne cherchait des noms
commerciaux ??

Sylvain.


Francois Grieu
Le #574178
Dans l'article "ptilou"
Peut tu éclairer ma lanterne à propos d'implémentation fausse ?


Il y a plusieurs pièges dans l'implémentation de SHA-1, pour
les messages d'environ 64*n+56 octets, 64*n+63 octets, 2^29 octets,
et les messages de longeur non multiple de 8 bits, si l'implémentation
le supporte.

La norme FIPS 180-1 donnais un vecteur de test pour le premier
piège, mais pas pour les autres, de sorte que l'on trouve
assez souvent des erreurs, et pas seulement dans son propre code.

Il faut relire le code avec une immense attention, et/ou
utiliser des vecteurs de tests, qui maintenant sont disponibles
au bas de cette page
http://csrc.nist.gov/cryptval/shs.htm


François Grieu

ptilou
Le #574177
Bonjour,

On Mar 6, 6:46 am, Francois Grieu
Dans l'article "ptilou"
Peut tu éclairer ma lanterne à propos d'implémentation fausse ?


Il y a plusieurs pièges dans l'implémentation de SHA-1, pour
les messages d'environ 64*n+56 octets, 64*n+63 octets, 2^29 octets,
et les messages de longeur non multiple de 8 bits, si l'implémentation
le supporte.

La norme FIPS 180-1 donnais un vecteur de test pour le premier
piège, mais pas pour les autres, de sorte que l'on trouve
assez souvent des erreurs, et pas seulement dans son propre code.

Il faut relire le code avec une immense attention, et/ou
utiliser des vecteurs de tests, qui maintenant sont disponibles
au bas de cette pagehttp://csrc.nist.gov/cryptval/shs.htm



Je ne programme pas !
Est qu'il y a un logiciel portable sur de nombreuse plateformes, qui à
rencontré ces problème d'implémentation ?

Merci

Ptilou


Francois Grieu
Le #574176
In article "ptilou"
On Mar 6, 6:46 am, Francois Grieu
Il y a plusieurs pièges dans l'implémentation de SHA-1, pour
les messages d'environ 64*n+56 octets, 64*n+63 octets, 2^29 octets,
et les messages de longeur non multiple de 8 bits, si l'implémentation
le supporte.


Je ne programme pas !
Est qu'il y a un logiciel portable sur de nombreuse plateformes,
qui à rencontré ces problème d'implémentation ?


Oui.

Généralement, les bugs touchant les frontières de 64*n+63 octets
sont souvent gênants donc rapidement corrigés et ne sont pas dans
des versions stables; on en trouve parfois trace dans les "changelog".
Par contre les bugs touchant les frantières de 2^29 octets sont
fréquent dans le code actif.

Un exemple au hasard: OpenBSD, sha1.c v 1.5 2004/04/28 20:39:35
http://fxr.watson.org/fxr/source/crypto/sha1.c?v=OPENBSD

Si on passe un bloc de donnée de 512Mo ou plus (ce qui de nos jours
n'a rien d'impossible) à SHA1Update, le résultat est faux, car
l'addition de la taille d'un mot de 64 bits est faite par

void SHA1Update(SHA1_CTX *context, unsigned char *data, unsigned int len)
(..)
context->count += (len << 3);

context->count est de type u_int64_t; il aurait fallu

context->count += ((u_int64_t )len << 3);


François Grieu


ptilou
Le #574175
On Mar 6, 7:47 pm, Francois Grieu
In article
"ptilou"
On Mar 6, 6:46 am, Francois Grieu
Il y a plusieurs pièges dans l'implémentation de SHA-1, pour
les messages d'environ 64*n+56 octets, 64*n+63 octets, 2^29 octets,
et les messages de longeur non multiple de 8 bits, si l'implémentati on
le supporte.


Je ne programme pas !
Est qu'il y a un logiciel portable sur de nombreuse plateformes,
qui à rencontré ces problème d'implémentation ?


Oui.

Généralement, les bugs touchant les frontières de 64*n+63 octets
sont souvent gênants donc rapidement corrigés et ne sont pas dans
des versions stables; on en trouve parfois trace dans les "changelog".
Par contre les bugs touchant les frantières de 2^29 octets sont
fréquent dans le code actif.

Un exemple au hasard: OpenBSD, sha1.c v 1.5 2004/04/28 20:39:35http://fx r.watson.org/fxr/source/crypto/sha1.c?v=OPENBSD

Si on passe un bloc de donnée de 512Mo ou plus (ce qui de nos jours
n'a rien d'impossible) à SHA1Update, le résultat est faux, car
l'addition de la taille d'un mot de 64 bits est faite par

void SHA1Update(SHA1_CTX *context, unsigned char *data, unsigned int len)
(..)
context->count += (len << 3);

context->count est de type u_int64_t; il aurait fallu

context->count += ((u_int64_t )len << 3);



Sa a été corrigé, je suppose ?
Donc les erreurs se produisent plus les fichiers sont important en
volume !
( Et non l'inverse ? Alors que je pensais le contraire ! )

Enfin existe t'il un soft qui n'a jamais connu de PB
d'implémentation ?

Ptilou



Francois Grieu
Le #574174
Dans l'article "ptilou"
On Mar 6, 7:47 pm, Francois Grieu
Un exemple au hasard: OpenBSD, sha1.c v 1.5 2004/04/28 20:39:35
Si on passe un bloc de donnée de 512Mo ou plus (ce qui de nos
jours n'a rien d'impossible) à SHA1Update, le résultat est faux.


ça a été corrigé, je suppose ?


Non. Voir dans FreeBSD 4.0 (17 septembre 2006)
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz
(attention c'est gros).

J'ai même trouvé, parmis de multiples variantes de sha1_update
dans cette distro, une qui est plus indiscutablement fause,
différemment, et un peu plus rarement.

void
isc_sha1_update(isc_sha1_t *context, const unsigned char *data,
unsigned int len)
{
unsigned int i, j;
(..)
j = context->count[0];
if ((context->count[0] += len << 3) < j)
context->count[1] += (len >> 29) + 1;

Il y a une tentative manifeste de traiter len plus grand que 512Mo
(sinon à quoi bon len >> 29 ??), mais ça ne marche pas, en particulier
quand len est exactement 512Mo. Par contre ça marche si on passe
des blocs de 510Mo, puis 515Mo (1Mo = 1048576 octets).

Il fallait écrire par exemple:
j = len<<3;
context->count[1] += ((context->count[0] += j)<j)+(len>>29);


Enfin existe t'il un soft qui n'a jamais connu de PB d'implémentation ?


Au pied de la lettre: oui, il en existe même surement plusieurs,
mais je ne connais l'historique complet d'aucun autre logiciel
que le mien ;-)

Plus sérieusement: la pluspart des librairies cryptographiques
en C/C++ du domaine public que je connais sont sans bug apparent
dans leur version courante, et toutes fonctionnent bien tant que
l'on ne leur passe ques des BLOCS de pas plus de 512 Mo.
Et surtout, pratiquement tous les programmes qui calculent le
SHA1 d'un FICHIER le tronçonnent en petits blocs, donc fonctionnent
même avec le bug latent ci-dessus dans leur librairie SHA-1.
Ca fait 8 ans que je n'ai pas hurlé après un outil à calculer SHA-1
d'un fichier disque qui me sort un résultat faux au delà de 512 Mo.


François Grieu


Damien Wyart
Le #574173
* Francois Grieu
Non. Voir dans FreeBSD 4.0 (17 septembre 2006)
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz
(attention c'est gros).

J'ai même trouvé, parmis de multiples variantes de sha1_update dans
cette distro, une qui est plus indiscutablement fause, différemment,
et un peu plus rarement.


Avez-vous signalé tout cela aux développeurs concernés ? Si non, c'est
assez logique que ça ne soit pas corrigé (même s'ils font des audits,
ils ne peuvent pas tout repérer), et c'est dommage que vous gardiez
l'info pour vous ; si oui, je suppose que ça sera corrigé quand ils en
auront la possibilité matérielle, sauf s'ils n'étaient pas d'accord,
mais dans ce cas, cela serait étonnant.

--
DW

ptilou
Le #574172
On Mar 7, 9:03 am, Damien Wyart
* Francois Grieu
Non. Voir dans FreeBSD 4.0 (17 septembre 2006)
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz
(attention c'est gros).



Que ne faut il pas comprendre ?

J'ai même trouvé, parmis de multiples variantes de sha1_update dans
cette distro, une qui est plus indiscutablement fause, différemment,
et un peu plus rarement.


Avez-vous signalé tout cela aux développeurs concernés ? Si non, c' est
assez logique que ça ne soit pas corrigé (même s'ils font des audit s,
ils ne peuvent pas tout repérer), et c'est dommage que vous gardiez
l'info pour vous ; si oui, je suppose que ça sera corrigé quand ils en
auront la possibilité matérielle, sauf s'ils n'étaient pas d'accord,
mais dans ce cas, cela serait étonnant.



Si on fait une comparaison, que vaut le hash de S/Mime ?

Ptilou


Publicité
Poster une réponse
Anonyme