sha1 hash using libgcrypt different from what returns sha1sum

[Werner Koch]

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)

Yes.

> 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
first place.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.