[Top] [All Lists]

Re: ECC in OpenPGP proposal

2008-02-29 22:56:43

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

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?

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

Dependant on the "low spec" argument/evidence, we could just
make one of the larger curve-hash pairs as the MUST, and make
AES256 as the must cipher.  Then if we need to encrypt to one
of the two bigger curves *and* a smaller curve then we just
"up" the cipher to AES256 for the small curve recipient.

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.

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