WIP: supports mutable IV in GcmParams, close #225

[zkonge]

so that some PKCS11 implementation (like AWS CloudHSM) could write random IV into it.

Fixes #225

[wiktor-k]

I'm not using this scheme personally but the underlying issue seems real and the trade-offs in this solution reasonable.

Wdyt @hug-dev @ionut-arm @keldonin et al?

[zkonge]

Although the trait constraint for Mechanism is enough for the alias rule:

Mechanism: !Clone+!Send

I open another branch 43c8863 that make all operations use the owned Mechanism.

It's not necessary, but I think it can give us (and the compiler) more restrictions on when we can get things wrong.

Any ideas about that? And is there anyone prefer passing the mutable reference instead of owned data?

[wiktor-k]

Any ideas about that? And is there anyone prefer passing the mutable reference instead of owned data?

Wait, I thought mutable ref would allow the PKCS11 implementation to set these fields that are to be read by the caller, which would be impossible when using owned data? (unless the owned object is being returned from the function too).

Btw, I think we can resume work on this given recent changes in main.

Sorry for the delays @zkonge 🙇

[fiercelybearded]

Hello, I'm curious if there's any update on this one? I know this PR is out of date with the current release, 0.9.0, but I was able to make the same changes to an updated branch and I have success with AES GCM on AWS CloudHSM. I've verified that the mutable reference allows the IV to be provided back to the caller. This is with the V5 cloudhsm pkcs11 client.

The changes don't seem to affect anything with SoftHSM tests, and my Luna SA works with it as well.

[wiktor-k]

Hmm... good question. We regularly have "contributor missing-in-action" situations here but it looks like all checks passed and the PR is merge-able so we could take it as is.

@hug-dev what do you think about merging it as is?

[hug-dev]

I think it's fine since we agreed in #225 that the approach of passing &mut Mechanism should be done everywhere.

Although I would have liked a bit more comments on the reason of the mutability I think this is fine! We should complete this at some point moving all operations to &mut Mechanism as described in the issue.

Better to merge this as is if more people can benefit from it :)

[wiktor-k]

Yep, totally agreed on all points. Thanks for your time, Hugues 🙇