com.sun.crypto.provider.GHASH performance fix

[Anthony Scarpino]

Florian had posted months back about it giving 10x improvement. 

Hardware acceleration is an separate project as it is mostly changes to hotspot. 

Tony

> On Jan 15, 2015, at 11:31 AM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> 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
> 
>