RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration]

[Anthony Scarpino]

Personally I think it better to not have implSquareToLenChecks() and 
implMulAddCheck() as separate methods and to have the range check 
squareToLen and mulAdd.  Given these change are about performance, it 
seems unnecessary to add an extra call to a method.

While we are changing BigInteger, should a range check for multiplyToLen 
be added?  Or is there a different bug for that?

Tony

On 05/27/2015 06:27 PM, Viswanathan, Sandhya wrote:
> Hi Tony,
>
> Please let us know if you are ok with the changes in BigInteger.java (range checks) in patch from Intel:
>
> http://cr.openjdk.java.net/~kvn/8069539/webrev.01/
>
> Per Andrew's email below we could go ahead with this patch and it shouldn't affect his work.
>
> Best Regards,
> Sandhya
>
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
> Sent: Wednesday, May 27, 2015 10:12 AM
> To: Christian Thalinger
> Cc: Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net
> Subject: RSA and Diffie-Hellman performance [Was: RFR(L): 8069539: RSA acceleration]
>
> An update:
>
> I'm still working on this.  Following last week's revelations [1] it
> seems to me that a faster implementation of (integer) D-H is even more
> important.
>
> I've spent a couple of days tracking down an extremely odd feature
> (bug?) in MutableBigInteger which was breaking everything, but I'm
> past that now.  I'm trying to produce an intrinsic implementation of
> the core modular exponentiation which is as fast as any state-of-the-
> art implementation while disrupting the common code as little as
> possible; this is not easy.
>
> I hope to have something which is faster on all processors, not just
> those for which we have hand-coded assembly-language implementations.
>
> I don't think that my work should be any impediment to Sadya's patch
> for squareToLen at http://cr.openjdk.java.net/~kvn/8069539/webrev.01/
> being committed.  It'll still be useful.
>
> Andrew.
>
>
> [1]  Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
> https://weakdh.org/imperfect-forward-secrecy.pdf
>