Code review request: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc
Michael StJohns
mstjohns at comcast.net
Mon Feb 13 17:40:34 UTC 2012
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(log2n) >= hashlen, set E = H. Otherwise, set E equal to the leftmost .floor(log2n). bits of H.
'n' is the prime order of the curve generator G.
So I'd actually say - bug.
>> Xuelei
>>
>>> Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20120213/5264b6b7/attachment.htm>
More information about the security-dev
mailing list