com.sun.crypto.provider.GHASH performance fix
Michael StJohns
mstjohns at comcast.net
Thu Jan 15 19:31:37 UTC 2015
Just for curiosity, what was the improvement in performance?
I'm wondering if it might be worthwhile to see if its possible to add a plugin to use the hardware instructions:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf
Mike
At 06:10 AM 1/15/2015, Florian Weimer wrote:
>On 08/18/2014 02:32 PM, Florian Weimer wrote:
>>This change addresses a severe performance regression, first introduced
>>in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS
>>implementation. This regression is a result of the poor performance of
>>the implementation of the GHASH function.
>>
>>I first tried to eliminate just the allocations in blockMult while still
>>retaining the byte arrays. This did not substantially increase
>>performance in my micro-benchmark. I then replaced the 16-byte arrays
>>with longs, replaced the inner loops with direct bit fiddling on the
>>longs, eliminated data-dependent conditionals (which are generally
>>frowned upon in cryptographic algorithms due to the risk of timing
>>attacks), and split the main loop in two, one for each half of the hash
>>state. This is the result:
>>
>> <https://fweimer.fedorapeople.org/openjdk/ghash-performance/>
>
>Updated webrev: <http://cr.openjdk.java.net/~fweimer/ghash/webrev.00/>
>
>Anthony, could you file a bug so that I can include its number? Thanks.
>
>--
>Florian Weimer / Red Hat Product Security
More information about the security-dev
mailing list