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