On 9/25/2018 12:06 PM, Xuelei Fan wrote:
On 9/25/2018 8:34 AM, Adam Petcher wrote:
Yes, it is possible, at the expense of some assurance related to
security against side-channel attacks. This interoperable
implementation will be available by default in SunEC. A
higher-assurance form of the same implementation will be available in
the new provider. The additional effort required to put this
implementation in both providers is expected to be relatively small.
Can we have the same security level impl in SunEC in some
circumstances? For example, when the key is not imported for the 4
named curves. Using a new provider means we force applications to
choose between weak and interop, just because we cannot provide both
at the same time.
Thanks,
Xuelei
There's a hole in my desk from where I've been pounding my head on this
subject.
Basically, for the opaque operations - signing, verifying, deriving
shared secrets - Adam can meet his branchless goal. For the non-opaque
operations - importing and exporting the private key according to the
interface specifications, he can't or thinks he can't. And even with
the latter - with the use of PKCS12 as the standard key store format -
the import of a private key from a key store (e.g. internally stored as
PKCS8) should be able to be implemented branchless without too much effort.
It's only when moving key material to/from his implementation where
there are interoperability requirements that might involve branching
(and not even then if he makes his own version of BigInteger to avoid
those branches in the new() methods). Given that once the key leaves
his implementation he has no control over whether it's used branchless,
it's utterly disingenuous to claim that the process of exporting also
must be branchless.
So to clarify: all of his opaque code will be "high assurance" - and
that's will be what's used about 99.999% of the time. The rest of this
is just religious dogma that doesn't consider the actual use cases and
costs related to moving keys to/from his implementation.
Later, Mike
