WARNING: signature digest conflict in message ?

[Matija Nalis]

On Thu, Sep 25, 2008 at 08:54:58AM -0400, David Shaw wrote:
> On Sep 25, 2008, at 8:05 AM, Matija Nalis wrote:
> >Would it be possible in such a case to try to deduce the hash used
> >from signature, before (or instead of) falling back to assuming it is
> >MD5 ? I see no reason why it couldn't be possible.
> 
> Verifying a clear signature uses the Hash: header to set up the hash  
> context, then the data is hashed, then the signature is read - in that  
> order.  If GPG is getting the clear signatures in a stream it would  
> have to buffer all the data until it finds out what the hash is by  
> reading the signature, then go back and hash the data.  If the data is  
> large, that may not be possible.

Thanks David! (for crushing my hopes before they get too developed :-)

That is indeed very reasonable (I didn't think of big non-seekable
stream and was hoping for 2-pass or buffer) and obviously the right
way to do it, not to mention conforming to RFC.

(although as alternative it might also sequentially generate all
supported hashes as it goes, and then drop the unneeded ones; but
this would also be an inexcusable waste of resources)

> What is generating these messages in the first place?  Why not fix  
> that?  I know your sample message was signed by GPG, but GPG puts the  
> right Hash headers in.  Is something stripping them out?

Yes, I was just using gpg + editor for making reproducible test case.
The broken software is above mentioned pgpverify (for example, broken
version can be found at
ftp://ftp.isc.org/pub/pgpcontrol/ARCHIVE/pgpverify-1.15 ) which
attempted to make its own clearsign version (without "Hash" header)
and then call "gpg --verify" on it - which failed unless you used
MD5.

Although the pgpverify was fixed years ago (by switching to use
detached signatures), there are a lot of sites still using older INN
installations (and there are some good reasons for people not wanting
to upgrade INN once it is working) which still have broken pgpverify.

So I was hoping perhaps if gnupg could be easily fixed to autodetect
signature type in this case, than just gpg could get upgraded
(leaving custom inn unmodified) and thus fixing situation - which
would be much easier than making newsadmins all over the world
upgrade their custom INN installations (and might even happen
automatically over time when they upgrade their distros).

Unfortunately for me, that avenue does not look reasonable anymore.

I guess there is also NO way gpg (or something) could be forced to
use MD5 with DSA key for signing (as "--digest-algo md5" gives me
"DSA key XXXXXXXX requires a 160 bit or larger hash" error) ?

So probably only reasonable (for some flexible definition of
reasonable :-) thing for me is to either start a crusade to make all
newsadmins upgrade their INN (or at least replace pgpverify part of
it), or to start using RSA key and forcing MD5 hash on it, which I
wanted to avoid if at all possible (as it requires changing usenet
hierarchy key, for which is there no good key-exchange mechanism, so
I also get to contact all newsadmins across the world)

Thanks again, perhaps this discussion will help some new newsadmin to
*NOT* use DSA key, but old 1024 bit RSA for signing Usenet control
messages. (or at least if they did choose DSA, and google finds them
this post with error message, to realize they're doomed quick enough :-)

-- 
Opinions above are GNU-copylefted.