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

[David Benjamin via RT]

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 chacha-x86.pl and allowing any out <= in overlap, or declaring
that you want out == in (or something else) with, at minimum, a
documentation change.

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.)

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.)

Given the numbers in
https://mta.openssl.org/pipermail/openssl-dev/2016-March/005625.html
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.

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.

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.

David

On Fri, Mar 4, 2016 at 7:24 AM 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.
>
> Fear is irrational and destructive feeling. Having faith that world is
> better than that it nothing but healthy :-) What I'm saying is that
> let's put a little bit more substance into discourse. Would anybody
> consider it *sane* programming practice to rely on partially overlapping
> buffers in *general* case? I.e. without actually *knowing* (as opposite
> to *assuming*) what's gong on? [Control question: does compiler
> guarantee order of references to memory?] As said in last message I
> don't consider it sane and even consider it natural [which means that
> I'd expect majority to not consider it sane too].
>
> Once again, I'm not saying that nothing would be done, I simply want to
> figure out where does line go. From my personal view point I'd say that
> nothing *has to* be done, but it's just me. You seem to say that we're
> obliged to support partially overlapping buffers. My question then is
> *any* overlap, *any* cost? Shall we settle for simply writing down that
> application developer may not rely on partially overlapping buffers? If
> so, do we fix the modules in question arguing that this quality might be
> desirable in different context [where modules in question can be used]?
>
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
> Please log in as guest with password guest if prompted
>
>

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