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 ? )
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).
Euh, et le Hasch de S/mime par rapport à sha1, plus sur ou moins sur ?
Ptilou
Bonjour,
On 8 mar, 23:28, Sylvain <noS...@mail.net> wrote:
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).
Euh, et le Hasch de S/mime par rapport à sha1, plus sur ou moins sur ?
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).
Euh, et le Hasch de S/mime par rapport à sha1, plus sur ou moins sur ?
Ptilou
Francois Grieu
"ptilou" a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
Et serait-on revenu au problème du risque de collisions, explicitement exclu au début de ce fil? http://google.fr/groups?selm
François Grieu
"ptilou" <ptilou@gmail.com> a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la
spécification S/MIME, ou une implémentation de S/MIME ?
Dans les deux cas, laquelle, et dans ce contexte qu'est-ce
que "Le hash de S/MIME" ?
Et serait-on revenu au problème du risque de collisions,
explicitement exclu au début de ce fil?
http://google.fr/groups?selm72929735.409227.54780@30g2000cwc.googlegroups.com
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
Et serait-on revenu au problème du risque de collisions, explicitement exclu au début de ce fil? http://google.fr/groups?selm
François Grieu
ptilou
Bonjour, ou re,
On Mar 9, 1:07 pm, Francois Grieu wrote:
"ptilou" a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459 Je pense à la spécification ! ( Si je parle d'implémentation, la volet de bois vert, n'est pas loin ... )
Et serait-on revenu au problème du risque de collisions, explicitement exclu au début de ce fil? http://google.fr/groups?selm roups.com
Pour moi, cette histoire de collision, me sembler être plus probable, sur de petit paquet que des gros ! ( Mais il est certaint que je ne suis même pas la cinquième roue du carrosse dans ce jargon . )
Ptilou
Bonjour, ou re,
On Mar 9, 1:07 pm, Francois Grieu <fgr...@gmail.com> wrote:
"ptilou" <pti...@gmail.com> a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la
spécification S/MIME, ou une implémentation de S/MIME ?
Dans les deux cas, laquelle, et dans ce contexte qu'est-ce
que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459
Je pense à la spécification ! ( Si je parle d'implémentation, la volet
de bois vert, n'est pas loin ... )
Et serait-on revenu au problème du risque de collisions,
explicitement exclu au début de ce fil?
http://google.fr/groups?selm=1172929735.409227.54...@30g2000cwc.googleg roups.com
Pour moi, cette histoire de collision, me sembler être plus probable,
sur de petit paquet que des gros !
( Mais il est certaint que je ne suis même pas la cinquième roue du
carrosse dans ce jargon . )
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459 Je pense à la spécification ! ( Si je parle d'implémentation, la volet de bois vert, n'est pas loin ... )
Et serait-on revenu au problème du risque de collisions, explicitement exclu au début de ce fil? http://google.fr/groups?selm roups.com
Pour moi, cette histoire de collision, me sembler être plus probable, sur de petit paquet que des gros ! ( Mais il est certaint que je ne suis même pas la cinquième roue du carrosse dans ce jargon . )
Ptilou
ptilou
On Mar 9, 10:10 pm, Erwan David wrote:
"ptilou" écrivait :
Bonjour, ou re,
On Mar 9, 1:07 pm, Francois Grieu wrote:
"ptilou" a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459 Je pense à la spécification ! ( Si je parle d'implémentation, la volet de bois vert, n'est pas loin ... )
Le hash peut être MD5, SHA-1, SHA-256 ou autre... La spécification ne l'impose pas.
Donc voyons les choses autrement, si je mes des variables commes le
nombres de caractères et le nombres d'un caractères le plus utilisés plus trois autre variables ( nbrs de page, de ligne, de paragraphe ) la quelle des deux solution à le plus de risque de collision et pouquoi ? ( surtout, avec calcul de probabilité ... )
Ptilou
On Mar 9, 10:10 pm, Erwan David <e...@rail.eu.org> wrote:
"ptilou" <pti...@gmail.com> écrivait :
Bonjour, ou re,
On Mar 9, 1:07 pm, Francois Grieu <fgr...@gmail.com> wrote:
"ptilou" <pti...@gmail.com> a écrit à peu de chose près:
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la
spécification S/MIME, ou une implémentation de S/MIME ?
Dans les deux cas, laquelle, et dans ce contexte qu'est-ce
que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459
Je pense à la spécification ! ( Si je parle d'implémentation, la volet
de bois vert, n'est pas loin ... )
Le hash peut être MD5, SHA-1, SHA-256 ou autre... La spécification ne
l'impose pas.
Donc voyons les choses autrement, si je mes des variables commes le
nombres de caractères et le nombres d'un caractères le plus utilisés
plus trois autre variables ( nbrs de page, de ligne, de paragraphe )
la quelle des deux solution à le plus de risque de collision et
pouquoi ? ( surtout, avec calcul de probabilité ... )
Le hash de S/MIME par rapport à SHA-1, plus sur ou moins sur ?
Je ne saisis pas la question. Déjà "S/MIME" désigne la spécification S/MIME, ou une implémentation de S/MIME ? Dans les deux cas, laquelle, et dans ce contexte qu'est-ce que "Le hash de S/MIME" ?
rfc 2045 et s puis 2387 et 3459 Je pense à la spécification ! ( Si je parle d'implémentation, la volet de bois vert, n'est pas loin ... )
Le hash peut être MD5, SHA-1, SHA-256 ou autre... La spécification ne l'impose pas.
Donc voyons les choses autrement, si je mes des variables commes le
nombres de caractères et le nombres d'un caractères le plus utilisés plus trois autre variables ( nbrs de page, de ligne, de paragraphe ) la quelle des deux solution à le plus de risque de collision et pouquoi ? ( surtout, avec calcul de probabilité ... )
Ptilou
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.
(je repose, reformule)
a) constatant que ma propre implémentation, évidemment, est buggé pour un bloc d'entrée de 512Mo, b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé 2 compteurs int32 au lieu d'un seul int64, c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privilégier 2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le compilo le permet ?
ma question me semble un peu idiote, merci de ne insister que sur ce point dans vos réponses ;)
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.
(je repose, reformule)
a) constatant que ma propre implémentation, évidemment, est buggé pour
un bloc d'entrée de 512Mo,
b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé 2
compteurs int32 au lieu d'un seul int64,
c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privilégier
2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le
compilo le permet ?
ma question me semble un peu idiote, merci de ne insister que sur ce
point dans vos réponses ;)
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.
(je repose, reformule)
a) constatant que ma propre implémentation, évidemment, est buggé pour un bloc d'entrée de 512Mo, b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé 2 compteurs int32 au lieu d'un seul int64, c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privilégier 2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le compilo le permet ?
ma question me semble un peu idiote, merci de ne insister que sur ce point dans vos réponses ;)
Sylvain.
Francois Grieu
On 10 mar, 01:24, Sylvain wrote:
a) constatant que ma propre implémentation (de SHA1) est buggé pour un bloc d'entrée de 512Mo, b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé 2 compteurs int32 au lieu d'un seul int64, c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privil égier 2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le compilo le permet ?
Il est parfaitement possible d'utiliser un type 64 bits pour le compteur de SHA, à condition de le découper en deux mots de 32 bits au moment de le mettre à la fin du dernier bloc (sans cette précaution, on serait dépendant de l'ordre des mots sur la machine cible).
Dans le genre variante pas connes du hash de base, j'aime bien celle où le compteur compte les octets (et non de bits), jusqu'à la finalisation où l'on le transorme en compteur de bits. C'est un poil plus rapide, et surtout il devient quasi impossible d'avoir un problème avec les blocs de 512 Mo.
François Grieu
On 10 mar, 01:24, Sylvain <noS...@mail.net> wrote:
a) constatant que ma propre implémentation (de SHA1) est buggé
pour un bloc d'entrée de 512Mo,
b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé
2 compteurs int32 au lieu d'un seul int64,
c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privil égier
2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le
compilo le permet ?
Il est parfaitement possible d'utiliser un type 64 bits pour le
compteur
de SHA, à condition de le découper en deux mots de 32 bits au
moment de le mettre à la fin du dernier bloc (sans cette précaution,
on serait dépendant de l'ordre des mots sur la machine cible).
Dans le genre variante pas connes du hash de base, j'aime bien
celle où le compteur compte les octets (et non de bits), jusqu'à
la finalisation où l'on le transorme en compteur de bits. C'est un
poil plus rapide, et surtout il devient quasi impossible d'avoir un
problème avec les blocs de 512 Mo.
a) constatant que ma propre implémentation (de SHA1) est buggé pour un bloc d'entrée de 512Mo, b) me comprenant pas pourquoi (au delà d'un mimétisme) j'ai utilisé 2 compteurs int32 au lieu d'un seul int64, c) ne voyant pas d'effet négatif à remplacer ce compteur par un int64
aurais-je loupé un détail ou cas particulier qui justifie de privil égier 2 int32 ou, en effet, ce compteur peut être un int64 si le hard / le compilo le permet ?
Il est parfaitement possible d'utiliser un type 64 bits pour le compteur de SHA, à condition de le découper en deux mots de 32 bits au moment de le mettre à la fin du dernier bloc (sans cette précaution, on serait dépendant de l'ordre des mots sur la machine cible).
Dans le genre variante pas connes du hash de base, j'aime bien celle où le compteur compte les octets (et non de bits), jusqu'à la finalisation où l'on le transorme en compteur de bits. C'est un poil plus rapide, et surtout il devient quasi impossible d'avoir un problème avec les blocs de 512 Mo.
François Grieu
Sylvain
Francois Grieu wrote on 10/03/2007 08:57:
Il est parfaitement possible d'utiliser un type 64 bits pour le compteur []
merci pour cet confirmation.
Dans le genre variante pas connes du hash de base, j'aime bien celle où le compteur compte les octets (et non de bits) []
;) c'est vrai que je n'ai jamais à traiter de flux de bits de longueur non multiple de 8.
Sylvain.
Francois Grieu wrote on 10/03/2007 08:57:
Il est parfaitement possible d'utiliser un type 64 bits pour le
compteur []
merci pour cet confirmation.
Dans le genre variante pas connes du hash de base, j'aime bien
celle où le compteur compte les octets (et non de bits) []
;) c'est vrai que je n'ai jamais à traiter de flux de bits de longueur
non multiple de 8.
