[openssl-project] to fully overlap or not to

[Andy Polyakov]

> 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?