JEP 332: Transport Layer Security (TLS) 1.3
New JEP Candidate: http://openjdk.java.net/jeps/332 - Mark
Re: JEP 332: Transport Layer Security (TLS) 1.3
Is it possible that this could make Java 11, or is that a long shot? On Fri, Mar 30, 2018 at 11:36 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/332 > > - Mark -- - DML
Re: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448
A few comments so far; have not finished my review yet. General comment: Many of these tests test more than XDH. That is fine and good for increasing coverage, but have you looked through existing tests to see if you are duplicating anything we are already testing and maybe those tests could be removed or you could share the same code. One of the things we should be looking at is to figure out how to reduce the overall time the security tests take. * KeyAgreementTest.java 128 // Uses platform supported provider to test interoperability. What do you mean by "platform supported provider"? Isn't this based on the provider search order? So in some cases, you might be testing against the same provider and not really doing interop testing? * KeySizeTest.java You are generating some large keys - any issues with test timeouts? Do we need to test the generation of the keypairs? Could we use cached keypairs instead? --Sean On 3/26/18 12:38 PM, Sibabrata Sahoo wrote: Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ All the Test files uses KeyAgreement, KeyPairGenerator, Several KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with curve25519 and curve448 algorithms. Each Test files try to address several cases and the purpose of each has been commented in their own files. Thanks, Siba
Re: RFR 8171277: Elliptic Curves for Security in Crypto (part 2)
The updated webrev looks good.
--Sean
On 3/27/18 4:23 PM, Adam Petcher wrote:
After the last code review[1] on this topic completed, it was suggested
that I add some more "spec enforcement" to the XDH service. The code
hasn't been integrated yet, so I'm doing this as a follow-on review
under the same ticket. The latest webrev contains only the diff from the
end of the last review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8171277
Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.03/
(note: you can look at webrev.02 to see the code at the end of the last
review).
For XDH, we are adding the algorithm names "X25519" and "X448", because
these names are more widely known than "XDH". This leaves us with the
problem of whether things like this should be allowed:
var kpg = KeyPairGenerator.getInstance("X448");
kpg.initialize(new NamedParameterSpec("X25519"));
To promote good code hygiene, the implementation in SunEC will reject
all confusing combinations like this in all XDH services. Programmers
can still use the "XDH" algorithm name to get a service that allows all
supported parameters and key sizes.
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-March/016915.html
