On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT <r...@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 >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev