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

Anthony Scarpino anthony.scarpino at oracle.com
Wed May 27 20:35:07 UTC 2015


On 05/27/2015 10:17 AM, Andrew Haley wrote:
> [I'm sorry, I didn't send this to the correct list.  I forgot that
> there was a separate security list.]
>
> 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
>

I had been following your work off and on as I was on the 
hotspot-compiler-dev thread for a while, but then fell off.

Intrinsifying montgomery multiply & square would be a good thing.  I was 
prototyping montgomery multiple & square around SPARC instructions about 
the same time you posted your webrev a few weeks ago and we had 
similarities.  I've been pulled into other parts of my JEP 246, so I 
look forward to see what you come up.  Please keep me in the loop on how 
things are progressing.

How much of the montgomery multiply and sqaure are you planning to 
intrinsify?  Are you doing the whole thing or just portions of the 
operations similar to multiplyToLen and squareToLen?

Sandhya's patch is going to proceed.

Tony



More information about the security-dev mailing list