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

Brian M. Carlson
Wed Jul 17 02:01:02 2002

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 16, 2002 at 06:57:01PM -0400, David Shaw wrote:
> 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:
> > >=20
> > > > > 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, a=
> > > > > what algorithm to use.  I consult your compression preferences an=
d see
> > > > > that you allow ZLIB only.  My implementation can only do ZIP.  No=
w we
> > > > > cannot communicate.  The answer is, of course, to not to compress=
> > > > > which would violate your interpretation of the RFC.  Again: if I =
> > > > > not use the implied "uncompressed" setting at the end of your lis=
> > > > > then we cannot communicate at all.
> > > >=20
> > > > You have a valid point. However, 12.2.1 goes on to say, "Additional=
ly, an
> > > > implementation MUST implement this preference to the degree of
> > > > recognizing when to send an uncompressed message. A robust implemen=
> > > > would satisfy this requirement by looking at the recipient's prefer=
> > > > 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."=
> > > > think this solves that problem. The implied uncompressed setting
> > > > should be at the end of this list when there is a conflict so a mes=
> > > > can be generated.
> > >=20
> > > 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.
> >=20
> > 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.

This should be documented.
> > 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.

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

I think we're arguing about using it 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:

It uses SHA1.
> 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.

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

	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. I much prefer d), then somewhat
c), then less e).

Brian M. Carlson <> <> 0x560553=
"Don't worry about people stealing your ideas.	 If your ideas are any good,=
you'll have to ram them down people's throats."
 -- Howard Aiken

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.1.90 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

Signature policy: