Resolved by overlapping buffer checks. Closing.
Matt
--
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
Not defined means we make no guarantees. OpenSSL can depend on what it knows
to be true. In the next release we can revisit this.
--
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 unsubscr
I don't think that will work. The SSL code uses in-place buffers
extensively, so in == out definitely needs to be defined. The question is
only whether out < in is also acceptable.
Either way, for BoringSSL, I've gone ahead and tightened our aliasing
constraints to forbid out < in and require equa
I think for now, we just note this in the documentation: behavior for
overlapping buffers, and even in-place buffers, is not defined.
It's like memcpy() vs memmove().
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted
--
ope
Brian Smith wrote:
> It seems that 32-bit ARM has the same limitation as x86 that the input and
> output pointers must match or the input and output buffers must not overlap
> at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has
> this issue.
Just to follow up on this: I think
It seems that 32-bit ARM has the same limitation as x86 that the input and
output pointers must match or the input and output buffers must not overlap
at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has
this issue.
Cheers,
Brian
--
https://briansmith.org/
--
Ticket here: ht
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
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
>> 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
>> buff
> On Mar 4, 2016, at 7:24 AM, Andy Polyakov via RT wrote:
>
> 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* pr
>>> 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 inconsiste
On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT 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) th
On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT 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) th
> 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 th
> I'm unclear on what EVP_CIPHER's interface guarantees are, but our EVP_AEAD
> APIs are documented to allow in/out buffers to alias as long as out is <=
> in. This matches what callers might expect from a naive implementation.
>
> Our AES-GCM EVP_AEADs, which share code with OpenSSL, have tended
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, w
I'm unclear on what EVP_CIPHER's interface guarantees are, but our EVP_AEAD
APIs are documented to allow in/out buffers to alias as long as out is <=
in. This matches what callers might expect from a naive implementation.
Our AES-GCM EVP_AEADs, which share code with OpenSSL, have tended to match
t
17 matches
Mail list logo
