[openssl-project] to fully overlap or not to

[Andy Polyakov]

On 03/09/18 17:13, Bernd Edlinger wrote:
> On 03/08/18 12:06, Andy Polyakov wrote:
>>
>>> Andy pointed out that my last e-mail was probably not clear enough.
>>>
>>> I want to drop the current partially overlapping checks
>>> on the WRAP mode ciphers (which were ineffective anyways).
>>>
>>> And allow the following additional use case for any cipher
>>>
>>> unsigned char *in = buf + sizeof(buf) - X, *out = buf;
>>> EVP_EncryptUpdate(ctx, out, &outl, &head, sizeof(head));
>>> out += outl;
>>> EVP_EncryptUpdate(ctx, out, &outl, in, X);
>>> out += outl;
>>> EVP_EncryptUpdate(ctx, out, &outl, &tail, sizeof(tail));
>>> out += outl;
>>>
>>> with X > 75% sizeof(buf)
>>> sizeof(head), sizeof(tail) not necessary multiple of block size
>>>
>>> And make the definition of allowed in-place partially overlapping
>>> effectively be driven by the implementation requirements.
>>
>> Nobody? OK. *Formal* objection to this is that you are making assumption
>> that underlying implementation processes data in specific order. Note
>> that it's not actually unreasonable assumption(*), yet in most general
>> sense it's an assumption, and question rather is if you are in position
>> to **formally** make it(**). One can argue that all our underlying
>> implementations do that, process data in expected order that is, but it
>> doesn't lift the question. One can even argue that suggested code worked
>> in 1.0.1, yet it doesn't lift the question. So instead one simply aims
>> for not making the assumption [or making least amount of assumptions].
>> Yes, you can sense contradiction, because in-place processing also rests
>> on an assumption. Yeah, world is not ideal and life is full of
>> compromises. I mean there are pros and cons, and in-place is considered
>> to bring more pros.
>>
>> (*) And in some cases it's even 100% justified, most notably in CBC
>> encrypt case, when each block is dependent on previous.
>>
>> (**) Note that you can avoid the question by processing data strictly on
>> per-block basis, so that you'll be in control of accessing data in
>> specific order, not underlying implementation. But that's not what is
>> suggested, right?
> 
> No.  The intention is to make the partially overlapping check follow
> the underlying cipher's implementation needs, not the other way round.

I don't follow. What does "underlying cipher's implementation needs"
mean? Or aren't you making quite specific assumption about
implementation the moment you recognize its "needs"? Assumption that it
does in fact processes data in specific order? Does it need to do that?
As *hypothetic* extreme example, consider ECB mode. What prevents
implementation to process blocks in arbitrary order? And if nothing,
what effect would reverse order have for suggested approach? Once again,
I'm not saying that any of our ECB implementation do that, only that
it's *formally* inappropriate to make that kind of assumption. To
summarize, if one wants to permit partially overlapping buffers, then
the only appropriate thing to do would be to perform operations in
chunks on non-overlapping sections. However, I'm not saying that we
should do that, I'd say that it would be unjustified complication of the
code. https://github.com/openssl/openssl/pull/5427#discussion_r172441266
is sufficient.