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

Reply via email to