RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Sean Mullan]

On 5/2/18 11:23 AM, Jamil Nimeh wrote:
>> Ok. I think as long as these fields are never dependent on previous 
>> values if you call engineInit again, then it is ok. In other words, 
>> they should be the same even if the previous call to engineInit throws 
>> an Exception. It might be safer as the first thing you do to 
>> re-initialize these each time engineInit is called.
>>
> JN: Yeah, earlier this morning I found a sequence that the half-baked 
> state of the object was a problem.  So I'm shuffling around the order 
> that these parameters get set in the ChaCha20 object so it happens later 
> in the method as you suggested earlier. Basically if you init the object 
> with an unsupported mode like Cipher.UNWRAP_MODE, that gets pinned to 
> the object and subsequent inits where the mode is corrected fail.  The 
> stack trace on the second init never makes it into ChaCha20's code, so 
> I'm not sure if something is set in Cipher itself that persists from 
> init to init. But setting these fields at the end of the init process is 
> a better way to do it regardless.

Another (I think simpler) option is to have a private method like 
initState() or initFields() which initializes all these fields to their 
default values and always call it as the first thing engineInit does.

--Sean