[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Andy Polyakov via RT]

> If the other EVP ciphers universally allow this then I think we must treat this
> as a bug, because people may be relying on this behaviour. There is also
> sporadic documentation in lower-level APIs (AES source and des.pod) that the
> buffers may overlap.
> 
> If it's inconsistent then, at the very least, we must document that it is not
> allowed.

I'd like to argue that EVP is not place to provide any guarantees about
partially overlapping buffers. Even though all current ciphers process
data in ascending address order, we shouldn't make assumption that there
won't be one that processes data in reverse order. I'd even argue that
not providing such guarantee is natural, i.e. can be naturally
*implied*. Just like you may not expect a tablet to work after you glued
wheels to it to make a skateboard, arguing that nowhere does it say that
it's not a viable idea. It might work, and apparently did for somebody,
but you may not *expect* it to, neither as tablet or skateboard. And
tablet manufacturer has no obligation to disclaim it in writing.

I'm not saying that this particular problem can't/won't be addressed,
though I consider it kind of bad style. Because it kind of sets a
precedent of creating an undesired illusion. BTW, further measurements
have shown that unlike others, Core2 suffers 20% performance regression.
Well, one can argue that nobody cares about Core2, but what if it was
contemporary processor?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted