Re: Suggested changes for DSA2, take 4

hal@finney.org ("Hal Finney") Wed, 29 March 2006 19:04 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfyT-0001hk-47 for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 14:04:57 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfyR-00048B-PF for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 14:04:57 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl6hj059523; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TIl6X3059522; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl53l059516 for <ietf-openpgp@imc.org>; Wed, 29 Mar 2006 11:47:05 -0700 (MST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id E0E5A57FAE; Wed, 29 Mar 2006 10:45:30 -0800 (PST)
To: ben@algroup.co.uk, ietf-openpgp@imc.org
Subject: Re: Suggested changes for DSA2, take 4
Message-Id: <20060329184530.E0E5A57FAE@finney.org>
Date: Wed, 29 Mar 2006 10:45:30 -0800
From: hal@finney.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

Ben Laurie writes:
> Slightly late to the party here, but I should note that hash truncation
> is not an operation that is thoroughly approved of. In particular I
> would worry that if it is permitted a cunning attacker might be able to
> choose a new q s.t. the signature still validated on a much shorter
> version of the hash, and thus show a valid signature on the wrong
> document. I would therefore suggest that we do _not_ permit arbitrary
> truncation of hashes.

I don't understand what you are proposing here.  To choose a new q means
to create a new key: a new (p, q, g, x, y) tuple.  Then you are worried
that an existing (r, s) signature could be made to work with this new key?
I don't see why this would be a concern even if it worked; and it could be
eliminated by checking that r and s are < q, which you should do anyway.

The NIST standard supports arbitrary truncation of (strong) hashes, and
if it were that risky I doubt very much that it would have gotten in.
John Kelsey at NIST is one of the top people in the field today and I
am sure this has been reviewed by him and other cryptographers.

Hal Finney