sha1 hash using libgcrypt different from what returns sha1sum

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Nov 13 22:05:57 CET 2013


On 11/13/2013 02:00 PM, Werner Koch wrote:
> On Wed, 13 Nov 2013 15:57, dkg at fifthhorseman.net said:
> 
>> If you don't mind burning a lot of CPU, it's pretty easy to generate a
>> test vector from /dev/zero ("pee" is from the moreutils package, but
> 
> That is not the problem.  The hashing of 256GB takes alone 14 minutes on
> my box - using the latest optimized code.  Nothing you want to do
> everytime in a regression suite.

yep, agreed, that would be pretty obnoxious for a regression suite.
maybe we should consider a separate "extended regression suite" annex
for people with CPU to burn?  I'm not sure how else to really test this
sort of codepath without testing it.

Maybe we could save and store intermediate digest state in git and make
the test suite load that intermediate state and restart the digest from
most-of-the-way-through?  that kind of seems like cheating though.

> tools/mk-tdata can easily be changed to emit large non-compressable
> blocks.

hm, I was just offering reasonable and clearly-understood test vectors
that are easily available.  I'm not sure non-compressability is a
characteristic we need care about for a test vectors to avoid a
regression into this particular bug.

	--dkg




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131113/b5d00151/attachment.sig>


More information about the Gnupg-devel mailing list