est que quelqu'un peut m'=E9clairer sur sha1, non sur les probl=E8me de
collision, mais sur la m=E9thode employ=E9 pour obtenir la cl=E9s de
hachage ?
( j'ai lu vaguement rfc 3174 et il y aurait deux m=E9thode ? )
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
Dans l'article <1172929735.409227.54780@30g2000cwc.googlegroups.com>,
"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.
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
Bonsoir,
On Mar 5, 5:53 pm, Francois Grieu wrote:
Dans l'article , "ptilou" é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
Bonsoir,
On Mar 5, 5:53 pm, Francois Grieu <fgr...@gmail.com> wrote:
Dans l'article <1172929735.409227.54...@30g2000cwc.googlegroups.com>,
"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 ?
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
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.
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 ??
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
Dans l'article , "ptilou" é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
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
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
Bonjour,
On Mar 6, 6:46 am, Francois Grieu wrote:
Dans l'article , "ptilou" é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
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 ?
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
In article , "ptilou" wrote:
On Mar 6, 6:46 am, Francois Grieu 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/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
context->count est de type u_int64_t; il aurait fallu
context->count += ((u_int64_t )len << 3);
François Grieu
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/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
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
context->count est de type u_int64_t; il aurait fallu
context->count += ((u_int64_t )len << 3);
François Grieu
ptilou
On Mar 6, 7:47 pm, Francois Grieu wrote:
In article ,
"ptilou" wrote:
On Mar 6, 6:46 am, Francois Grieu 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é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
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
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é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
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 ?
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
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
Dans l'article , "ptilou" écrit:
On Mar 6, 7:47 pm, Francois Grieu 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
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.
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
* Francois Grieu 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
* 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.
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
On Mar 7, 9:03 am, Damien Wyart wrote:
* Francois Grieu 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 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
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 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 ?
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 ?
