diff options
author | Benjamin Kaduk <bkaduk@akamai.com> | 2020-06-19 13:50:22 -0700 |
---|---|---|
committer | Benjamin Kaduk <bkaduk@akamai.com> | 2020-08-11 07:07:37 -0700 |
commit | 8489026850b38447d8e3e68c4d4260585b7e8e3a (patch) | |
tree | 512566541ac0e18ae54c4327dabb58316d97bbea /doc | |
parent | 31d2daecb384475da13c4bf7c76a2dde0077b2f2 (diff) | |
download | openssl-8489026850b38447d8e3e68c4d4260585b7e8e3a.tar.gz |
Support cipher provider "iv state"
Some modes (e.g., CBC and OFB) update the effective IV with each
block-cipher invocation, making the "IV" stored in the (historically)
EVP_CIPHER_CTX or (current) PROV_CIPHER_CTX distinct from the initial
IV passed in at cipher initialization time. The latter is stored in
the "oiv" (original IV) field, and has historically been accessible
via the EVP_CIPHER_CTX_original_iv() API. The "effective IV" has
also historically been accessible, via both EVP_CIPHER_CTX_iv()
and EVP_CIPHER_CTX_iv_noconst(), the latter of which allows for
*write* access to the internal cipher state. This is particularly
problematic given that provider-internal cipher state need not, in
general, even be accessible from the same address space as libcrypto,
so these APIs are not sustainable in the long term. However, it still
remains necessary to provide access to the contents of the "IV state"
(e.g., when serializing cipher state for in-kernel TLS); a subsequent
reinitialization of a cipher context using the "IV state" as the
input IV will be able to resume processing of data in a compatible
manner.
This problem was introduced in commit
089cb623be76b88a1eea6fcd135101037661bbc3, which effectively caused
all IV queries to return the "original IV", removing access to the
current IV state of the cipher.
These functions for accessing the (even the "original") IV had remained
undocumented for quite some time, presumably due to unease about
exposing the internals of the cipher state in such a manner.
Note that this also as a side effect "fixes" some "bugs" where things
had been referring to the 'iv' field that should have been using the
'oiv' field. It also fixes the EVP_CTRL_GET_IV cipher control,
which was clearly intended to expose the non-original IV, for
use exporting the cipher state into the kernel for kTLS.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Diffstat (limited to 'doc')
-rw-r--r-- | doc/man7/provider-cipher.pod | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod index ee159ff7eb..d6d544c0ba 100644 --- a/doc/man7/provider-cipher.pod +++ b/doc/man7/provider-cipher.pod @@ -240,7 +240,14 @@ The length of the "ivlen" parameter should not exceed that of a B<size_t>. =item "iv" (B<OSSL_CIPHER_PARAM_IV>) <octet string OR octet ptr> -Gets the IV for the associated cipher ctx. +Gets the IV used to initialize the associated cipher ctx. + +=item "iv-state" (B<OSSL_CIPHER_PARAM_IV_STATE>) <octet string OR octet ptr> + +Gets the current pseudo-IV state for the associated cipher ctx, e.g., +the previous ciphertext block for CBC mode or the iteratively encrypted IV +value for OFB mode. Note that octet pointer access is deprecated and is +provided only for backwards compatibility with historical libcrypto APIs. =item "num" (B<OSSL_CIPHER_PARAM_NUM>) <unsigned integer> |