Conceptual feedback on new ECC JEP

[Bernd Eckenfels]

Hello,

I think I missed it, but where is the conversion on BigInteger branching on key material? Isn’t this only branching on effective constant values?

Or are you concerned about Spectre-type problems?

Besides that I totally agree on the idea of having a more secure implementation which can be activated by simply switching provider priorities.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: -1001833328m Auftrag von
Gesendet: Mittwoch, September 19, 2018 7:16 PM
An: security-dev at openjdk.java.net
Betreff: Re: Conceptual feedback on new ECC JEP

On 9/18/2018 4:24 PM, Michael StJohns wrote:

>
> Adam -
>
> Basically, the JCE is all about plugging in not about the
> implementations.  If this is truly an EC library, I should be able to
> get the benefit of your library with very minimal changes - e.g.
> specifying your provider in the various getInstance() calls.   As it
> stands, I doubt this will end up in anyone's "must use" category
> because it will break existing code.

Is this standard of being "truly an EC library" met by PKCS11 providers
that don't export keys?

>
> You want folks to convince you that interoperability is a significant
> problem when what we (or at least I) want is for you to convince us
> that these interop breaks are warranted due to how wonderful your
> approach is and that they're absolutely necessary due the secret sauce
> of wonderfulness.  You're not there yet.

I don't agree with this logic. Different providers have different levels
of interoperability, and this interoperability is a feature that
requires effort to develop and maintain. I don't want to commit myself
or this community to this effort unless I/we think it is worthwhile.
Some of the proposals to increase interoperability for this effort (e.g.
subclassing BigInteger) would require a significant amount of additional
effort, and I think this requires justification.

Of course, if you know of a way to have more interoperability without
reducing assurance or significantly increasing effort, I would love to
hear about it. For assurance, an important property is that the
implementation should not branch on secrets after the developer has put
it in branchless mode (by selecting the branchless provider or by using
some other interface to switch modes).

>
> As for PKCS11 - there are exportable and non-exportable private keys
> (e.g. PKCS11 with an accelerator vs an HSM for example).  The
> exportable ones show up as ECPrivateKeys, the non-exportable ones as
> PrivateKeys (and I think with an underlying type of PKCS11Key...).  So
> it follows the model for exportable keys.  And every PKCS11 provider
> I've used at least has a way of IMPORTING ECPrivateKeys.

My goal is for the new provider to be at least as interoperable as
PKCS11 providers with non-exportable keys. Do all the PKCS11 providers
that you have used allow importing private keys over JCA, or over some
other API? Do you have to put the HSM in some sort of "import mode" in
order for this import to be allowed? Is there any difference in the way
that you can use keys that were loaded over this API vs keys that were
generated on the device (or loaded securely)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180919/e5d485d9/attachment.htm>