Move cipher ctx 'original iv' parameter into the provider

[slontis]

Checklist

• documentation is added or updated
• tests are added or updated

[levitte]

Naming wise, I wonder if the parameter isn't a bit misnamed. What does "original" mean? What origin does it refer to? So I wonder if it wouldn't be better to call it "initial IV", to express that it's the IV that was specified when initializing the cipher, i.e. when calling EVP_CipherInit & friends.

(remember that EVP_CipherInit can be called more than once on the same context, so "original" would make me wonder if it's the IV from the first EVP_CipherInit on the same context, or the last, if I didn't know the code as well as I do)

[levitte]

Speaking of IV, I'm starting to wonder why we even share the running IV (which, strictly speaking, isn't an IV any more) from providers. With legacy code, I fully understand, because all back-ends needed to access the IV that was centrally stored in the EVP_CIPHER_CTX instead of their own private context. With provided implementations that hold the IV in the own private context, there should be about zero need to share that one, just the actual initialization vector.

In other words, there should really just be a OSSL_CIPHER_PARAM_IV, and it should only access what we currently call "the original IV".

Perhaps this is a matter for another PR. I'll be happy to oblige.

[beldmit]

I need to look at it more thoroughly. GOST TLS requires an original IV as a source to derive the per-packet IV. See https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-05#section-4.1.1 for details.

[slontis]

there should really just be a OSSL_CIPHER_PARAM_IV, and it should only access what we currently call "the original IV".

Good point - If there is a need for the running IV (which I dont think there is now) we would add it later.
I have removed the references to the original iv param - and it seems to work fine.

[slontis]

need to look at it more thoroughly. GOST TLS requires an original IV as a source to derive the per-packet IV. See https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-05#section-4.1.1 for details.

TLS related ciphers normally use a seperate mechanism via some ctrls to set the fixed_iv and aad so this should not be an issue.

[slontis]

Updated

[slontis]

rebased due to simple merge conflict in header ciphercommon.h. Approval should still apply.

[levitte]

Approval should still apply.

Not formally. A re-review will confirm that you didn't goof up the merge fixups

[slontis]

Thanks.. Merged to master.