Hi Brad
I did't expect I need a new updated version at
http://cr.openjdk.java.net/~weijun/8051408/webrev.14/
Changes include:
1. The new wording you suggested below.
2. All health-test related codes (even if they were not called in webrev.13 at
all) removed.
3. Revert the change in ByteAr
> On Apr 29, 2016, at 2:46 AM, Bradford Wetmore
> wrote:
>
> to completely fill the
> buffer before returning from this method.
This is more clear. I'll update but will not send out a new webrev.
Thanks
Max
On 4/27/2016 7:16 PM, Wang Weijun wrote:
On Apr 28, 2016, at 8:50 AM, Bradford Wetmore
wrote:
I won't have the cycles to do another full review, but just looked over things
I mentioned in my previous review, and things are looking good! I have to jump
back to my other projects.
Thanks,
http://cr.openjdk.java.net/~weijun/8051408/webrev.13
http://cr.openjdk.java.net/~weijun/8051408/webrev.13/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.13/specdiff
Another update.
1. Comment out health test for the moment.
2. Remove the following words in SecureRandom#nextBytes:
-
> On Apr 28, 2016, at 8:50 AM, Bradford Wetmore
> wrote:
>
> I won't have the cycles to do another full review, but just looked over
> things I mentioned in my previous review, and things are looking good! I have
> to jump back to my other projects.
Thanks, there are still several thing to d
I won't have the cycles to do another full review, but just looked over
things I mentioned in my previous review, and things are looking good!
I have to jump back to my other projects.
Thanks for your careful review of our comments. A few minor points.
On 4/27/2016 10:20 AM, Wang Weijun wrote
Webrev updated:
http://cr.openjdk.java.net/~weijun/8051408/webrev.12
http://cr.openjdk.java.net/~weijun/8051408/webrev.12/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.12/specdiff
1am now and I will reread the changes tomorrow. This is the result of 3 days'
intense work and I hope I cov
> On Apr 27, 2016, at 3:27 AM, Bradford Wetmore
> wrote:
>
>
>
> On 4/25/2016 11:25 PM, Wang Weijun wrote:
>>
>>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore
>>> wrote:
>>>
>>> but the runtime "Health Testing" I was talking about is in the diagram of
>>> Section 7, and details in secti
Deleting the cruft that doesn't need further discussion.
On 4/24/2016 9:13 PM, Wang Weijun wrote:
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff
Thanks for the review
On 04/26/2016 12:27 PM, Bradford Wetmore wrote:
On 4/25/2016 11:25 PM, Wang Weijun wrote:
On Apr 26, 2016, at 8:48 AM, Bradford Wetmore
wrote:
but the runtime "Health Testing" I was talking about is in the
diagram of Section 7, and details in section 11.3:
I haven't touched this area yet
On 4/25/2016 11:25 PM, Wang Weijun wrote:
On Apr 26, 2016, at 8:48 AM, Bradford Wetmore
wrote:
but the runtime "Health Testing" I was talking about is in the diagram of
Section 7, and details in section 11.3:
I haven't touched this area yet.
If you think it's necessary, I would like to
> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore
> wrote:
>
> but the runtime "Health Testing" I was talking about is in the diagram of
> Section 7, and details in section 11.3:
I haven't touched this area yet.
If you think it's necessary, I would like to add the test inside the static
bloc
On 4/24/2016 9:13 PM, Wang Weijun wrote:
I didn't see any health tests. What is your plan for that?
*** If by health test your means the CAVP known-output tests, I am going to put
it into test/closed since it's reading a huge (13MB) external file and should
be stored on an artifact server.
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff
Thanks for the review. I copied your DRBG.txt below with my comments.
Most are accepted, some I mentioned my previ
I haven't followed much of the discussion between you/Xuelei, I will
hopefully look at this tomorrow. I just started with webrev.11 and ran
heads down with it for the last few days.
Comments attached.
Brad
On 4/21/2016 1:52 AM, Wang Weijun wrote:
Hi All
Webrev updated again at
http://c
On 4/21/2016 4:52 PM, Wang Weijun wrote:
> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/
src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
=
343 if (debug != null) {
344 debug.println("nextBytes");
345 }
Would you m
On 4/21/2016 11:10 PM, Wang Weijun wrote:
>
>> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote:
>>
public MyCertStore extends CertStoreSpi {
public MyCertStore() {
// whatever
// ;-) Don't ask me why this construct is necessary.
}
public MyC
> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote:
>
>>> public MyCertStore extends CertStoreSpi {
>>>
>>> public MyCertStore() {
>>> // whatever
>>> // ;-) Don't ask me why this construct is necessary.
>>> }
>>>
>>> public MyCertStore(XXX params) {
>>> // throws NoSuchMe
On 4/21/2016 12:29 PM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 9:35 AM, Xuelei Fan wrote:
>>
>> On 4/20/2016 9:17 AM, Wang Weijun wrote:
>>>
On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote:
On 4/19/2016 11:41 PM, Wang Weijun wrote:
> http://cr.openjdk.java.net/~weijun/80
Hi All
Webrev updated again at
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff
Changes since webrev.10:
- DRBG's generateSeed() will directly read from securerandom.sour
> On Apr 20, 2016, at 9:35 AM, Xuelei Fan wrote:
>
> On 4/20/2016 9:17 AM, Wang Weijun wrote:
>>
>>> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote:
>>>
>>> On 4/19/2016 11:41 PM, Wang Weijun wrote:
http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>>
>> Please update cop
On 4/21/2016 9:24 AM, Wang Weijun wrote:
>
>> On Apr 21, 2016, at 8:07 AM, Xuelei Fan wrote:
>>
>>> I'll model after Authenticator. That would need some synchronization.
>>>
>> You have already make synchronization.
>
> You mean synchronized for instantiateIfNecessary? But this time I need to
>
> On Apr 21, 2016, at 8:07 AM, Xuelei Fan wrote:
>
>> I'll model after Authenticator. That would need some synchronization.
>>
> You have already make synchronization.
You mean synchronized for instantiateIfNecessary? But this time I need to
synchronize on cc which is static.
>
>> I even da
On 4/21/2016 7:55 AM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 11:13 PM, Xuelei Fan wrote:
>>
>>> Really? You are worried about more than 2^64 instances of DRBG?
>>>
>> SSL/TLS considers record sequence number wrapping, too. The nonce
>> require at least half-strength randomness, I would like
On 4/20/2016 4:30 PM, Wang Weijun wrote:
198: Should we add a short 1-liner description for the fields? The
variable meanings (esp pr/df) may not be obvious to a casual observer.
For example, using these three fields as an example:
mech_name: default "Hash_DRBG"
"Hash_DRBG" | "H
> On Apr 20, 2016, at 11:13 PM, Xuelei Fan wrote:
>
>> Really? You are worried about more than 2^64 instances of DRBG?
>>
> SSL/TLS considers record sequence number wrapping, too. The nonce
> require at least half-strength randomness, I would like to follow this
> requirement.
>
>> How about
> On Apr 21, 2016, at 3:06 AM, Bradford Wetmore
> wrote:
>
>
>>> 175: Should we add DRBG:SUN as a backup for non-windows?
>>
>> If NativePRNGBlocking:SUN is not always available, yes we can.
>
> It should be available, unless someone decides to blow away /dev/(u)random.
> But then DRBG wi
175: Should we add DRBG:SUN as a backup for non-windows?
If NativePRNGBlocking:SUN is not always available, yes we can.
It should be available, unless someone decides to blow away
/dev/(u)random. But then DRBG will have the same problem.
One advantage about listing it here is that deplo
On 4/20/2016 10:14 PM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 12:53 PM, Xuelei Fan wrote:
>>
>> On 4/20/2016 12:00 PM, Wang Weijun wrote:
>>>
On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote:
On 4/19/2016 9:09 PM, Xuelei Fan wrote:
> On 4/15/2016 9:
>> http://cr.openjdk
> On Apr 20, 2016, at 12:00 PM, Wang Weijun wrote:
>
>> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
>> ===
>> line 66-68: My understanding is that ...
>>
>> I would suggest rewords or remove this sentence.
> On Apr 20, 2016, at 12:53 PM, Xuelei Fan wrote:
>
> On 4/20/2016 12:00 PM, Wang Weijun wrote:
>>
>>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote:
>>>
>>> On 4/19/2016 9:09 PM, Xuelei Fan wrote:
On 4/15/2016 9:
> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>>>
>>> src
On 4/20/2016 12:00 PM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote:
>>
>> On 4/19/2016 9:09 PM, Xuelei Fan wrote:
>>> On 4/15/2016 9:
http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>>
>> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
>>
> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote:
>
> On 4/19/2016 9:09 PM, Xuelei Fan wrote:
>> On 4/15/2016 9:
>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>
> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
> =
On 4/19/2016 9:09 PM, Xuelei Fan wrote:
> On 4/15/2016 9:
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
===
line 66-68: My understanding is that ...
I wo
> On Apr 20, 2016, at 8:54 AM, Bradford Wetmore
> wrote:
>
> > Webrev updated again at
> >
> > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
> > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec
> > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff
>
> Some initial
On 4/20/2016 9:17 AM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote:
>>
>> On 4/19/2016 11:41 PM, Wang Weijun wrote:
>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>
> Please update copyright dates.
>
> src/java.base/share/classes/java/securi
> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote:
>
> On 4/19/2016 11:41 PM, Wang Weijun wrote:
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
Please update copyright dates.
src/java.base/share/classes/java/security/Provider.java
--
> Webrev updated again at
>
> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec
> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff
Some initial comments.
security/java.security
==
123-133: Would you
On 4/19/2016 11:41 PM, Wang Weijun wrote:
>>> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>> >
>> > Please update copyright dates.
>> >
>> > src/java.base/share/classes/java/security/Provider.java
>> > ---
>> > 145-151: Looks like
> On Apr 19, 2016, at 9:09 PM, Xuelei Fan wrote:
>
> On 4/15/2016 9:
>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
>
> Please update copyright dates.
>
> src/java.base/share/classes/java/security/Provider.java
> ---
> 145-151: Loo
On 4/15/2016 9:
> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
Please update copyright dates.
src/java.base/share/classes/java/security/Provider.java
---
145-151: Looks like the comment are not correct. There are
getInstance(alg,param
On 4/19/2016 6:39 PM, Wang Weijun wrote:
>> > Anyway, minor comments. You can go with the current design, please let
>> > me know.
> I'd like to keep the current design.
OK. Let's move on with the current design.
Thanks,
Xuelei
> On Apr 19, 2016, at 5:41 PM, Xuelei Fan wrote:
>
> On 4/19/2016 4:05 PM, Wang Weijun wrote:
2. DrbgParameters.Instantiate
Looks like this class would be better to an extendable individual class.
Declare this class as "static final" may limit it extension.
>> NIST SP 800-90A&C ar
On 4/19/2016 4:05 PM, Wang Weijun wrote:
>> > 2. DrbgParameters.Instantiate
>> > Looks like this class would be better to an extendable individual class.
>> > Declare this class as "static final" may limit it extension.
> NIST SP 800-90A&C are quite clear on what parameters are required for a DRBG.
> On Apr 19, 2016, at 12:34 PM, Xuelei Fan wrote:
>
> Two minor comments about the spec.
>
> 1. DrbgParameters.Capability
> The spec for each enum item is not very clear. Please add more comments
> about the meaning and behavior of each item.
OK. I probably should move the text in DrbgParamet
> On Apr 19, 2016, at 12:34 PM, Xuelei Fan wrote:
>
> Two minor comments about the spec.
>
> 1. DrbgParameters.Capability
> The spec for each enum item is not very clear. Please add more comments
> about the meaning and behavior of each item.
OK. I probably should move the text in DrbgParamet
Two minor comments about the spec.
1. DrbgParameters.Capability
The spec for each enum item is not very clear. Please add more comments
about the meaning and behavior of each item.
2. DrbgParameters.Instantiate
Looks like this class would be better to an extendable individual class.
Declare thi
Hi All
Webrev updated again at
http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff
Changes since webrev.09:
1. The first line in DrbgParameters:
- * This class specifies th
Thanks for the review. All comments accepted.
--Max
> On Apr 5, 2016, at 9:13 PM, Seán Coffey wrote:
>
> A few comments from supportability side of the table.
>
> =
> sun/security/provider/AbstractDrbg.java
>
>> +if (dp.getStrength() > strength) {
>> +t
A few comments from supportability side of the table.
=
sun/security/provider/AbstractDrbg.java
+if (dp.getStrength() > strength) {
+throw new IllegalArgumentException("strength too high");
+}
+if (result.length > maxNbLength) {
+
Updated webrev again at
http://cr.openjdk.java.net/~weijun/8051408/webrev.09/
http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff
The only change is that SecureRandomInstantiateParameters,
SecureRandomNextBytesParameters and
Hi All
Updated webrev at
http://cr.openjdk.java.net/~weijun/8051408/webrev.08/
http://cr.openjdk.java.net/~weijun/8051408/webrev.08/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.08/specdiff
Spec changes:
- More text in @implNote of DrbgParameters.java, which somehow matches the
Oops. I suddenly realize something wrong about the drbg security property.
Hash_DRBG can use
SHA-512/224 and it includes a slash.
--Max
> On Apr 1, 2016, at 3:24 AM, Sean Mullan wrote:
>
> Just a few comments:
>
> - SunJCE
>
> 707 // TODO: aliases with OIDs
>
> leftover TODO.
Every other HMAC algorithm has an OID that can be used as an Alg.Alias.***, but
the 2 new algorithms do not have. I expect one day
Just a few comments:
- SunJCE
707 // TODO: aliases with OIDs
leftover TODO.
- SecureRandom
604 * @implSpec The default implementation returns {@code null}.
Technically, I don't think that is correct, since it is really dependent
on what the underlying Spi is doing.
Ping again. No comment?
--Max
> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote:
>
> Hi All
>
> Please take a review at the design and implementation of DRBG at:
>
> http://cr.openjdk.java.net/~weijun/8051408/webrev.07
> http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec
> http://cr.ope
> On Mar 21, 2016, at 1:23 PM, Wang Weijun wrote:
>
>
>> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote:
>>
>>if (ins.getCapability() != NONE) {
>
> Ah, should be
>
> if (ins.getCapability() != NONE && ins.getCapability() != PR_ONLY) {
Oh, back to
if (ins.getCapability() != NONE)
> On Mar 21, 2016, at 1:15 PM, Wang Weijun wrote:
>
> if (ins.getCapability() != NONE) {
Ah, should be
if (ins.getCapability() != NONE && ins.getCapability() != PR_ONLY) {
--Max
Hi All
Please take a review at the design and implementation of DRBG at:
http://cr.openjdk.java.net/~weijun/8051408/webrev.07
http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html
An example:
SecureRandom d
59 matches
Mail list logo
