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

[David Shaw]

On Tue, Jul 16, 2002 at 10:21:45PM +0000, Brian M. Carlson wrote:
> On Mon, Jul 15, 2002 at 11:44:23PM -0400, David Shaw wrote:
> > On Tue, Jul 16, 2002 at 12:10:47AM +0000, Brian M. Carlson wrote:
> > > On Mon, Jul 15, 2002 at 05:55:49PM -0400, David Shaw wrote:
> > 
> > > > Look at it in terms of functionality.  Let's say I'm encrypting a
> > > > message to you, and the question arises whether to compress it, and
> > > > what algorithm to use.  I consult your compression preferences and see
> > > > that you allow ZLIB only.  My implementation can only do ZIP.  Now we
> > > > cannot communicate.  The answer is, of course, to not to compress -
> > > > which would violate your interpretation of the RFC.  Again: if I do
> > > > not use the implied "uncompressed" setting at the end of your list,
> > > > then we cannot communicate at all.
> > > 
> > > You have a valid point. However, 12.2.1 goes on to say, "Additionally, an
> > > implementation MUST implement this preference to the degree of
> > > recognizing when to send an uncompressed message. A robust implementation
> > > would satisfy this requirement by looking at the recipient's preference
> > > and acting accordingly. A minimal implementation can satisfy this
> > > requirement by never generating a compressed message, since all
> > > implementations can handle messages that have not been compressed." I
> > > think this solves that problem. The implied uncompressed setting
> > > should be at the end of this list when there is a conflict so a message
> > > can be generated.
> > 
> > Indeed, this is my point, and this is exactly what GnuPG does.  If
> > there is no "uncompressed" anywhere in the list, it is added to the
> > end.
> 
> But this should not be displayed if the user did not choose such an
> algorithm. That is lying to the user.

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.

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

What exactly are we arguing about here?  That I'm calling it a
"preference", that the user can see it, or that it is used as the
last-ditch hash choice?

Anyway, we're going in circles now, so let me summarize with the
example again:

1) All OpenPGP programs have SHA1.
2) Your implementation has RIPEMD160, TIGER192, and SHA1.
3) Your preferences are RIPEMD160 and TIGER192.
4) My implementation has only SHA1.

Now, I want to encrypt and sign a message to you. What does my
implementation do:

a) fail     (unacceptable)
b) use SHA1 (remember - I know you have it because ALL OpenPGP
	     programs have it by definition)
c) other    (??)

I won't do a), and you seem to fear b).  I'm all ears if you have a
good c).  Bear in mind that in OpenPGP, the SENDER controls what hash
algorithms are used.  NOT THE RECEIVER.  The most the receiver can do
is say (via the preference list): "please use one of these
algorithms".  You don't get to tell other users they can't use SHA1.
That's their choice.

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