Anyone have any additional thoughts on this?

I think the most significant item we need to discuss is the extent to which JCA should allow curve parameters for RFC 7748/8032 to be specified over the API. Does anyone know of a particular use case (that we haven't discuss already) that would require a provider to support arbitrary curves? Any other arguments for or against this feature?



On 8/7/2017 4:37 PM, Adam Petcher wrote:
I'm working on the Java implementation of RFC 7748 (Diffie-Hellman with X25519 and X448). I know some of you have been anxious to talk about how this would fit into JCA, and I appreciate your patience while I learned enough about JCA and existing crypto implementations to develop this API proposal. This API/design proposal is for RFC 7748 only, and it does not include the API for RFC 8032 (EdDSA). Of course, I expect many of the decisions that we make for RFC 7748 will also impact RFC 8032.

First off, I think it is important to separate RFC 7748 from the existing ECDH API and implementation. RFC 7748 is a different standard, it uses different encodings and algorithms, and it has different properties. Further, this separation will reduce the probability of programming errors (e.g. accidentally interpreting a Weierstrass point as an RFC 7748 point). So I propose that we use distinct algorithm names for RFC 7748, and that we don't use any of the existing EC classes like EllipticCurve and ECPoint with RFC 7748.

We can achieve this separation without duplicating a lot of code if we start with some simplifying assumptions. My goal is to remove functionality that nobody needs in order to simplify the design and API. If I am simplifying away something that you think you will need, please let me know.

A) We don't need to expose actual curve parameters over the API. Curves can be specified using names (e.g. "X25519") or OIDs. The underlying implementation will likely support arbitrary Montgomery curves, but the JCA application will only be able to use the supported named curves. B) We don't need direct interoperability between different providers using opaque key representations. We can communicate with other providers using X509/PKCS8 encoding, or by using KeyFactory and key specs.

These two assumptions greatly simplify the API. We won't need classes that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, ECPublicKey, etc. for X25519/X448.

Now that the motivation and assumptions are out of the way, here is a description of the proposed JCA API:

1) The string "XDH" will be used in getInstance() to refer to all services related to RFC 7748 (KeyAgreement, KeyFactory, KeyPairGenerator, etc). This is a departure from the ECDH API that used "EC" for key generation (shared with ECDSA) and "ECDH" for KeyAgreement, and makes the RFC 7748 API more like "DiffieHellman" and other algorithms that use the same name for all services. 2) The new class java.security.spec.NamedParameterSpec (which implements AlgorithmParameterSpec) will be used to specify curves for RFC 7748. This class has a single String member which holds the name of the curve ("X25519" or "X448"). This parameter spec class can be reused by other crypto algorithms that similarly identify parameter sets using names (e.g. FFDHE3072 in DiffieHellman). This new class can be inserted into the hierarchy above ECGenParameterSpec. 3) There will be no classes in java.security.spec for EC public keys and private keys. An RFC 7748 implementation can use the existing classes X509EncodedKeySpec and PKCS8EncodedKeySpec for public and private key specs, respectively. 4) There will be no interfaces in java.security.interfaces for RFC 7748 public/private keys. Public/private key implementation classes will implement java.security.PublicKey and java.security.PrivateKey, which allows access to their encoded representations.

Here is how the API will be implemented in the SunEC provider:

1) The public key and private key implementation classes will extend sun.security.ec.X509Key and sun.security.ec.PKCS8Key, respectively. This is similar to ECPublicKeyImpl and ECPrivateKeyImpl. 2) The KeyFactory for RFC 7748 will support translation to/from opaque keys and X509EncodedKeySpec/PKCS8EncodedKeySpec.

Example code:

KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
kpg.initialize(paramSpec); // equivalent to kpg.initialize(255)
KeyPair kp = kpg.generateKeyPair();

KeyFactory kf = KeyFactory.getInstance("XDH");
X509EncodedKeySpec pubSpec = ...
PublicKey pubKey = kf.generatePublic(pubSpec);

KeyAgreement ka = KeyAgreement.getInstance("XDH");
ka.init(kp.getPrivate());
ka.doPhase(pubKey, true);
byte[] secret = ka.generateSecret();


One thing that is missing from the "core" API proposal is a way to easily produce a public/private key from an encoded numeric value. Of course, it's possible to put this value into a complete encoded X509/PKCS8 key, but that is not very convenient. Perhaps we can add another key spec class (that holds e.g. an AlgorithmParameterSpec and a byte array) to make this easier, but I don't know how valuable this would be.

I appreciate any feedback the experts on the mailing list may have for me. Please let me know what you think.



Reply via email to