The fix looks fine to me.
Xuelei
On 2/14/2012 2:49 AM, Vincent Ryan wrote:
Hello Michael,
Thanks for providing those details.
This specific fix is a workaround for a test failure using SunPKCS11-Solaris
provider on Sparc. I'll file a separate bug to correct the issue of matching
hash length to key length.
On 02/13/12 05:40 PM, Michael StJohns wrote:
At 12:24 PM 2/13/2012, Vincent Ryan wrote:
On 02/13/12 05:04 PM, Xuelei Fan wrote:
On Feb 14, 2012, at 12:47 AM, Vincent Ryan<[email protected]> wrote:
Please review the following change:
http://cr.openjdk.java.net/~vinnie/7142888/webrev.00/
for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142888
Some implementations of the SHA512withECDSA signing algorithm require
that the signing/validation key is at least 512 bits.
If I am correct, RSA algorithms have such limitation, but for EC algorithms,
there is no such require. Is it a intend design, or a bug of the implementation?
It's not a bug. I believe it is a FIPS recommendation.
Well sort of - FIPS 186-3 *requires* the HASH function to meet or exceed the
security strength of the key. It *recommends* they be the same (e.g. use SHA256
for NIST P-256). But the controlling document is actually ANSI X9.62 which says
if your hash is longer than your key then trim the hash to the key length before
performing the public key operations.
d) Use the selected hash function (see 7.2) to compute /H = Hash /(/M/), a bit
string of length /hashlen /bits.
e) Derive an integer /e /from /H /as follows:
1) If .floor(log2/n/)>= /hashlen/, set /E /= /H/. Otherwise, set /E /equal to
the leftmost .floor(log2/n)/. bits of /H/.
'n' is the prime order of the curve generator G.
So I'd actually say - bug.
Xuelei
Thanks.
