Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

On 3/1/08, Andrey Jivsov <openpgp@xxxxxxxxxxxx> wrote:
> David Crick wrote:
>  > The ecc-pre-6.txt's section 2 pretty much says "this is how to
>  > do ECC with AES," and we've said that this proposal is a "MAY."
>  > In a sense this is therefore some kind of a fork (sub-superset?)
>  > of 4880, so we're not concerned with 3DES (or CAST), and - as
>  > with DSA - we can make specific restrictions in order to meet
>  > compliance.

(further to my point above, if we really want ECC to support
3DES then the ECC document needs to be updated for that)

> I think we need to be careful here. Let's examine a use case.
>
>  I am a user of some RFC 4880 OpenPGP application. All algorithms are
>  available to me, e.g. I am not a government employee.
>
>  * I use the application to encrypt mail to 5 recipients, my friends.
>  They use RSA/DSA/ElGamal keys.
>
>  * I upgraded the application to the next version that happened to
>  implement "ECC in OpenPGP".
>
>  I assume that we agree that if I encrypt to exactly the same 5 people
>  with new version, as far as algorithm selection is concerned, the result
>  is identical to the previous version.
>
>  * I added 6th recipient to the list, which uses ECDH key.
>
>  I hope we will agree that it must be possible to send single e-mail to 6
>  recipients. RFC 4880 specifies that the default encryption algorithm is
>  3DES, thus, there is always a match. Why shouldn't single e-mail be sent
>  to 6 recipients with 3DES symmetric key?

I use PGP 2.6, I upgrade to PGP 5.0.  Shiny new DH/DSS
keys - but no RSA support!  Until the RSA patent expired
(well, was placed prematurely into the public domain) we
ran parallel systems and/or kept "old" and "new" keys.

Even now with 3DES as a must, we have this delightful
phrase in 4880:

"Implementations MUST implement TripleDES.  Implementations SHOULD
implement AES-128 and CAST5.  Implementations that interoperate with
PGP 2.6 or earlier *need to* support IDEA, as that is the only symmetric
cipher those versions use.  Implementations MAY implement any other
algorithm."

"need to"!

But, NB, "might not be able to" - due to the IDEA patent.


I seem to recall one of the PGP (5+) versions popping up
a message about mixed V3/V4 (or RSA/DH) keys when I
attempted to encrypt something (or maybe it was due to
an IDEA/3DES conflict).  (Maybe Jon can confirm my vague
recollections here?)


>  If the application is operating in Suite-B mode, or FIPS more, etc, then
>  the situation is different.

right.

> RFC 4880 currently grants to a user of embedded device a method to say
>  "don't do AES-256 to me" by using cipher preferences that exclude AES
>  256. We should respect this. We cannot change the fact that there are
>  hardware platforms that don't implement or don't like AES 256.

OK, but they SHOULD support AES-128 (which would make
a 128-256-256 ECC MUST not seem absolutely unworkable).

Question: how "interoperable" do these "embedded devices"
need to be with the rest of the world?