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

[Brian M. Carlson]

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

On Mon, Jul 15, 2002 at 05:55:49PM -0400, David Shaw wrote:
> On Mon, Jul 15, 2002 at 09:06:59PM +0000, Brian M. Carlson wrote:
> > On Mon, Jul 15, 2002 at 09:33:38AM -0400, David Shaw wrote:
> > > On Mon, Jul 15, 2002 at 11:46:17AM +0000, Brian M. Carlson wrote:
> > > > You can see my preferences here:
> > > > 	Cipher: 3DES, BLOWFISH, CAST5, AES192
> > > > 	Hash: RIPEMD160, TIGER192, SHA1 (that is a nasty extra SHA1 that
> > > > 	shouldn't be there)
> > > > 	Compression: ZLIB, ZIP, Uncompressed
> > > > 	Features: MDC
> > >=20
> > > No, that SHA1 is required by the OpenPGP protocol.  You can put other
> > > hashes in front of it if you prefer, but you can't get rid of it.  The
> > > same thing applies to the 3DES cipher, and the "Uncompressed"
> > > compression type.
> >=20
> > I disagree. I am using as my reference 2440 bis05. Section 12.1
> > specifically states that "Since TripleDES is the MUST-implement
> > algorithm, if it is not explicitly in the list, it is tacitly at the en=
d.
> > However, it is good form to place it there explicitly." Section 12.2
> > states merely: "Other algorithm preferences work similarly to the
> > symmetric algorithm preference, in that they specify which algorithms
> > the keyholder accepts." 12.2.1 merely states that an implementation MUST
> > recognize when to send an uncompressed message, and that if "the
> > preferences are not present, then they are assumed to be [ZIP(1),
> > UNCOMPRESSED(0)]." Note that says if they are not present. 12.2.2 is
> > silent on requiring anyone to use any algorithm.
>=20
> That's interesting.  To me, 12.2 means the opposite of your
> interpretation - they also have the implied addition of the MUST
> algorithms.

I just thought the "in that they specify which algorithms the keyholder
accepts" part was without additional implied meaning. Perhaps if it's
too confusing the WG needs to clear it up.

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

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
Brian M. Carlson <karlsson@hal-pc.org> <http://decoy.wox.org/~bmc> 0x560553=
E7
"I am ecstatic that some moron re-invented a 1995 windows fuckup."=3D20
        -- Alan Cox

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

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

iQFKBAEBAwA0BQI9M2SFLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w
Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT5xp0CACOQPjHX9K2H+nWbe2smyToKu9s
s0e+E131QL4oAeiIC0rPiQKX1EmH1x1mVuVtVocnhkQC+EaN+vm2KyeNfzfuFAoo
9/ORqdURtf/1/+u/ZDUaMxfyVx64DVNcjS5Rg3iULYhIHrcaLw0z9Uc/MH/E/c4H
AlmPJ4Qh2oICb+pRMjgzj3REmXJWChQDqVQVvhXYO4UORdAmv8os8GKm5lw3dxcj
6Uy3ef/P34pIx0ziDfPXio35fHJpYSDufCmdZSXuxXjsL4hzTW+oM3+XlOhgQlh1
77WYdJhmCr8TlvtFJuDBstJWrpeIWUwCnSQcg/erRY2VK/VGU0P5m0OIdKUn
=HDxr
-----END PGP SIGNATURE-----
Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--D6IIOQQv2Iwyp54J--