On 09/10/2018 08:50 AM, Adam Petcher wrote:
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.
A provider property would be good route to explore I think. It would be
nice to cut down on Security 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.
A single provider with a security property is fine. I think we agree the
property will tell if the API's that use BigInteger will work with the
provider or not. Internally you can design the algorithm code however
you want. It's only the import/export parts I've been referring to.
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.
Ok.. I had the impression that the other curves could work with the
branchless code. If they cannot, then I wouldn't worry about including
them.
Tony
