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
