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
