[openssl-project] to fully overlap or not to

[Bernd Edlinger]

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.
And to document that the term "partially overlapping" is meant this way.


Bernd.