<html>
<body>
At 12:24 PM 2/13/2012, Vincent Ryan wrote:<br>
<blockquote type=cite class=cite cite="">On 02/13/12 05:04 PM, Xuelei Fan
wrote:<br>
> On Feb 14, 2012, at 12:47 AM, Vincent Ryan
<vincent.x.ryan@oracle.com> wrote:<br>
> <br>
>> Please review the following change:<br>
>>
<a href="http://cr.openjdk.java.net/~vinnie/7142888/webrev.00/" eudora="autourl">
http://cr.openjdk.java.net/~vinnie/7142888/webrev.00/</a><br>
>><br>
>> for
<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142888" eudora="autourl">
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142888</a><br>
>><br>
>> Some implementations of the SHA512withECDSA signing algorithm
require<br>
>> that the signing/validation key is at least 512 bits.<br>
>><br>
> 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?<br>
> <br><br>
It's not a bug. I believe it is a FIPS recommendation.</blockquote><br>
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.<br><br>
<blockquote type=cite class=cite cite="">d) Use the selected hash
function (see 7.2) to compute <i>H = Hash </i>(<i>M</i>), a bit string of
length <i>hashlen </i>bits.<br>
e) Derive an integer <i>e </i>from <i>H </i>as follows:<br>
1) If .floor(log<font size=1>2</font><i>n</i>) >= <i>hashlen</i>, set
<i>E </i>= <i>H</i>. Otherwise, set <i>E </i>equal to the leftmost
.floor(log<font size=1>2</font><i>n)</i>. bits of
<i>H</i>.</blockquote><br>
'n' is the prime order of the curve generator G.<br><br>
<br><br>
So I'd actually say - bug.<br><br>
<br><br>
<blockquote type=cite class=cite cite="">> Xuelei<br>
> <br>
>> Thanks.</blockquote></body>
<br>
</html>