RFR: 8046943: RSA Acceleration

Andrew Haley aph at redhat.com
Mon Jun 15 16:58:21 UTC 2015

On 06/15/2015 05:38 PM, Anthony Scarpino wrote:
> On 06/12/2015 04:06 AM, Andrew Haley wrote:
>> http://cr.openjdk.java.net/~aph/8046943-hs-1/
>> http://cr.openjdk.java.net/~aph/8046943-jdk-1/
> Please don't use the JEP 246 in the comments when you push. There are a 
> number of changesets related to 246 and I'd rather not have one 
> associated with it.  We can link the a separate bug id to the JEP.


>> 3.  I fused squaring and multiplication into a single
>> montgomeryMultiply method.  This has two advantages.  Firstly, we only
>> need a single intrinsic, and secondly the decision whether to use
>> multiply or squaring can be made in the runtime library.  If the
>> target does not support the montgomeryMultiply intrinsic there is no
>> slowdown when using C2 because it removes the if (a == b) test in
>>          if (a == b) {
>>              product = squareToLen(a, len, product);
>>          } else {
>>              product = multiplyToLen(a, len, b, len, product);
>>          }
> I don't agree with fusing them together.  I think there should two 
> separate intrinsics.  For one, SPARC has a montsqr and montmul 
> instructions.  Additionally if someone wants to call montgomerySquare, 
> they should be able to call it directly with it's needed number of 
> arguments and not pass 'a' twice to satisfy an internal if().

OK, fair enough.  I'll think a little more about the best way to do

Out of curiosity I just had a look at the SPARC instruction
specifications, and happily (it certainly surprised me!)  they are
almost exactly the same as what I've done, so using those instructions
should be a trivial change after this patch.  The SPARC instruction
seems to be limited to 32 words (2048 bits) but I guess you'd just use
the software for larger sizes.


More information about the security-dev mailing list