Correct off-by-one in minimum output buffer size computation

[alex]

If there was a full block in the buffer, it would have already been returned.

[davidben]

Are you sure this is correct? The documentation says:

The amount of data written depends on the block alignment of the encrypted data. For most ciphers and modes, the amount of data written can be anything from zero bytes to (inl + cipher_block_size - 1) bytes. For wrap cipher modes, the amount of data written can be anything from zero bytes to (inl + cipher_block_size) bytes. For stream ciphers, the amount of data written can be anything from zero bytes to inl bytes. Thus, out should contain sufficient room for the operation being performed.

https://www.openssl.org/docs/man3.1/man3/EVP_DecryptUpdate.html

Really the problem is that EVP_CIPHER is simply not suitable to be wrapped generically like this. rust-openssl's strategy of "exposing the underlying library" is unsound here. You have to know details about the cipher to accurate size it. (I'm going to file a bug with OpenSSL about this. This is a terrible API.)

[alex]

Pretty sure it's correct -- we've used the same math for pyca/cryptography for a gazillion years :-)

If you think about it, it makes sense: the buffer will always contain less than one bock (if it had a whole block, it would have returned it previously).

[davidben]

Depends on which modes are reachable here. As it says, cipher_block_size-1 is correct for most ciphers, but not all. The wrap mode ciphers have a block sizes of 8...
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/evp/e_aes.c#L3872

...but they write inlen + 8 bytes:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/evp/e_aes.c#L3857
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/modes/wrap128.c#L80

Unfortunately, since this crate exposed EVP_get_cipherbyname (I definitely wouldn't have...), you have to worry about all possible EVP_CIPHERs. There's probably also a future-proofing problem too. Based on OpenSSL's documentation, it's unclear whether they've promised that they will never add a new kind of EVP_CIPHER that requires an even larger output. Saying "you have to know what kind of cipher you've got" would be perfectly coherent, but incompatible with rust-openssl's API decisions.