RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Sean Mullan]

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: 
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4

--Sean