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

[Brian M. Carlson]

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

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, 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.
> >=20
> > 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 implementati=
on
> > 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.
>=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.

But this should not be displayed if the user did not choose such an
algorithm. That is lying to the user.

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

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.

> required, here's the same example as before with SHA1 substituted for
> "uncompressed": I want to encrypt & sign a message to you.  I

But the standard never stated in any way that there should be any
preference for SHA1. In fact, I'll dare to suggest that the only reason
that SHA1 was made MUST-implement was because we decided to use DSA
instead of RSA as MUST-implement.

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

And that is your choice. As a person. It should not be the
implementation's choice. If you want to sign something, you as the
signer get to make the educated decision on algorithms. I think a much
better alternative is to use personal-digest-preferences. If SHA1 is in
there, let's use it. If it's not, let's not.

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

I don't think that the OpenPGP standard states anything in the case of
SHA1 other than that is MUST-implement. And I certainly don't think that
when you display the algorithms, it should display algorithms that are
not, in fact, in the person's preference list.

--=20
Brian M. Carlson <karlsson@hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553=
E7
As Zeus said to Narcissus, "Watch yourself."

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

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

iQFKBAEBAwA0BQI9NJx4LRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w
Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT5yXpB/90t30RXUu2ATHEsW+mPEFRoIjL
7TZ0UFDvIK2CmqWYidnPiNnkQYx4TPB4KtfcziPGgV/D9s9LK3ANzJz06s1U5ZiY
030JaepXQpzM93FstUAko0Yah81Ff/+OZJnkxtoi3N2aChANEh4PI3IEAcgnBedg
frUjC0zLeCDfBfWGQQtXTIcUx1posvL3HlRITMXnWu8ZiFPcWAYZPHJabDMtyDc6
FxIXoF6WFm3qydZBG7KRoHbVGbNDifpo4g4VdWRe9IO1fiU2VZfw254IiUz98hVn
ql1Iw9v7bOfZhki8vxuziLVhk6pxTAA6qIrs5TR/64NMYB5y8lYSl/zTG/VC
=LBnp
-----END PGP SIGNATURE-----
Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--EEx6GiKZGZ1wKUra--