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

[Xuelei Fan]

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