ietf-openpgp
[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-03-01 06:13:05

On 3/1/08, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> 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?

<Prev in Thread] Current Thread [Next in Thread>