See inline below.
It also occurred to me that we could use Provider properties here. We
have the "ImplementedIn" property, and we can similarly add a standard
"Branchless" property. I think my preferred solution is still to use
separate providers, and perhaps use a read-only "Branchless" property to
aid in provider selection. That is, JCA client code that supports the
branchless API (that is, no BigInteger) could loop through the providers
until it finds one with the "Branchless" property set. This same
mechanism could be used to select a provider that allows branching in an
environment where the highest-priority provider is branchless.
We may also be able to set the "Branchless" property at runtime to
influence the behavior of a single provider. But this would introduce a
lot of complication, and I think it is starting to get away from the
intended use of these properties.
On 9/7/2018 7:07 PM, Anthony Scarpino wrote:
On Sep 7, 2018, at 12:08 PM, Adam Petcher <adam.petc...@oracle.com> wrote:
This is a good suggestion. I don't have particularly strong feelings about
using separate providers vs a property in a single provider. I think the
fundamental issues are the same, and this choice mostly affects API details.
Do you think this should be a system property, security property, or something
else? Should it be modifiable at any time?
I would say a security property
Perhaps it has to be in order to address Mike's desire to put the provider in
"import/export mode". Would the property affect existing keys? Again, I think
it would have to, so you can generate a key, turn off branchless mode, and then export it.
My thought was the property would allow the branchless import/export for that
java instance. Not turning it on and off during operations. I think the
value of the branchless operation is in the usage of the algorithms. If an app
wants to use a pure branchless provider the property can be set or never use
the APIs with BigInteger in them.
One could avoid the property completely by just documenting clearly the
interfaces that branched and then leave it to the app developer, but from the
email discussion with Mike it sounded like you preferred strong controls on the
provider.
The issues related to branching are too subtle, and I don't think we
should expose any of it to the developer except "use this
provider/property/algorithm to indicate that branching on secrets is
unacceptable." Moreover, I'm intimately familiar with all of these
issue, and yet I still don't have confidence in my own ability to switch
SunJSSE over to using a branchless ECC implementation, unless I have
strong enforcement in the provider. It would be too easy for me to
simply miss an existing call to getS() or a use of ECPrivateKeySpec.
If we only have a single provider, and a security property that has been
set to indicate that branching is unacceptable in that provider, then I
think that means that there is no way to change the value of the
property and use private keys as BigInteger in that JVM process without
using some other (third party) provider. Though maybe I'm
misunderstanding something about your proposal.
What about curves other than P256, P384, and P521? We can't do branchless
operations in those curves, so any attempt to use them when this property is
enabled would result in an exception.
I wasn’t going to propose anything further than your existing curves, but it
would be nice if branchful curves could be added to eventual replace SunEC. I
know that isn’t the intent of this JEP and depends if you want to expand it.
Sure, but for this JEP, we need to be concerned about how the API can be
misused, and a branching implementation is obtained when a branchless
one is expected. The developer shouldn't be expected to know that three
of the curves have branchless implementations, and using any other curve
will result in branching. So any global "don't branch" property would
need to cause the use of any other curve to fail.
