<div dir="ltr">The current state is that, as far as I can tell, overlapping requirements are undocumented (or is it somewhere and I missed it?) and, for ChaCha, architecture-specific. I think something certainly needs to be done. Either changing <a href="http://chacha-x86.pl">chacha-x86.pl</a> and allowing any out <= in overlap, or declaring that you want out == in (or something else) with, at minimum, a documentation change.<div><div><br></div><div>I would actually suggest going further and updating EVP_CipherUpdate to enforce the rule and raise an error if the caller doesn't honor it. Otherwise we'll continue to be in the situation where callers may write code that works on some architectures but not others. (BoringSSL's EVP_AEAD API will fail with OUTPUT_ALIASES_INPUT if aliasing requirements aren't honored.)<br><br>Actually, I'm not sure how to best translate an out == in rule to streaming EVP_CipherUpdate for block ciphers. Imagine feeding one byte at a time to EVP_CipherUpdate, in will naturally get ahead of out and then synchronize at block boundaries, so the rule can't be as straight forward as "out == in". (Whereas out <= in naturally covers this behavior.)<div><br></div><div>Given the numbers in</div><div><a href="https://mta.openssl.org/pipermail/openssl-dev/2016-March/005625.html">https://mta.openssl.org/pipermail/openssl-dev/2016-March/005625.html</a></div><div>the cost seems fairly modest and this is only for 32-bit, not 64-bit. Based on that, and that other implementations I've tested handle the case fine, I think this is a reasonable requirement to impose.</div><div><br></div><div>Of course, I am also biased here because out == in will cause me some nuisance. :-) One can certainly argue that out == in is perhaps easier to handle than out <= in and it is not worth allowing it.</div><div><br></div><div>Either way, I'm not an OpenSSL team member and can't make a decision on behalf of you all. This is something you all have to pick from.<br><div><br></div><div>David</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 4, 2016 at 7:24 AM Andy Polyakov via RT <<a href="mailto:rt@openssl.org">rt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>> If the other EVP ciphers universally allow this then I think we must<br>
>> treat this<br>
>>> as a bug, because people may be relying on this behaviour. There is also<br>
>>> sporadic documentation in lower-level APIs (AES source and des.pod) that<br>
>> the<br>
>>> buffers may overlap.<br>
>>><br>
>>> If it's inconsistent then, at the very least, we must document that it<br>
>> is not<br>
>>> allowed.<br>
>><br>
>> I'd like to argue that EVP is not place to provide any guarantees about<br>
>> partially overlapping buffers. Even though all current ciphers process<br>
>> data in ascending address order, we shouldn't make assumption that there<br>
>> won't be one that processes data in reverse order.<br>
><br>
><br>
> I'm afraid that, since we haven't documented it, the world may already have<br>
> made that assumption.<br>
<br>
Fear is irrational and destructive feeling. Having faith that world is<br>
better than that it nothing but healthy :-) What I'm saying is that<br>
let's put a little bit more substance into discourse. Would anybody<br>
consider it *sane* programming practice to rely on partially overlapping<br>
buffers in *general* case? I.e. without actually *knowing* (as opposite<br>
to *assuming*) what's gong on? [Control question: does compiler<br>
guarantee order of references to memory?] As said in last message I<br>
don't consider it sane and even consider it natural [which means that<br>
I'd expect majority to not consider it sane too].<br>
<br>
Once again, I'm not saying that nothing would be done, I simply want to<br>
figure out where does line go. From my personal view point I'd say that<br>
nothing *has to* be done, but it's just me. You seem to say that we're<br>
obliged to support partially overlapping buffers. My question then is<br>
*any* overlap, *any* cost? Shall we settle for simply writing down that<br>
application developer may not rely on partially overlapping buffers? If<br>
so, do we fix the modules in question arguing that this quality might be<br>
desirable in different context [where modules in question can be used]?<br>
<br>
<br>
<br>
--<br>
Ticket here: <a href="http://rt.openssl.org/Ticket/Display.html?id=4362" rel="noreferrer" target="_blank">http://rt.openssl.org/Ticket/Display.html?id=4362</a><br>
Please log in as guest with password guest if prompted<br>
<br>
</blockquote></div></div></div></div></div></div>