[openssl-project] to fully overlap or not to

[Andy Polyakov]

>>> I'd like to request more opinions on
>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>> whether or not following fragment should work
>>>
>>>     unsigned char *inp = buf, *out = buf;
>>>
>>>     for (i = 0; i < sizeof(buf); i++) {
>>>         EVP_EncryptUpdate(ctx, out, &outl, inp++, 1);
>>> 	out += outl;
>>>     }
>>
>> This should work.
>>
> 
> It does only work, if you know that ctx->buf_len == 0
> before the loop is entered.

It's naturally implied that ctx is used *consistently*. I mean it's not
like it's suggested that you can just use the above snippet in random
place. Application would have to adhere to above pattern all along, for
the life time of in-place processing "session". [I write "session" in
quotes, because there might be better term.]

> It does not work with CFB1, CCM, XTS and WRAP modes.

Yes, some modes are so to say "one-shot", i.e. you have to pass all the
data there is at once, no increments are allowed. But what does it have
to do with question at hand, question about in-place processing that is?
These two things are independent. So that question is rather should the
snippet work in cases when incremental processing is an option. Related
thing to recognize in the context is that *disputable* condition, the
one that triggered this discussion, is exercised only when
ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
it's special...

> There is no access function to get the internal state of the cipher
> context.

But there is notion of in-place processing "session".

> I the documentation does not cover this at all, and most of
> all I really wonder how the wording could look like.

That in-place processing "session" would be customarily tied up with
call to EVP_EncryptFinal[_ex]?