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

Dans l'article <1172929735.409227.54780***30g2000cwc.googlegroups.c om>,
"ptilou" <ptilou***gmail.com> écrit:

> 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

Bonsoir,

On Mar 5, 5:53 pm, Francois Grieu <fgr...***gmail.com> wrote:
> Dans l'article <1172929735.409227.54...***30g2000cwc.googlegroups.c om>,
> "ptilou" <pti...***gmail.com> écrit:
>
> > 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

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.

Dans l'article <1173120514.232166.172160***j27g2000cwj.googlegroups .com>,
"ptilou" <ptilou***gmail.com> écrit:

> 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

Bonjour,

On Mar 6, 6:46 am, Francois Grieu <fgr...***gmail.com> wrote:
> Dans l'article <1173120514.232166.172...***j27g2000cwj.googlegroups .com>,
> "ptilou" <pti...***gmail.com> écrit:
>
> > 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

In article <1173186907.043813.162990***j27g2000cwj.googlegroups .com>,
"ptilou" <ptilou***gmail.com> wrote:

> On Mar 6, 6:46 am, Francois Grieu <fgr...***gmail.com> wrote:
>> 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/cry...a1.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

On Mar 6, 7:47 pm, Francois Grieu <fgr...***gmail.com> wrote:
> In article <1173186907.043813.162...***j27g2000cwj.googlegroups .com>,
>
> "ptilou" <pti...***gmail.com> wrote:
> > On Mar 6, 6:46 am, Francois Grieu <fgr...***gmail.com> wrote:
> >> 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:35http://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);
>

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

Dans l'article <1173215061.115483.163350***n33g2000cwc.googlegroups .com>,
"ptilou" <ptilou***gmail.com> écrit:

> On Mar 6, 7:47 pm, Francois Grieu <fgr...***gmail.com> wrote:
>> 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

* Francois Grieu <fgrieu***gmail.com> in fr.misc.cryptologie:
> 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

On Mar 7, 9:03 am, Damien Wyart <damien.wy...***free.fr> wrote:
> * Francois Grieu <fgr...***gmail.com> in fr.misc.cryptologie:
>
> > 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 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.
>

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

Ptilou

Damien Wyart <damien.wyart***free.fr> écrivait***:

> * Francois Grieu <fgrieu***gmail.com> in fr.misc.cryptologie:
>> 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.

EUh, 4.0 c'est très vieux, freeBSD en est au 6.2 Il faudrait eut-être
d'abord vérifier que ce n'est pas déjà corrigé (4.0 doit dater de 1998
ou 1999, pas 2006)

--
Erwan