> 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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
