At 10:38 AM +0100 3/10/98, Christopher Creutzig wrote:
On Fri, 6 Mar 1998, Jon Callas wrote:
-> Elliptic Curve: I've added identifiers for EC-encryption and ECDSA. Is this
-> enough?
The same thing I already asked you in an unanswered private e-mail some
months ago: Wat encryption system over elliptic curves do you mean by that?
You can use RSA and ElGamal over elliptic curves, amongst others. So far,
only ElGamal and RSA are defined for encryption, so your probably mean one
of those.
Specifically, are you just reserving an identifier (which seems pretty
useless to me; it shouldn't be reserved until its specified), or are you
indending to provide all the necessary info to allow implementation?
If the former, specifying a value is relatively harmless, but short-sighted.
If the latter, there is an awful lot of work left to do before you're done.
I have the same problem with the existing specification for ElGamal: it's
not detailed enough to be complete. Here is the entire description of the
ElGamal encryption system from draft-ietf-openpgp-formats-00.txt:
Algorithm Specific Fields for Elgamal encryption:
- MPI of DSA value g**k.
- MPI of DSA value m * y**k.
There's no discussion of how to generate k, and this description isn't
detailed enough to expect any but true initiates into the secrets to be
able to implement it. There's no mention of mod p, for example, let alone
the arcana of key generation or how to decrypt this packet.
Since ElGamal isn't even standardized (as opposed to RSA's PKCS#1), this
isn't even a stand-in for another document.
Elliptic curve will have all the same issues and more. For example, how to
encode the keys. An RSA key has two elements: e and n. An ElGamal key,
three: p, g, and y. An elliptic curve key can have up to 13.
An elliptic-curve note: If you use PKCS#1 padding for EC encryption, that
will result in an 11 byte (88 bit) overhead. The internal encoding in the
encrypted block adds another 3 bytes, for a total of 14 bytes (112 bits).
This means that if you use raw elliptic curve encryption, you'll need to
use key lengths of at least 240 bits for 128 bit symmetric algorithms and
at least 304 bits for 3DES. This is radical overkill: it's like requiring
RSA keys to be at least 3000-4000 bits long.
This is the sort of unexpected pitfall that causes me to recommend complete
specification or total omission.
- Tim
Tim Dierks - timd(_at_)consensus(_dot_)com - www.consensus.com
Director of Engineering - Consensus Development
Developer of SSL Plus: SSL 3.0 Integration Suite