Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/10/2018 7:49 PM, Xuelei Fan wrote:

> The motivation of the JEP is that some formulas may be more easier to 
> expose attacks.  It's true that the formulas impact the security level 
> of the implementation.  I was just wondering if the JEP proposed 
> formulas have been well analyze.  A standard or formal recommendation 
> may indicate the good quality of the formulas.

Thanks. I added this comment to the JEP under "Risks and Assumptions".

As far as I know, the exact EC formulas that are usually implemented 
have never been standardized. The standards give a specification for 
point addition in affine coordinates, but that is not what is 
implemented. I admit that the novelty of the proposed formulas presents 
some additional risk, but the formulas in SunEC were novel when they 
were implemented, too.

I'd like to hear more opinions about the perceived risk of using 
formulas from the academic literature, if anyone has them. It's worth 
noting that some of these academic formulas have already been 
implemented in other crypto/TLS libraries.

>
> It's a concern to me that interoperability is listed as "non-goals".  
> In general,  it may introduce a lot of problems in the current JCE 
> framework.  I don't know your detailed design yet, and not sure if you 
> are able to mitigate the impact.
>
> Looks like the debate was mainly about the BigInteger.   If the keys 
> are used in the same provider, I don't think the BigInteger is a 
> problem as you can extend a private BigInteger that you like.  If the 
> keys are use between two providers, add a thine clue to export/import 
> BigInteger may be worthy for provider interoperability.

I reworded that part of the JEP, because it was misleading. Now it more 
clearly indicates that interoperability with providers that only support 
BigInteger private keys is out of scope.

I still haven't been convinced that this lack of interoperability is a 
significant problem. In the proposed design, the new KeyFactory will not 
support ECPrivateKeySpec, and the implementation will produce private 
keys that inherit from PrivateKey, but not ECPrivateKey. Specifically, 
what problems in JCE are introduced by this design? How are these 
interoperability issues different from the ones you encounter with a 
PKCS11 provider that doesn't export private keys? If the developer wants 
more interoperability, why not use SunEC? If we decide that we want the 
new implementation to have better interoperability in the future, does 
something prevent us from enhancing it? These questions are for anyone 
who can help me understand the objections that have been raised related 
to interoperability.

>
> I'm a little bit nervous about the two providers design.  It simplify 
> the initial crypto implementation, but left the complexity to 
> developers and sustaining.   I don't have a good sense about how to 
> use them in JSSE.  What if the proposed formulas is vulnerable in the 
> future?

I don't see any reason for a two-provider design to be more complex than 
a one-provider design. The two providers could even share code, but I 
don't think that is necessarily a good idea. Also, I'm not opposed to 
putting everything in one provider, with some sort of property to choose 
the behavior. But the provider system already exists, and it seems to 
work fine for this purpose, so I would rather use it.

Here is a proposal for how we can make the two-provider design work in JSSE:

1) We add the new provider to the list, with lower priority than SunEC
2) We add a "Branchless" property to the provider
3) We modify SunJSSE so that it sends all EC private keys to the 
provider using an encoded key spec. PKCS8EncodedKeySpec would work, but 
perhaps we could add a new type for raw encoded private keys, if necessary.
4) We add some provider selection code to SunJSSE that is used for EC, 
ECDH, and ECDSA. This code will loop through the providers (in priority 
order), looking for the first "Branchless" provider that supports the 
desired curve. If it doesn't find one, it will use the first provider 
that supports the desired curve.

I'm not sure how your question about vulnerability fits in here. If the 
formulas are vulnerable, we will fix them, if possible. Maybe if you 
restate the question, I'll have a better idea of what you are asking.