Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/25/2018 11:57 AM, Xuelei Fan wrote:

> On 9/25/2018 8:34 AM, Adam Petcher wrote:
>>
>> There will be nothing provider-dependent in the TLS implementation. 
>> The point of #3 is to say that we should test the TLS implementation 
>> to ensure that it will work with either "EC" provider. The only 
>> required changes to TLS code will be using PKCS8 private keys instead 
>> of BigInteger private keys.
>>
> I read it as there is no need to change TLS implementation, right?  
> The change from BigInteger private keys to PKCS8 private keys is for 
> test only, right?  What if we don't change test code as well?  Can an 
> existing application survive if it uses BigInteger private keys (okay, 
> I this is a interop question)?

I looked into the TLS code a bit, and the key stores (both PKCS12 and 
JKS) load the private keys in PKCS8 format and give them to the 
KeyFactory as a PKCS8EncodedKeySpec. From that point on, the TLS 
implementation uses the opaque keys. Based on this behavior, I don't 
expect there will be any need to change the TLS code in order for it to 
work with the new provider.

An existing application cannot use BigInteger private keys if it wants 
to be branchless. If such an application attempts to use the new 
branchless provider, then the provider will throw an exception. If 
branchless behavior in the entire application is desired, then the 
solution is to change the application code so that private keys go 
directly from storage into the provider in PKCS8 format, in the same way 
that our TLS code behaves. If the import/export is allowed to branch, 
then the developer/configuration can use SunEC, which will allow 
branching in import/export, but will be branchless for the core EC 
operations (for three curves only).

> We may not want to have an impl to expose to side-channel attacks.
>
> Okay, let me ask the question in another way.  Is it possible to have 
> an interop-able impl without losing the quality of the new formula 
> (side-channel attacks, etc)?   How much effort will it take to make it 
> possible (please consider even we have to update the BigInteger APIs 
> as well)?

Also, you asked a related question in another email: "Can we have the 
same security level impl in SunEC in some circumstances?"

Yes, the implementation in SunEC will be interoperable and will have the 
same level of security against side-channel attacks when used in a 
particular way. Using this implementation in the new provider only 
ensures that it is used in the particular way that enables this level of 
security.

I've thought more about modifying/subclassing BigInteger, and I don't 
believe it helps us. It only seems to move the problem around. For 
example, say getS() returns an internal BigInteger subclass that only 
supports a subset of the BigInteger operations. When an API client tries 
to use an operation that is not supported, it will get an exception or 
incorrect results. So we are back to having 
compatibility/interoperability issues, just in a different place in the 
code. Making a BigInteger subclass that implements the entire BigInteger 
API in constant time is impossible because the size of a BigInteger is 
unbounded.