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

Emilia Käsper emilia at openssl.org
Fri Mar 4 11:52:56 UTC 2016

On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT <rt at openssl.org> wrote:

> > 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'm afraid that, since we haven't documented it, the world may already have
made that assumption.

> 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
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160304/bc19fe1b/attachment-0001.html>

More information about the openssl-dev mailing list