I received quite a bit of feedback that questions the value of the new
provider, and the "branchless mode" in general. At the same time, nobody
has told me that this mode would be useful to them. So I am removing it
from the JEP. In short, I will only be doing the second bullet point
from my la
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
require
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 s
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 t
On 9/25/2018 8:34 AM, Adam Petcher wrote:
On 9/25/2018 11:15 AM, Xuelei Fan wrote:
I did not follow the discussion. But it does not sound right to me to
have an application to be provider dependent (#3).
There will be nothing provider-dependent in the TLS implementation. The
point of #3 is
On 9/25/2018 11:15 AM, Xuelei Fan wrote:
I did not follow the discussion. But it does not sound right to me to
have an application to be provider dependent (#3).
There will be nothing provider-dependent in the TLS implementation. The
point of #3 is to say that we should test the TLS implemen
I did not follow the discussion. But it does not sound right to me to
have an application to be provider dependent (#3).
I was not confident that a new provider instead of updating the existing
provider is a good idea. It might be a significant effort to update
existing provider. However, i
Thanks, everyone for your feedback on this JEP. I have incorporated this
feedback (received on this mailing list and elsewhere) into the draft
JEP[1]. Here is a summary of the current JEP and plan:
*) A new provider (name TBD) will be developed to hold the new ECC
implementation for the three
On 9/19/2018 1:37 PM, Bernd Eckenfels wrote:
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?
This is not for Spectre (etc.) issues, wh
On 9/19/2018 12:51 PM, Michael StJohns wrote:
On 9/19/2018 11:45 AM, Adam Petcher wrote:
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
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@openjdk.java.net
Betreff: Re: Conceptual feedback on new ECC
On 9/19/2018 11:45 AM, Adam Petcher wrote:
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.
sp
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 getIns
On 9/18/2018 4:01 PM, Adam Petcher wrote:
On 9/11/2018 11:07 AM, Adam Petcher wrote:
I still haven't been convinced that this lack of interoperability is
a significant problem. In the proposed design, the new KeyFactory
will not support ECPrivateKeySpec, and the implementation will
produce
On 9/11/2018 11:07 AM, Adam Petcher wrote:
I still haven't been convinced that this lack of interoperability is a
significant problem. In the proposed design, the new KeyFactory will
not support ECPrivateKeySpec, and the implementation will produce
private keys that inherit from PrivateKey,
On 9/10/2018 7:49 PM, Xuelei Fan wrote:
The motivation of the JEP is that some formulas may be more easier to
expose attacks. It's true that the formulas impact the security level
of the implementation. I was just wondering if the JEP proposed
formulas have been well analyze. A standard or
On 9/10/2018 1:23 PM, Adam Petcher wrote:
The paper[1] containing the proposed formulas is referenced in the JEP.
Thanks!
As far as I know, they are not part of any standard. If you know of any
standardized, complete EC point arithmetic formulas, then let me know.
I don't know, either.
I th
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, a
The paper[1] containing the proposed formulas is referenced in the JEP.
As far as I know, they are not part of any standard. If you know of any
standardized, complete EC point arithmetic formulas, then let me know. I
think it is okay to use these formulas as long as they produce the same
result
Can I have the links to the new formulas that you will be used? Are
they part of any current standards?
Thanks,
Xuelei
On 8/23/2018 10:50 AM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal of
developing improved implementations of existing algorithms,
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" prope
> On Sep 7, 2018, at 12:08 PM, Adam Petcher 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
Hi,
I have not had a chance to review this JEP yet. Personally, if
possible, I would expect there is no public APIs update so that more
applications can benefit from the enhancement, and SunJSSE could
benefits from more crypto providers. I'm not sure if it is possible or
not now, or how co
Hi,
In general, System properties should be avoided, they add complexity to
configurations and
especially if they change sensitive behavior. In any case, the defaults
should be secure-by-default;
not the other way around.
Perhaps two different providers, one secure and one more secure.
$.02
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
Adam,
I tend to agree with Mike that disallowing import/export of keys using
BigInteger is not the value of a branchless implementation. As you point out
in the JEP the provider is greatly hindered by this design choice. I feel it
would be better to implementing the BigInteger parts and have a
I'm only going to respond to one of your points in detail, see inline below.
For the other points, I don't think we are going to agree. You want the
implementation to be more interoperable, and I have stated that the
level of interoperability that you want is not a goal of the JEP. This
is sup
On 9/6/2018 9:53 AM, Adam Petcher wrote:
On 9/5/2018 5:53 PM, Michael StJohns wrote:
BigInteger is not required to encode a PKCS8 key, but its trivial to
translate from BigInteger to PKCS8 and vice versa. Note that
internally, the current BigInteger stores the magnitude as an array
of int i
On 9/5/2018 5:53 PM, Michael StJohns wrote:
BigInteger is not required to encode a PKCS8 key, but its trivial to
translate from BigInteger to PKCS8 and vice versa. Note that
internally, the current BigInteger stores the magnitude as an array of
int in big endian order and stores the sign se
On 9/5/2018 2:47 PM, Adam Petcher wrote:
On 9/4/2018 5:20 PM, Michael StJohns wrote:
On 9/4/2018 3:19 PM, Adam Petcher wrote:
I think what you are suggesting is that the implementation should
convert between BigInteger and the internal representation when
necessary. The problem with this appr
On 9/4/2018 5:20 PM, Michael StJohns wrote:
On 9/4/2018 3:19 PM, Adam Petcher wrote:
I think what you are suggesting is that the implementation should
convert between BigInteger and the internal representation when
necessary. The problem with this approach is that it is too easy to
inadverten
On 9/4/2018 3:19 PM, Adam Petcher wrote:
I think what you are suggesting is that the implementation should
convert between BigInteger and the internal representation when
necessary. The problem with this approach is that it is too easy to
inadvertently supply a BigInteger to the implementation,
On 9/4/2018 2:01 PM, Michael StJohns wrote:
Below
*buzz* wrong answer. Sorry. The internal storage of the key can be
anything you want it to be if you want to prevent a non-constant-time
issue for normal calculation. But the import/export of the key really
isn't subject to the cargo cul
Below
On 9/4/2018 8:57 AM, Adam Petcher wrote:
On 9/1/2018 2:03 PM, Michael StJohns wrote:
On 8/23/2018 1:50 PM, Adam Petcher wrote:
It will only support a subset of the API that is supported by the
implementation in SunEC. In particular, it will reject any private
keys with scalar values sp
On 9/1/2018 2:03 PM, Michael StJohns wrote:
On 8/23/2018 1:50 PM, Adam Petcher wrote:
It will only support a subset of the API that is supported by the
implementation in SunEC. In particular, it will reject any private
keys with scalar values specified using BigInteger (as in
ECPrivateKeySpec
On 8/23/2018 1:50 PM, Adam Petcher wrote:
It will only support a subset of the API that is supported by the
implementation in SunEC. In particular, it will reject any private
keys with scalar values specified using BigInteger (as in
ECPrivateKeySpec), and its private keys will not return scalar
I'm starting work on yet another ECC JEP[1], this time with the goal of
developing improved implementations of existing algorithms, rather than
implementing new ones. The JEP will re-implement ECDH and ECDSA for the
256-, 384-, and 521-bit NIST prime curves. The new implementation will
be all J
37 matches
Mail list logo
