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.
