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 ? )
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
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)
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
F. Senault
Damien Wyart écrivait :
* 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 ^^^^^^^
EUh, 4.0 c'est très vieux, freeBSD en est au 6.2
M'est avis qu'il y a eu une petite distraction...
Fred -- I love the smell of burning luser in the morning. (David P. Murphy in the SDM)
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
^^^^^^^
EUh, 4.0 c'est très vieux, freeBSD en est au 6.2
M'est avis qu'il y a eu une petite distraction...
Fred
--
I love the smell of burning luser in the morning.
(David P. Murphy in the SDM)
Non. Voir dans FreeBSD 4.0 (17 septembre 2006) ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz ^^^^^^^
EUh, 4.0 c'est très vieux, freeBSD en est au 6.2
M'est avis qu'il y a eu une petite distraction...
Oui, je crois...
-- Erwan
Benoit Izac
Bonjour,
le 07/03/2007 à 08:07, Francois Grieu a écrit dans le message :
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) ^^^^^^^
OpenBSD
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz (attention c'est gros).
On peut consulter les sources et historiques en ligne sur le cvsweb : http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/sha1.c
-- Benoit Izac
Bonjour,
le 07/03/2007 à 08:07, Francois Grieu a écrit dans le message
<fgrieu-F2C019.08075407032007@news-1.proxad.net> :
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)
^^^^^^^
OpenBSD
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz
(attention c'est gros).
On peut consulter les sources et historiques en ligne sur le cvsweb :
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/sha1.c
le 07/03/2007 à 08:07, Francois Grieu a écrit dans le message :
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) ^^^^^^^
OpenBSD
ftp://ftp.crans.org/pub/OpenBSD/4.0/src.tar.gz (attention c'est gros).
On peut consulter les sources et historiques en ligne sur le cvsweb : http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/sha1.c
-- Benoit Izac
Francois Grieu
On 7 mar, 09:03, 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). 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.
Je viens de passer 30 minutes à faire un email de bug report à OpenBSD. Ma conscience est donc maintenant en paix.
François Grieu
On 7 mar, 09:03, 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).
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.
Je viens de passer 30 minutes à faire un email de bug report à
OpenBSD.
Ma conscience est donc maintenant en paix.
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 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.
Je viens de passer 30 minutes à faire un email de bug report à OpenBSD. Ma conscience est donc maintenant en paix.
François Grieu
Francois Grieu
Erwan David a écrit:
* 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).
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)
Désolé d'avoir mélangé FreeBSD et OpenBSD (c'est un coup à me faire attaquer par les deux camps, ça). Tout ce que j'avais écrit s'appliquer à OpenBSD 4.0 et antérieur, C'est ma ligne voir.. qui est mauvaise (l'URL est bien vers OpenBSD).
Et dans FreeBSD c'est corrigé au moins là où j'ai regardé:
l=(c->Nl+(((HASH_LONG)len)<<3))&0xffffffffUL; /* 95-05-24 eay Fixed a bug with the overflow handling, thanks to * Wei Dai for pointing it out. */ if (l < c->Nl) /* overflow */ c->Nh++; c->Nh+=(len>>29); /* might cause compiler warning on 16-bit */ c->Nl=l;
François Grieu
Erwan David <erwan@rail.eu.org> a écrit:
* 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).
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)
Désolé d'avoir mélangé FreeBSD et OpenBSD (c'est un coup à me
faire attaquer par les deux camps, ça).
Tout ce que j'avais écrit s'appliquer à OpenBSD 4.0 et antérieur,
C'est ma ligne voir.. qui est mauvaise (l'URL est bien vers OpenBSD).
Et dans FreeBSD c'est corrigé au moins là où j'ai regardé:
l=(c->Nl+(((HASH_LONG)len)<<3))&0xffffffffUL;
/* 95-05-24 eay Fixed a bug with the overflow handling, thanks to
* Wei Dai <weidai@eskimo.com> for pointing it out. */
if (l < c->Nl) /* overflow */
c->Nh++;
c->Nh+=(len>>29); /* might cause compiler warning on 16-bit */
c->Nl=l;
* 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).
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)
Désolé d'avoir mélangé FreeBSD et OpenBSD (c'est un coup à me faire attaquer par les deux camps, ça). Tout ce que j'avais écrit s'appliquer à OpenBSD 4.0 et antérieur, C'est ma ligne voir.. qui est mauvaise (l'URL est bien vers OpenBSD).
Et dans FreeBSD c'est corrigé au moins là où j'ai regardé:
l=(c->Nl+(((HASH_LONG)len)<<3))&0xffffffffUL; /* 95-05-24 eay Fixed a bug with the overflow handling, thanks to * Wei Dai for pointing it out. */ if (l < c->Nl) /* overflow */ c->Nh++; c->Nh+=(len>>29); /* might cause compiler warning on 16-bit */ c->Nl=l;
François Grieu
Francois Grieu
In article , Francois Grieu wrote:
J'ai même trouvé, parmis de multiples variantes de sha1_update dans OpenBSD 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);
Eh bien mon code est subtilement faux: il ne fonctionne pas si unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible dans l'absolu. Maintenant je pense qu'il faudrait écrire:
[je commence à comprendre pourquoi ce bug persiste, et à regretter de m'y être attaqué, quel gouffre..]
François Grieu
In article <fgrieu-F2C019.08075407032007@news-1.proxad.net>,
Francois Grieu <fgrieu@gmail.com> wrote:
J'ai même trouvé, parmis de multiples variantes de sha1_update
dans OpenBSD 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);
Eh bien mon code est subtilement faux: il ne fonctionne pas si
unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible
dans l'absolu. Maintenant je pense qu'il faudrait écrire:
J'ai même trouvé, parmis de multiples variantes de sha1_update dans OpenBSD 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);
Eh bien mon code est subtilement faux: il ne fonctionne pas si unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible dans l'absolu. Maintenant je pense qu'il faudrait écrire:
[je commence à comprendre pourquoi ce bug persiste, et à regretter de m'y être attaqué, quel gouffre..]
Est-ce que les vecteurs de tests que tu avais donnés, mettent en évidence ce bug ?
Bon courage !
Francois Grieu
On 8 mar, 15:14, Steph wrote:
[je commence à comprendre pourquoi ce bug persiste, et à regretter de m'y être attaqué, quel gouffre..]
Est-ce que les vecteurs de tests que tu avais donnés, mettent en évidence ce bug ?
Non pour les vecteurs pointés par cette page dont j'avais donné l'adresse http://csrc.nist.gov/cryptval/shs.htm
Oui pour ces vecteurs produits il y a longtemps en collaboration avec Jim Gillogly pour palier à l'insuffisance des vecteurs de test 'bit' alors disponibles, et en particulier les problèmes autour de 4Gbit, mais seulement si le test comprend le traitement d'un vecteur de test en un seul gros bloc http://google.fr/group/sci.crypt/msg/bdd5ed44cca69331?dmode=source
François Grieu
On 8 mar, 15:14, Steph <s...@paspam.nospam> wrote:
[je commence à comprendre pourquoi ce bug persiste, et à regretter
de m'y être attaqué, quel gouffre..]
Est-ce que les vecteurs de tests que tu avais donnés, mettent en
évidence ce bug ?
Non pour les vecteurs pointés par cette page dont j'avais donné
l'adresse
http://csrc.nist.gov/cryptval/shs.htm
Oui pour ces vecteurs produits il y a longtemps en collaboration
avec Jim Gillogly pour palier à l'insuffisance des vecteurs de test
'bit'
alors disponibles, et en particulier les problèmes autour de 4Gbit,
mais seulement si le test comprend le traitement d'un vecteur de
test en un seul gros bloc
http://google.fr/group/sci.crypt/msg/bdd5ed44cca69331?dmode=source
[je commence à comprendre pourquoi ce bug persiste, et à regretter de m'y être attaqué, quel gouffre..]
Est-ce que les vecteurs de tests que tu avais donnés, mettent en évidence ce bug ?
Non pour les vecteurs pointés par cette page dont j'avais donné l'adresse http://csrc.nist.gov/cryptval/shs.htm
Oui pour ces vecteurs produits il y a longtemps en collaboration avec Jim Gillogly pour palier à l'insuffisance des vecteurs de test 'bit' alors disponibles, et en particulier les problèmes autour de 4Gbit, mais seulement si le test comprend le traitement d'un vecteur de test en un seul gros bloc http://google.fr/group/sci.crypt/msg/bdd5ed44cca69331?dmode=source
François Grieu
Sylvain
Francois Grieu wrote on 08/03/2007 14:54:
Eh bien mon code est subtilement faux: il ne fonctionne pas si unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible dans l'absolu. Maintenant je pense qu'il faudrait écrire:
ne peut-on pas estimer/espérer justement que les CPU sont soit: - 64 bits et gérer le compteur de bits sur une seule var. int64, - 32 bits mais utilisés avec un compilo proposant un long long 64 bits, - 8 bits et tout gérer à la main ou brider la taille maximale supporté (pour un chip carte, par exemple, je ne me vois traiter des Go par un tel chip de toute façon).
je ne connais pas assez les cartes HSM pour savoir si leur hard est un 32 bits strict ...
Sylvain.
Francois Grieu wrote on 08/03/2007 14:54:
Eh bien mon code est subtilement faux: il ne fonctionne pas si
unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible
dans l'absolu. Maintenant je pense qu'il faudrait écrire:
ne peut-on pas estimer/espérer justement que les CPU sont soit:
- 64 bits et gérer le compteur de bits sur une seule var. int64,
- 32 bits mais utilisés avec un compilo proposant un long long 64 bits,
- 8 bits et tout gérer à la main ou brider la taille maximale supporté
(pour un chip carte, par exemple, je ne me vois traiter des Go par un
tel chip de toute façon).
je ne connais pas assez les cartes HSM pour savoir si leur hard est un
32 bits strict ...
Eh bien mon code est subtilement faux: il ne fonctionne pas si unsigned int fait plus de 32 bits, ce qui n'a rien d'impossible dans l'absolu. Maintenant je pense qu'il faudrait écrire:
ne peut-on pas estimer/espérer justement que les CPU sont soit: - 64 bits et gérer le compteur de bits sur une seule var. int64, - 32 bits mais utilisés avec un compilo proposant un long long 64 bits, - 8 bits et tout gérer à la main ou brider la taille maximale supporté (pour un chip carte, par exemple, je ne me vois traiter des Go par un tel chip de toute façon).
je ne connais pas assez les cartes HSM pour savoir si leur hard est un 32 bits strict ...
