Subject: Re: Using IDEA in v3-v4 algorithm conflict

From: <[email-masked]>
Date: Tue, 16 Sep 2003 08:15:53 -0700

On Mon, 15 Sep 2003 21:18:05 -0700 David Shaw <[email-masked]>
wrote:

>Trying to be
>backwards compatible by using IDEA in an algorithm conflict between
a
>V3 key and an Elgamal subkey is pointless since PGP 2.x won't be able
>to handle the message anyway due to the use of Elgamal.

>Some experimentation shows that using IDEA when having a V3<=>V4
>algorithm conflict only works if the V4 (sub)key is:

>a) RSA
and
>b) <=2112 bits 

>The above is true for MIT PGP 2.6.2 and PGP 2.6.3ia.  I don't know
>about Disastry's "2.6.3ia-multi05", or any other programs that might
>implement RFC-1991.

it is not a problem at all in Disastry's multi builds, as they accept
all symmetrical algorithms, (and all hashes),

but by default, will encrypt using idea, and sign with md5, unless configured
otherwise, or overriden at the command line
(the -j command added at the end of a command, can specify an ovverride
and use any algorithm and hash)

Disastry's builds are capable of generating keys up to 8k,
and have no problems accepting messages simultaneously encrypted to a
4k rsa v4 key.

interestingly, it has no problem with the signature of a v4 rsa key either,
 (no alerts, flags, or error messages at all)
it just can't verify it because it won't accept a v4 rsa key into the
keyring,
but it 'asks' to do so, when given a signature from a v4 rsa key, the
same as it would from an unknown v3 rsa key

--vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

---

From: David Shaw <[email-masked]>
Date: Tue, 16 Sep 2003 19:20:12 -0400

> all symmetrical algorithms, (and all hashes),

The issue is unrelated to having sufficient symmetric algorithms, IDEA
or otherwise.  The issue is that 2.x-derived implementations of PGP
cannot cope with the encrypted session key from most v4 (sub)keys.

The draft suggests (though does not recommend) using IDEA in an
algorithm conflict between v3 and v4 keys in order to improve
backwards compatiblity.  My point was that this is not necessarily
useful advice since the 2.x implementation would likely fail anyway,
because of the Elgamal-encrypted session key.

There is no backwards compatiblity with a message encrypted to both a
v3 and v4 key, unless the v4 key happens to be an RSA key that is
<=2112 bits long.  Anything else makes the message unusable by PGP
2.x.

David

Date: Tue, 16 Sep 2003 19:20:12 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Using IDEA in v3-v4 algorithm conflict
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> all symmetrical algorithms, (and all hashes),

The issue is unrelated to having sufficient symmetric algorithms, IDEA
or otherwise.  The issue is that 2.x-derived implementations of PGP
cannot cope with the encrypted session key from most v4 (sub)keys.

The draft suggests (though does not recommend) using IDEA in an
algorithm conflict between v3 and v4 keys in order to improve
backwards compatiblity.  My point was that this is not necessarily
useful advice since the 2.x implementation would likely fail anyway,
because of the Elgamal-encrypted session key.

There is no backwards compatiblity with a message encrypted to both a
v3 and v4 key, unless the v4 key happens to be an RSA key that is
<=2112 bits long.  Anything else makes the message unusable by PGP
2.x.

David

Date: Tue, 16 Sep 2003 08:15:53 -0700
To: [email-masked]
Cc: 
Subject: Re: Using IDEA in v3-v4 algorithm conflict
From: <[email-masked]>
Sender: [email-masked]

a

and

--vedaal

Date: Tue, 16 Sep 2003 00:18:05 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Using IDEA in v3-v4 algorithm conflict
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 12.1 of the draft says:

   An implementation that is striving for backward compatibility MAY
   consider a V3 key with a V3 self-signature to be an implicit
   preference for IDEA, and no ability to do TripleDES. This is
   technically non-compliant, but an implementation MAY violate the
   above rule in this case only and use IDEA to encrypt the message,
   provided that the message creator is warned. Ideally, though, the
   implementation would follow the rule by actually generating two
   messages, because it is possible that the OpenPGP user's
   implementation does not have IDEA, and thus could not read the
   message. Consequently, an implementation MAY, but SHOULD NOT use
   IDEA in an algorithm conflict with a V3 key.

This is a problem since the method given (even though it is a SHOULD
NOT) doesn't work terribly well in practice as PGP 2.x breaks when it
sees *anything* it doesn't understand in a message.  For example, the
most common OpenPGP encryption (sub)key type is Elgamal.  Trying to be
backwards compatible by using IDEA in an algorithm conflict between a
V3 key and an Elgamal subkey is pointless since PGP 2.x won't be able
to handle the message anyway due to the use of Elgamal.

a) RSA
and
b) <=2112 bits

(and everything else in the message is carefully chosen to be at the
RFC-1991 level).

I know 2440bis isn't intended as an implementation guide, so details
like this are perhaps inappropriate.  Still, the wording in the draft
can lead a developer down a bad path.  It is not unreasonable for that
developer to assume that something specified in an RFC is going to
work.

There are countless ways to fix this (specify RSA and <=2112 bits
somewhere, add another implementation note, etc) but it might be
simpler to just drop the paragraph altogether.

David