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

[David Shaw]

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.

> The last of the three sets of preferences is hash preferences. Really,
> the signer can ignore the hash preferences and merely do whatever he or
> she likes as far as digest algorithms go (within the bounds of the
> OpenPGP standard). The hash preferences are there so if someone is
> sending, for example, a signed and encrypted message, one could use an
> algorithm that both people find mutually agreeable. There is no need to
> have an implied setting here. Yes, it is generally a good idea to use
> algorithms that are widely known to be implemented (e.g. SHA1, MD5).
> However, if the user chooses to use HAVAL-5-160, that is his or her
> choice. It may not be a wise choice, or a smart choice for
> interoperability, but it is that person's choice, as HAVAL is a valid
> algorithm within the standard. To further state my point: "This
> preference, though, allows a protocol based upon digital signatures ease
> in negotiation." Note the word "allows". It does not say "mandates". It
> does not say "makes REQUIRED". Therefore, I do not think SHA1 (nor any
> other algorithm) belongs at the "implied end" of the hash list.

I see where you are going with this, but I disagree: SHA1 is not
"widely known to be implemented".  Rather, it MUST be implemented in
every OpenPGP implementation (section 9.4).  The problem in your above
statement is the phrase "mutually agreeable".  There are common cases
where there are no mutually agreeable hashes.  So given that SHA1 is
required, here's the same example as before with SHA1 substituted for
"uncompressed": I want to encrypt & sign a message to you.  I
therefore would like to know what hashes you understand.  Your
preference list says "RIPEMD160 and TIGER192".  I, however, am using
an implementation that cannot use either of these algorithms.  I have
a choice of either not communicating, or using SHA1 which I know (due
to it being a MUST) you can handle.

What the OpenPGP spec is doing with the 3DES/Uncompressed/SHA1
MUST-implement algorithms is handling the case where there is no way
to reach agreement on algorithm 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