Thank you!
About buffer size - there's nothing special about it. I believe I just
took 1024 from some java code example.
Thank you,
Svetlana
On 11.05.2016 7:40, Wang Weijun wrote:
Looks fine to me.
Just curious, why choose BUFFER_SIZE = 1024 in Utils.java? In JDK 9,
DEFAULT_BUFFER_SIZE = 8
Webrev updated.
Still looking for crypto-collaborator.
On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote:
> https://bugs.openjdk.java.net/browse/JDK-8156584
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
>
> I'm not a crypto engineer, so I'm hoping someone on se
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. This change affected to all test files.
- Addressed all the following comments
Please provide your review of patch to refactor SignatureTest. This test
now runs all signature algorithms with key generated once resulting in
saving 75% of execution time.
Bug: https://bugs.openjdk.java.net/browse/JDK-8156671
Webrev: http://cr.openjdk.java.net/~rhalade/8156671/webrev.00/
Tha
Hi
I need a review of my changes to jdk.security.preferred.provider to add
Groups. This makes it a lot cleaner for support a group of algorithms
that are very similar, such as SHA2 (aka SHA224, SHA256, SHA384, ... )
http://cr.openjdk.java.net/~ascarpino/8155847/webrev/
thanks
Tony
Please review the changes related to 8154005. This is a continuation
JEP-288. It adds a denyAfter constraint the stops PKIX algorithm
support at a specified date.
http://cr.openjdk.java.net/~ascarpino/8154005/webrev/
thanks
Tony
Hello,
In AlgorithmChecker the Javadoc seems to not follow "@param name desc" format
(in two places). Also it should most likely describe something like "time the
signature claimed to be made to check time range limited ciphers after that
date or similiar)
* @param PKIXParameter timestamp (or
Ping again, and webrev updated at
http://cr.openjdk.java.net/~weijun/8156501/webrev.01/
Volatile keyword added to reseedCounter.
Thanks
Max
> On May 9, 2016, at 11:51 AM, Wang Weijun wrote:
>
> Hi All
>
> Please review the fix at
>
> http://cr.openjdk.java.net/~weijun/8156501/webrev.00
Looks fine to me except a minor comment:
AbstractDrbg.java
=
54 * Since 8098581, there is no more synchronized keyword on
SecureRandom APIs.
55 * An implementation is required to protect shared access to
instantiate states
56 * (instantiated, nonce) and DRBG states (v, c,
> On May 12, 2016, at 9:31 AM, Xuelei Fan wrote:
>
> Looks fine to me except a minor comment:
>
> AbstractDrbg.java
> =
> 54 * Since 8098581, there is no more synchronized keyword on
> SecureRandom APIs.
> 55 * An implementation is required to protect shared access to
> inst
Please take a review at
http://cr.openjdk.java.net/~weijun/8156213/webrev.00/
In its initial changeset, The SUN implementation of DRBG supports all
algorithms described in NIST SP 800-90Ar1. However, one algorithm is already
considered weak today (3KeyTDEA) and another is likely to be consid
> 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.
Looks good.
Brad
On 5/11/2016 7:27 PM, Wang Weijun wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8156213/webrev.00/
In its initial changeset, The SUN implementation of DRBG supports all
algorithms described in NIST SP 800-90Ar1. However, one algorithm is already
cons
AlgorithmId.java
Line 582-587, about the capacity of hash map, applications may customize
Security providers and more OID numbers may get removed/added later, so
the oid number may be not a fixed hard-coded number. It may be easier
to maintain the code if using the default initial
On 5/12/2016 12:24 PM, Bradford Wetmore wrote:
> Looks good.
>
+1.
Xuelei
> Brad
>
>
> On 5/11/2016 7:27 PM, Wang Weijun wrote:
>> Please take a review at
>>
>>http://cr.openjdk.java.net/~weijun/8156213/webrev.00/
>>
>> In its initial changeset, The SUN implementation of DRBG supports all
Hi Xuelei,
I think the non-test code will work well with any set of providers,
but is optimized for the default set of providers. If the user
removes a provider, then the hashmap will be auto-compacted. The
OidTableSize test will fail if the default providers are changed, but
that actually helps
On 5/12/2016 1:21 PM, Martin Buchholz wrote:
> Hi Xuelei,
>
> I think the non-test code will work well with any set of providers,
> but is optimized for the default set of providers. If the user
> removes a provider, then the hashmap will be auto-compacted. The
> OidTableSize test will fail if t
Xuelei,
I again invite you to take ownership of this change.
It needs to be ported to jdk9.
If we simply delete OidTableSize then the initialization code will be
close to optimal for the default configuration, and it will still work
well if configured a little differently, so I would keep it. Bu
Hi Martin,
If you agree with the update, I will sponsor your contribution for the
testing and integration for JDK 9.
Thanks,
Xuelei
On 5/12/2016 2:27 PM, Martin Buchholz wrote:
> Xuelei,
>
> I again invite you to take ownership of this change.
> It needs to be ported to jdk9.
>
> If we simply
19 matches
Mail list logo
