On 03/29/18 16:07, Andy Polyakov wrote: > On 03/09/18 17:13, Bernd Edlinger wrote: >> >> 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.
Once again: - This PR *recognizes* the fact that special cases do in fact *exist*. - The EVP layer has to be more aware of special cases anyhow. - The test coverage of error cases is not perfect, but I try to improve that. - I don't see why we can't relax a check in cases that are known to work, especially when test cases are added at the same time. _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
