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

[David Shaw]

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 ;)

> > > SHA1 is MUST-implement, yes. There are times when there are no mutually
> > > agreeable hashes, yes. If there is a mutually agreeable hash, it should
> > > be chosen. Adding SHA1 gives preference to a hash that was never there.
> > 
> > Preference is perhaps the wrong word here.  The implied "preference"
> > for SHA1 does not imply that SHA1 is favored or even a good choice.
> > All it means is that **if all else fails**, we still have a hash
> > algorithm.
> 
> I think a different algorithm for choosing the last-ditch hash algorithm
> would be better.

I'm all for placing additional smarts before we must resort to using
the last-ditch hash algorithm (see below for discussion), but the
last, last, last-ditch algorithm must always be SHA1 as it is the only
algorithm that is guaranteed to be present in all OpenPGP
implementations.  Since no other algorithm has that crucial feature,
none of them can be used as a the last-ditch choice.  Or to put it
differently, why use a last-ditch choice that may or may not work,
when we can use a last-ditch choice that will *always* work?

> I quite understand that I can't dictate to other users what hash
> algorithms they can or can't use. That's not what I'm trying to
> do. Should there not be a compatible algorithm, I have a whole host of
> suggestions:
> 
> 	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.

c) is not a viable solution.  We already know that there is no
compatible algorithm to have gotten that far, so choosing anything on
the sender's list other than SHA1 is likely to result in an unusable
message.  I'm all for letting people shoot themselves in the foot if
they really want to, as I'm sure you remember with the
cert-digest-algo discussions, but foot shooting must not be the
default behavior. :) There is always --digest-algo if someone wants to
override the default.

> 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.

It's starting to sound like what you want is a
--personal-digest-preferences that acts more like --digest-algo: if it
can negotiate gracefully, fine, but if it can't then act like
--digest-algo and force the issue.

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