sha1 hash using libgcrypt different from what returns sha1sum

[Philipp Schafft]

On Tue, 2013-11-12 at 15:46 -0500, David Shaw wrote:
> On Nov 12, 2013, at 12:34 PM, Werner Koch <wk at gnupg.org> wrote:
> 
> > On Tue, 12 Nov 2013 00:44, yumkam at gmail.com said:
> > 
> >> I strongly believe this is a bug, I have not found any such
> behavior in standard
> > 
> > You are right.  This is a limitation of the code which was never hit
> in
> > practice until now - at least I hope so.  The more disturbing fact
> is
> > that this also affects GPG encrypted files: SHA-1 is used for an MDC
> to
> > protect the encrtpted messages.  If both parties use GPG, this won't
> be
> > a problem but it is not standard compliant.
> > 
> > [...]
> [...]

> I'm somewhat surprised that this hasn't come up long before, or
> possibly it has and people just accepted (or bypassed) the MDC
> mismatch?

As of my understanding it doesn't generate any warning just that the
hash that is stored is wrong. So maybe it happend very often but nobody
noticed because if it happens on both ends the problem will not show up.

I think that there are little pople like me and Yuriy Kaminskiy that
will have a closer look into the hashing code and do more testing. So
it's hard to find such bugs and then people still need to report it.
Most users of most projects I have be involved are just too lazy to
report problems (but not to lazy to complain on IRC or somewhere ;).

I would also vote for calculating both hashes (of it's really only the
finaling) and print an warning in case it matches the hash caluclated
with the bad implementation. Maybe rejecting it with --batch or
something for rejecting it by default as soon as major operating systems
have updated.


Thank you for your work and many thanks to Yuriy Kaminskiy for
reporting!

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20131114/dd9b129c/attachment.sig>