RFR 8177784 Use CounterMode intrinsic for AES/GCM

Sean Mullan sean.mullan at oracle.com
Mon Apr 10 19:30:20 UTC 2017

On 4/7/17 3:47 PM, Anthony Scarpino wrote:
> On 04/07/2017 06:58 AM, Chris Hegarty wrote:
>> On 06/04/17 21:39, Anthony Scarpino wrote:
>>> I'd like to get a review for this performance change to use the existing
>>> CounterMode parallelized intrinsic instead of GCTR's own version. The
>>> two classes were nearly identical except for the doFinal() method which
>>> doesn't belong in CounterMode.java.
>>> I could have been more aggressive with this change, but I'm looking to
>>> get this into 9, so I stayed away from completely merging GCTR into
>>> CounterMode in case of incompatibilities.  All tests security and
>>> hotspot tests pass.
>>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/
>> This change looks good to me. Trivially, the class-level comment in
>> GCTR should be updated ( it refers to removed fields ). Also,
>> CounterMode.counter could be protected ( rather than package-private ).
>> -Chris.
> Thanks Chris,
> I left CounterMode.counter as package-private because the package is
> what becomes the SunJCE provider.  I don't believe there should be any
> outside package classes accessing this code.

I agree it is better to keep it package-private since the field is not 
intended to be ever accessed outside the package, and keeping it 
package-private is in general a better practice for writing secure code. 
See also Guideline 4-1 of Java Secure Coding Guidelines: 


More information about the security-dev mailing list