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.
