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. _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project