sha1 hash using libgcrypt different from what returns sha1sum
wk at gnupg.org
Wed Nov 13 09:55:00 CET 2013
On Tue, 12 Nov 2013 22:17, yumkam at gmail.com said:
> I guess, same apply to signatures? (and it is not only sha1, it's most other
> hashes [except of sha384 and sha512] too)
> Actually, it won't add much time on *processing* - you can produce both versions
> at nearly same cost as one, only *final method needs to be different to produce
> both versions (one with counter truncation, one without).
> (But I guess it will take lot of time on *designing proper API* for such hack;
Right, that is a major problem. For GnuPG-1 this would be easy but
GnuPG-2 uses Libgcrypt and adding a bug comatibility interface is not easy.
> And I'm not sure, but cipher-ccm.c also feels suspicious in this respect (won't
> it fail after SIZE_T_MAX bytes?).
We need to look at it.
> Strictly speaking, libgcrypt's sha512 and whirlpool are "broken" too - standard
> limits message size with 2**128 bits (more for whirlpool), and so libgcrypt
> sha512 will also fail after about 2**73 + 127 bytes. But I guess, unlike
> *md*/sha*, it won't become practical problem for some quite time :-).
I wonder how we could do a regression test or get test vectors in the
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel