Non-cipher preferences (Was: Re: --override-session-key $PASS simple brute force attack vulnerability?)

[David Shaw]

On Wed, Jul 17, 2002 at 04:06:43AM +0000, Brian M. Carlson wrote:
> On Tue, Jul 16, 2002 at 11:06:42PM -0400, David Shaw wrote:
> > On Wed, Jul 17, 2002 at 12:01:47AM +0000, Brian M. Carlson wrote:
> > > On Tue, Jul 16, 2002 at 06:57:01PM -0400, David Shaw wrote:
> > 
> > > > If the user selects "showpref", GnuPG shows what the preferences are
> > > > *in effect*.  That is, including 3DES/SHA1/Uncompressed if they are
> > > > not already present.  This is because GnuPG is going to act on those
> > > > pseudo-preferences whether or not they are physically present.
> > >  
> > > > If the user selects "pref", GnuPG shows what the preferences are *on
> > > > the key*.  If the key owner hates SHA1, then they can leave it out and
> > > > it won't sully their display.  Either way, it doesn't change that
> > > > GnuPG is going to use the implied preferences if all else fails.
> > > 
> > > This should be documented.
> > 
> > Hey, give me a chance.  1.2 isn't even released yet.  You're using the
> > development version ;)
> 
> I can deal with that.

You could write that bit for the documentation too you know... :)

> > > 	c) use the first algorithm on the SENDER's list.
> > > 	d) use the intersection of personal-digest-preferences and the
> > > 	RECIPIENT's list if it (the intersection) is non-null, otherwise c).
> > > 	e) print a warning message, and use SHA1 anyway.
> > > 
> > > I think d) is courteous, c) is pragmatic, and e) is to let people know
> > > that negotiation failed. The reason I prefer e) over b) is because we
> > > warn people when cipher algorithm negotiation failed, and I see no reason
> > > not to do so with hash algorithms also.
> > 
> > That's not exactly how it works.  There is a warning on the recipient
> > side if the cipher used in a message is not one of those ciphers in
> > the recipient's preferences, but since 3DES is always in those
> > preferences (whether we call this a "real" preference or not) a
> > warning is never printed for a message encrypted in 3DES.  This is as
> > per section 12.1 of 2440bis-05.  Translating this idea over to hashes
> > may have merit, but it also means that there would be no warning for
> > SHA1 in particular.
> 
> I understand this. But the negotiation has to happen for ciphers on
> sender's side, and it is ultimately the recipient's choice. But here it
> happens on the sender's side, and it is the sender's choice. I figure we
> should warn the person whose choice it is.

I don't quite agree: all negotiations, whether cipher, hash, or
compression, happen on the sender's side, and are ultimately the
sender's choice.  The sender is king.  The RFC bans any sender for
using a cipher that the recipient cannot use (and the sender would be
foolish at best to do so), but the sender can still do it.  That's
just wordplay though.  We're basically talking about the same thing
here.

In any event, the version of GnuPG you are using has a warning for
this already: "forcing digest algorithm "foo" violates recipient
preferences".  Note that this does not apply to a sender using SHA1 -
the warning is to warn about a violation of the preferences, and using
SHA1 does not violate preferences (implied preferences, if you wish).
Note also that this warning only appears if the user forces a
non-listed algorithm with --digest-algo.  Unless the sender takes
intentional action to override the default behavior, GnuPG will never
violate the preference list.

> > > I much prefer d), then somewhat c), then less e).
> > 
> > I'm sure you'll be pleased to know that d) is in fact the default
> > behavior in GnuPG for a non-null intersection.  A null intersection,
> > of course, is SHA1.
> 
> We are progressing. Excellent! All we've got to figure out is that last
> point for the null intersection.

You couldn't tell that was the behavior?  That feature is in the
version of GnuPG you are using.  Documented, too ;)

> As you said, it's the sender's choice. But I'm willing to stick with
> SHA1 as the default choice. (I can see my arm being twisted around 20
> radians.) But can we make it e) instead of b)? Please?

It will be e) in 1.2 (and is already e) in 1.1.x), but as I noted
earlier, that does not apply to SHA1.

Even if the other reasons I gave above did not apply, there is a less
theoretical problem: keys generated with PGP do not provide a hash
algorithm list at all.  This is perfectly legal (it is interpreted as
a list containing only the implied SHA1), but if there was a warning
when SHA1 was used when it was not physically in the list, barring
some special hack to avoid it, this would cause a warning every single
time someone encrypted&signed to a PGP user, which is unacceptable.

> However, I would like to point out, before this discussion on hash
> algorithms ends, that TIGER192 cannot be used for signing because with
> DSA it is too large and with RSA and Elgamal it does not have a proper
> ASN.1 OID for the PKCS encoding.

Yes.  You can only really use it with other GnuPG users (which is not
a big problem since no other implementation has it anyway...)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson