Code review request: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc

[Vincent Ryan]

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.ryan at 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.
>