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
Changeset: 6eed7049d389
Author:ptisnovs
Date: 2012-03-01 14:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6eed7049d389
7149785: Minor corrections to ScriptEngineManager javadoc
Summary: JavaDoc correction
Reviewed-by: alanb
Contributed-by: Pavel Tisnovsky
! src/share/cl
Changeset: 971a86421f51
Author:mduigou
Date: 2012-03-01 09:40 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/971a86421f51
7149320: Move sun.misc.VM.booted() to the end of System.initializeSystemClass()
Summary: Ensure that sun.misc.VM.booted() is the last action in
System.in
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
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
> 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
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
