com.sun.crypto.provider.GHASH performance fix
Anthony Scarpino
anthony.scarpino at oracle.com
Thu Jan 15 16:24:58 UTC 2015
On 01/15/2015 03:10 AM, 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.
>
Here it is: https://bugs.openjdk.java.net/browse/JDK-8069072
Tony
More information about the security-dev
mailing list