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

[Brian M. Carlson]

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

On Tue, Jul 16, 2002 at 11:06:42PM -0400, David Shaw wrote:
> 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:
>=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.
> >=20
> > This should be documented.
>=20
> Hey, give me a chance.  1.2 isn't even released yet.  You're using the
> development version ;)

I can deal with that.
=20
> > > > SHA1 is MUST-implement, yes. There are times when there are no mutu=
ally
> > > > agreeable hashes, yes. If there is a mutually agreeable hash, it sh=
ould
> > > > be chosen. Adding SHA1 gives preference to a hash that was never th=
ere.
> > >=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.
> >=20
> > I think a different algorithm for choosing the last-ditch hash algorithm
> > would be better.
>=20
> 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?
>=20
> > 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:
> >=20
> > 	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.
> >=20
> > 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 reas=
on
> > not to do so with hash algorithms also.
>=20
> 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.

I understand this. But the negotiation has to happen for ciphers on
sender's side, and it is ultimately the recipient's choice. But here it
happens on the sender's side, and it is the sender's choice. I figure we
should warn the person whose choice it is.
=20
> 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.
>=20
> > I much prefer d), then somewhat c), then less e).
>=20
> 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.

We are progressing. Excellent! All we've got to figure out is that last
point for the null intersection.
=20
> 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.

As you said, it's the sender's choice. But I'm willing to stick with
SHA1 as the default choice. (I can see my arm being twisted around 20
radians.) But can we make it e) instead of b)? Please?

However, I would like to point out, before this discussion on hash
algorithms ends, that TIGER192 cannot be used for signing because with
DSA it is too large and with RSA and Elgamal it does not have a proper
ASN.1 OID for the PKCS encoding.

There. I'm done.

--=20
Brian M. Carlson <karlsson@hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553=
E7
Modeling paged and segmented memories is tricky business.
		-- P.J. Denning

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

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

iQFKBAEBAwA0BQI9NO1RLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w
Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT59XdB/9roNGJG8kfj+7Ck5jKT0AL8Va5
3Y9dQZSiKbzmELWkw8w7q0Ufg3CuratzdvBsKGDVPuWPEXd6LwJSK8nngGJmU5YZ
tMDvvIqyrnZPjcwj8glZkH41couDOkRDWon3I68ypAzG8mTGL5+mlYrQdCgmA+rq
5yJWDcYt+/4++smlTvZoeTBsBdQnjiMVhsz2KFMQSHqPGU/gnQhc4tA7bD0r/o8Y
vdJS3uYEwdQL3KNs0JbBfg5xrol8El+CwjXydiVhXThwOc8geW4SUFYh6S296tVa
iwofAvlo3jxE5n7BBLdplabtmETHmnPGkbEK/s/5a1iOMLrkQ0zE1YMNQmsm
=lPSg
-----END PGP SIGNATURE-----
Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--z4IKABJTiQIqPwmW--