Sure, thanks!
Valerie
On 03/19/12 20:15, Brad Wetmore wrote:
Minor comment:
// Array too short, pad it w/ leading 0s including the sign bit
Can you pull off: "including the sign bit"
Looks good to me otherwise.
Brad
On 3/16/2012 1:42 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
As I was
Minor comment:
// Array too short, pad it w/ leading 0s including the sign bit
Can you pull off: "including the sign bit"
Looks good to me otherwise.
Brad
On 3/16/2012 1:42 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
As I was preparing the files for putting back, I noticed some
now-redund
Brad,
As I was preparing the files for putting back, I noticed some
now-redundant code in DHKeyAgreement2.java as well as one minor issue
about resetting the key agreement object in the
engineGenerateSecret(...) method of DHKeyAgreement.java.
Hope this to be the last version of the webrev:
h
I thought about this too when I noticed that other security sources also
have codes just simply remove the leading sign byte without checking the
overall length.
I will make an utility function for this in one of my other JDK 8 fixes
which cover more providers.
For this bug, the current chang
Sorry for the late comment here -
It may make sense to make a utility function with the calling sequence similar
to
static byte[] getBytesFixedLength (BigInteger x, int numBits)
throws IllegalArgumentException
some where in the security utility code.
The length of the returned byte
Sure, that's good clarification.
I'll add the suggested wording and put back the changes.
Thanks,
Valerie
On 03/14/12 16:01, Brad Wetmore wrote:
Here's the comment I was trying to suggest in your office yesterday:
/*
* NOTE: BigInteger.toByteArray() returns a byte array contain
Here's the comment I was trying to suggest in your office yesterday:
/*
* NOTE: BigInteger.toByteArray() returns a byte array containing
* the two's-complement representation of this BigInteger with
* the most significant byte in the zero-th element. This
Ok, more comments/changes added as suggested.
Webrev updated at:
http://cr.openjdk.java.net/~valeriep/7146728/webrev.02/
Thanks,
Valerie
On 03/08/12 17:15, Brad Wetmore wrote:
>> DHKeyAgreement:
>> ===
> I added more comments to both code blocks to explain what's going on.
A cou
Looks good, better to be explicit about these values than prepend to an
unknown list.
Thanks,
Brad
On 3/6/2012 7:37 PM, Valerie (Yu-Ching) Peng wrote:
BTW, have you looked at the fixes of 7130959?
* 7130959: Tweak 7058133 fix for JDK 8 (javah makefile changes)
o http://cr.openjdk.java.n
>> DHKeyAgreement:
>> ===
> I added more comments to both code blocks to explain what's going on.
A couple more requested comments.
Around line 299, could please add that the sign bit is always 0.
Around line 303, could you put in a comment that since there is enough
room here fo
BTW, have you looked at the fixes of 7130959?
* 7130959: Tweak 7058133 fix for JDK 8 (javah makefile changes)
o http://cr.openjdk.java.net/~valeriep/7130959/webrev.00/
Instead of using the -Xbootclasspath, switching over to use
-boothclasspath for consistency with the backported changes in
the
Brad,
Thanks for the review.
Please find the update webrev at:
http://cr.openjdk.java.net/~valeriep/7146728/webrev.01/
On 03/02/12 17:31, Brad Wetmore wrote:
DHKeyAGreement.java
===
Mainly just a request for some additional commenting so the reader
doesn't have to have a good u
DHKeyAGreement.java
===
Mainly just a request for some additional commenting so the reader
doesn't have to have a good understanding of the BigInteger logic to
understand the assumptions being made here:
For example, if the expected bits of the modulus is
1024 bits (128
Heh... by the way - this goes back to my previous email suggesting that the
standard algorithms page have an entry for each algorithm that points to the
specific standard you implement (or that should be implemented to claim
compliance with the name).
Later, Mike
At 08:09 PM 3/1/2012, Brad W
> RFC 2631 has not be crystal clear on this I am afraid,
and
> NIST SP800-56A (appendix C.1) make it clear
Thanks, Mike/Valerie
For the record, I wasn't disagreeing with the approach or the need to do
this, just pointing out that RFC 2631 wasn't authoritative on the matter
for the RAW opera
Hi Brad -
The output of the DH calculation needs to preserve leading zeros.
The RFC unfortunately doesn't specify the Integer to Byte conversion primitive,
but both X9.42 and the equivalent text in NIST SP800-56A (appendix C.1) make
it clear that the conversion from Integer to Byte string en
Yes, that's the section that mentioned the generated secret having the
same length as p.
I guess it depends on how it's interpreted. The way I look at it is that
if the generated secrets aren't of the same length, then whoever using
this variant for deriving the keying material will need to do
On 2/21/2012 5:33 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
Can you please review the fixes for the following 2 bugs:
* 7146728: Inconsistent length for the generated secret using DH key
agreement impl from SunJCE and PKCS11
o http://cr.openjdk.java.net/~valeriep/7146728/we
18 matches
Mail list logo
