: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273:
DRBG-Based SecureRandom Implementations
SerializedTest.java:
140: s/Atleast/At least/
51: I don't think TRY_FOR is needed, you can only check once.
Everything else is fine.
Thanks
Max
> On May 19, 2016, at 3:16 PM, Sibabra
her DRBG. So I am keeping
> the file unchanged.
>
> Thanks,
> Siba
>
> -Original Message-
> From: Wang Weijun
> Sent: Wednesday, May 18, 2016 1:37 PM
> To: Sibabrata Sahoo
> Cc: security-dev@openjdk.java.net
> Subject: Re: [9] RFR: 8141039: Test Task: D
RBG. So I am keeping the
file unchanged.
Thanks,
Siba
-Original Message-
From: Wang Weijun
Sent: Wednesday, May 18, 2016 1:37 PM
To: Sibabrata Sahoo
Cc: security-dev@openjdk.java.net
Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273:
DRBG-Based SecureRandom Implementa
> On May 18, 2016, at 4:07 PM, Wang Weijun wrote:
>
> - Can you use Supplier instead of creating a new RunnableCode
> type? Same in GetInstanceTest.java.
You're right. We need a new type because of that checkedException.
--Max
ApiTest.java:
- Please move line 128-130 (the System.out.println) line before line 127, so
that if getInstance() fails, we can see what parameters are failing.
- Useless line 69.
- Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1,
false, ..)). Can you also call nextBytes(
nce to MoreDrbgParameters and EntropySource.
>
>
> Thanks,
> Siba
>
> -Original Message-
> From: Wang Weijun
> Sent: Thursday, May 12, 2016 9:14 AM
> To: Sibabrata Sahoo
> Cc: security-dev@openjdk.java.net
> Subject: Re: [9] RFR: 8141039: Test Task: Develop
gt; Thanks,
> Siba
>
> -Original Message-
> From: Wang Weijun
> Sent: Thursday, May 12, 2016 9:14 AM
> To: Sibabrata Sahoo
> Cc: security-dev@openjdk.java.net
> Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273:
> DRBG-Based Secu
or JEP 273:
DRBG-Based SecureRandom Implementations
> On May 12, 2016, at 1:46 AM, Sibabrata Sahoo
> wrote:
>
> Hi Max,
>
> Please find the updated webrev:
> http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/
>
> Changes includes:
> - Removed otherVM option and
> On May 12, 2016, at 1:46 AM, Sibabrata Sahoo
> wrote:
>
> Hi Max,
>
> Please find the updated webrev:
> http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/
>
> Changes includes:
> - Removed otherVM option and default "securerandom.drbg.config" will get
> reset after each DRBG test run.
e it accordingly.
Thanks,
Siba
-Original Message-
From: Wang Weijun
Sent: Tuesday, May 10, 2016 1:14 PM
To: Sibabrata Sahoo
Cc: security-dev@openjdk.java.net
Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273:
DRBG-Based SecureRandom Implementations
For all:
RNGs. For example: https://www.random.org/analysis/.
SerializedSeedTest.java:
- The SHA1PRNG bug is pending. At the moment, can you just generate 32 bytes of
data with nextBytes() inside check()?
Thanks
Max
> On May 8, 2016, at 9:57 PM, Sibabrata Sahoo
> wrote:
>
> Hello,
>
Hello,
Please review the tests for "JDK-8141039:Test Task: Develop new tests for JEP
273: DRBG-Based SecureRandom Implementations".
Bug: https://bugs.openjdk.java.net/browse/JDK-8141039
Webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.00/
The tests covers the ne
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
There's been a long time, the current status is
http://cr.openjdk.java.net/~weijun/8051408/webrev.03/
http://cr.openjdk.java.net/~weijun/8051408/webrev.03/specdiff/java/security/package-summary.html
Two main changes:
1. s/EntropyInput/EntropySource/g.
2. Two methods in EntropySource, getFullEnt
> On Jan 6, 2016, at 5:53 PM, e...@zusammenkunft.net wrote:
>
> Hello,
>
> Wang Weijun :
>>> On Jan 6, 2016, at 3:31 PM, e...@zusammenkunft.net wrote:
>>> is the Intention of the default implementation of getFullEntropy to expand
>>> a too short array with the DF as well (which is a dangerous t
Hello,
Wang Weijun :
>> On Jan 6, 2016, at 3:31 PM, e...@zusammenkunft.net wrote:
>> is the Intention of the default implementation of getFullEntropy to expand a
>> too short array with the DF as well (which is a dangerous thing to do IMHO)
>> or is the conditional conditioning only to condense
nd
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Wang Weijun
> To: Sean Mullan
> Cc: OpenJDK Dev list
> Sent: Mi., 06 Jan. 2016 6:19
> Subject: Re: Design and impl review: JEP 273: DRBG-Based SecureRandom
> Implementations
>
>
>&
th). It might not be needed hoewever.
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Wang Weijun
To: Sean Mullan
Cc: OpenJDK Dev list
Sent: Mi., 06 Jan. 2016 6:19
Subject: Re: Design and impl review: JEP 273: DRBG-Based SecureRandom
Implementations
> On Jan 6,
> On Jan 6, 2016, at 12:01 AM, Sean Mullan wrote:
>
> If you think getFullEntropy is sufficient, then let's just keep the one
> method.
I thought about this more and we can actually do
/**
* An interface of a source of entropy input.
*
* This interface has 2 methods returning byte arrays
> On Jan 6, 2016, at 1:21 AM, Sean Mullan wrote:
>
> Here are some more comments on the API. I will send some comments on the impl
> next.
>
> * DrbgParameters
>
> 38 * A DRBG mechanism should extend this class.
>
> Is this sentence necessary? None of the builtin DRBG mechs extend this cla
Here are some more comments on the API. I will send some comments on the
impl next.
* DrbgParameters
38 * A DRBG mechanism should extend this class.
Is this sentence necessary? None of the builtin DRBG mechs extend this
class.
175 * If this method is not called, the implementat
On 01/04/2016 08:17 PM, Wang Weijun wrote:
On Jan 5, 2016, at 6:59 AM, Sean Mullan
wrote:
Here are some more comments on the API:
* EntropyInput:
29 * An interface of a source of entropy input.
"interface" is implied, so you can just say "A source of entropy
input." Also, I think this int
> On Jan 5, 2016, at 6:59 AM, Sean Mullan wrote:
>
> Here are some more comments on the API:
>
> * EntropyInput:
>
> 29 * An interface of a source of entropy input.
>
> "interface" is implied, so you can just say "A source of entropy input."
> Also, I think this interface should be called
Here are some more comments on the API:
* EntropyInput:
29 * An interface of a source of entropy input.
"interface" is implied, so you can just say "A source of entropy input."
Also, I think this interface should be called "EntropySource". To me,
"Input" means the byte array that is alread
Webrev updated:
http://cr.openjdk.java.net/~weijun/8051408/webrev.02/
http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html
Changes:
1. DrbgParameters has a Builder now
2. No more default implementation for reseed()
3. Synchronization is now in
On 12/15/2015 03:09 AM, Wang Weijun wrote:
Good.
But the builder will not provide default values so you will see
new DrbgParameters.Builder().build().getAlgorithm() == null
which means the getters still return requested values.
That's fine, this is no different than what the current class
Good.
But the builder will not provide default values so you will see
new DrbgParameters.Builder().build().getAlgorithm() == null
which means the getters still return requested values.
In this case, the algorithm will only be known after it is used for a specific
DRBG, for example, SHA-256 f
The DrbgParameters class has 7 parameters, most of which are optional. A
typical use case might involve lots of null parameters:
DrbgParameters params = new DrbgParameters(null, null, 256, false,
false, nonce, null);
That seems awkward, and you have be overly careful to map the right
value t
Minor updates:
spec:
http://cr.openjdk.java.net/~weijun/8051408/webrev.01/specdiff/java/security/package-summary.html
impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/
http://javaweb.us.oracle.com/~weijwan/webrev/8051408/webrev/ <<-
test/closed
Mostly spec. reseed() has no defa
spec:
http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html
impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/
- No more configure(), it's getInstance(alg, SecureRandomParameters) now.
- The *Spec class names are now *Parameters.
- Overloaded
> On Nov 20, 2015, at 8:23 AM, Wang Weijun wrote:
>
>>> 2. For each of these, if you have getInstance(alg, params), there is no
>>> getInstance(alg). Obviously, for SecureRandom we need to have both.
>>
>> Right, this is the first case where we have both variants of getInstance.
>>
>> Just lo
> On Nov 21, 2015, at 8:59 AM, Wang Weijun wrote:
>
> That said, I re-read SP 800-90A again and seems there is a feature I haven't
> supported yet. The full generate function is
>
> Generate_function (state_handle, requested_number_of_bits,
> requested_security_strength,
> prediction_re
> On Nov 21, 2015, at 6:46 AM, Anthony Scarpino
> wrote:
>
> On 11/18/2015 05:32 AM, Sean Mullan wrote:
>> The getInstance methods can now take a SecureRandomParameterSpec object
>> (rather than an AlgorithmParameterSpec). They should throw
>> InvalidAlgorithmParameterException (not IllegalArgu
On 11/18/2015 05:32 AM, Sean Mullan wrote:
The getInstance methods can now take a SecureRandomParameterSpec object
(rather than an AlgorithmParameterSpec). They should throw
InvalidAlgorithmParameterException (not IllegalArgumentException) if the
parameters are null or not the right type to be co
On 11/19/2015 07:23 PM, Wang Weijun wrote:
On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote:
>>
>>However, I cannot get it working, and I found difficulties understanding the
EngineDescription inner class inside Provider.java.
>>
>>1. For each engine that can take an extra parameter (not provide
> On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote:
>>
>> However, I cannot get it working, and I found difficulties understanding the
>> EngineDescription inner class inside Provider.java.
>>
>> 1. For each engine that can take an extra parameter (not provider) in
>> getInstance(), it is alway
On 11/19/2015 08:41 AM, Wang Weijun wrote:
On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote:
The getInstance methods can now take a SecureRandomParameterSpec object (rather
than an AlgorithmParameterSpec). They should throw
InvalidAlgorithmParameterException (not IllegalArgumentException) if
> On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote:
>
> The getInstance methods can now take a SecureRandomParameterSpec object
> (rather than an AlgorithmParameterSpec). They should throw
> InvalidAlgorithmParameterException (not IllegalArgumentException) if the
> parameters are null or not th
A few more comments -
The name of the new interface should be SecureRandomParameterSpec
instead of SecureRandomSpec.
The getInstance methods can now take a SecureRandomParameterSpec object
(rather than an AlgorithmParameterSpec). They should throw
InvalidAlgorithmParameterException (not Ille
> On 2015年11月14日, at 上午1:56, Sean Mullan wrote:
>
> On 11/12/2015 07:58 PM, Wang Weijun wrote:
>>> What happens if configure is called more than once, or
>>> simultaneously by more than one thread?
>> The state is reset. The last one rules. The implementation can be
>> made synchronized.
>>
>>
On 11/12/2015 07:58 PM, Wang Weijun wrote:
What happens if configure is called more than once, or
simultaneously by more than one thread?
The state is reset. The last one rules. The implementation can be
made synchronized.
* This method can be called multiple times. After each call, this *
{@co
> On Nov 12, 2015, at 11:23 PM, Sean Mullan wrote:
>
> Hi Max,
>
> Still reviewing, but a couple of initial comments ..
>
> On 11/09/2015 09:54 AM, Wang Weijun wrote:
>> Hi All
>>
>> The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at
>>
>> https://bugs.openjdk.java.net/b
1 - 100 of 105 matches
Mail list logo
