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 <vincent.x.r...@oracle.com> >> > 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. >
