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

[Brian M. Carlson]

--rPgHZmYkQ+bUEpVC
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=
nd
> > > > > 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 =
do
> > > > > not use the implied "uncompressed" setting at the end of your lis=
t,
> > > > > 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=
tation
> > > > would satisfy this requirement by looking at the recipient's prefer=
ence
> > > > 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 mes=
sage
> > > > 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.
>=20
> 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.
=20
> 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.
=20
> > 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.
>=20
> 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.
=20
> Anyway, we're going in circles now, so let me summarize with the
> example again:
>=20
> 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.

Ok.

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

It uses SHA1.
=20
> a) fail     (unacceptable)
> b) use SHA1 (remember - I know you have it because ALL OpenPGP
> 	     programs have it by definition)
> c) other    (??)
>=20
> 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
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. I much prefer d), then somewhat
c), then less e).

--=20
Brian M. Carlson <karlsson@hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553=
E7
"Don't worry about people stealing your ideas.	 If your ideas are any good,=
=20
you'll have to ram them down people's throats."
 -- Howard Aiken

--rPgHZmYkQ+bUEpVC
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQFKBAEBAwA0BQI9NLPqLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w
Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT52XMB/sHKMoazOBj1npqrVIZZXJb2Zei
dtiFuKTjzgokwpNX8lWnklhylRgQwoZRm7Opk2AbqIuXbZYcA0wX/jfHEhT0Juqu
APUuL46x9OrN/a4yH7x+ptirabrkqrcn6JU3tbliqDbctmfpZcL44skRMk7SWfZv
NYuz5Sg3n5ncq77/Nfa6Wv7sxo0UVmvNcMALCFLtjrvFVNIhYFTVH5XG/k1nMGSW
uj+9keGk+DwlIefDnXS5S+k62UiLeuf/JbwGuzQhxhG4LDqJwz5W7Mtc8W5l6YeD
IDYvR9yWMAqvmqo2gbagQzPnPmwDGaJaKadNKJfz9max9xeq4d43dckACh8a
=eqg/
-----END PGP SIGNATURE-----
Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--rPgHZmYkQ+bUEpVC--