Hello Paul,
On Wed, Dec 19, 2018 at 6:02 AM Paul Smith <paul@xxxxxxxxxxxxxxxxx> wrote:
Hi all; I'm working with OpenSSL 1.1.1a, using the EVP interface to
encrypt/decrypt with various ciphers/modes.
I had a couple of questions:
First, the encrypt update docs say:
> the amount of data written may be anything from zero bytes to
> (inl + cipher_block_size - 1)
Is that really true? For example if my block size is 16 and my input
length is 4, could the encrypt step really write as many as 19 bytes
(4 + 16 - 1)?
I would have thought that the true maximum would be round-up(inl,
cipher_block_size); that is, for inl values 1-15 you'd get 16 bytes,
and for inl values 16-31 you'd get 32 bytes, etc. (I'm not actually
sure whether inl of 16 gets you 16 or 32 bytes...)
Am I wrong about that? Would some ciphers/modes write beyond the end
of the current "block" and into the next one?
When you use a block cipher and pass data less than block size, it is stored in the internal buffer.
In this case you do not get encrypted data until there is enough plain text to encrypt the full block.
When you add more data, if you pass enough data to finalize a previously unfinished block,
you get more long ciphertext than plaintext passed in a particular call of CipherUpdate.
Second, the type of the outl parameter on EVP encrypt update is "int",
rather than (as I would have expected) "unsigned int". Is there a
possibility that EVP would set &outl to a negative value and if so,
what would that mean? Do I need to check for this in my code? Same
with inl; why isn't it "unsigned int"? Is there ever a reason to pass
in a negative value?
I strongly suspect just historical reasons here.
SY, Dmitry Belyavsky
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
