[Top] [All Lists]

ECC in OpenPGP proposal

2008-02-18 21:22:37

Hello OpenPGP list,

as Hal Finney had mentioned earlier, here is the draft:

Unless you read this on a text terminal, here is the document in alternative formats that offer cross-references as navigation links:

This submissions considers comments of the group to earlier Elliptic curve Cryptography (ECC) draft submissions. A couple of issues that were raised then are the justification for ECC in OpenPGP and how the larger set of ECC parameters can be managed.

Why do we need ECC? The main reason is better alignment with the strength of symmetric key. Given that US government has chosen ECC in favor of modp for larger key sizes, this proposal is carefully written to comply with NSA Suite-B. Informally, this is a proposal for these who are concerned that the use of SHA2-512 and AES-256 will need something stronger that RSA 1024. By optimistic estimates users should use at least RSA 4096 with AES 256, while it is a common assumption that RSA 8192 is more appropriate. In practice, many sites today are not able to use RSA keys of sizes greater than 4096. ECC offers alternatives to larger modp key sizes. Another advantage of ECC is an opportunity to expand the set of hardware on which OpenPGP can be implemented. The security of AES-128 with corresponding ECC public key may be more attractive for "weak" devices, as opposed to RSA public keys, especially because the ECC curves introduced by this standard are already supported by TLS, IKE, PKIX, and SSH. Any system that communicates over slow medium will benefit from smaller keys and ESKs as well.

This paragraph describes the direction chosen by the proposal in reference to the issue of magnitude of ECC parameters and options. One possible approach an ECC standard can take is to define all possible formats in one RFC, a "toolbox" approach. One can argue that smartcard devices may prefer ECC in binary fields, while software implementations would like to work in generalized Mersenne prime fields. Another group of OpenPGP applications may wish to generate its own random curves as part of a protocol, and so on. While it may be possible to create such a broad standard that will make each concerned implementer happy, it creates more interoperability issues. This puts burden on an implementation that wants to support every type of ECC key. The performance and security issues associated with generation and verification of random ECC curves creates new order of complexity. It seems to me that in the short run there are two likely outcomes resulting from implementing a "toolbox" approach. In the first one, there will be no interoperability between different OpenPGP implementations. The second possibility is that there will be a core set of parameters that will be implemented by everybody who claims ECC support. This second possibility is probably wishful thinking. Consider the fact that in OpenPGP there is no method to advertise public key support, yet alone, a method to advertise a nuance of public key support. For example, what an application should use for a top key, so that self-signatures and certifications by this key are broadly understood? It is rare to see SHA2-512 used for these signatures. I think the following approach will help speed up adoption of the standard: we define core set of ECC parameters and make them MUST. This will be lowest common denominator of all possible ECC configurations (within the acceptable security strength). This will not be the optimal field for every application, yet, it will be good compromise to achieve faster adoption. Future advances in computing will drive the upgrade of the core set, but by then there will be a path by which ECC-capable applications can transition to other formats. The draft doesn't preclude the existence of companion proposals that define ECC in other fields, moreover, the draft provides a framework for these extensions.

Finally, only patent-free techniques were chosen for this proposal. The requirement to be in unencumbered field further reduced the acceptable ECC methods.

To summarize, this document offers narrow core set of functionality and focuses on matching AES strength and on Suite-B support. There are lots of MUSTs, very few SHOULDs in the interest of interoperability and patent clarity.

I would appreciate if the group reviews the document. Thank you.

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