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
