Sorry - I thought this topic had come up again (or that this was a new
continuation of the older discussion). Now I see it was an old message that had
been delayed. Apologies for the noise.
--
Michael Wojcik
Technology Specialist, Micro Focus
___
op
On 07/01/2016 15:52, Michael Wojcik wrote:
The proposed change:
--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-
produces an implementation-defined value in C99
The proposed change:
--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-
produces an implementation-defined value in C99. See the final sentence of ISO
9899-1999 6.
> 1. With compiler optimization disabled, OpenSSL 1.0.2d function worked
> as it is.
Another indication in favour of compiler bug is that it worked when you
added printf. It's similar to quantum physics when by measuring you
force particle to specific state. But understand me correctly. I'm not
sa
Hi All,
1. With compiler optimization disabled, OpenSSL 1.0.2d function worked as
it is.
2. Looks like in the below functions, typecast to unsigned char to is not
going well when compiler optimization is enabled. Hence functions are
modified to assign the return value to a volatile unsigned char a
Hi All,
Thanks for all the responses. As mentioned by Matt in the discussion
thread,constant_time_msb performs the copy the msb of the input to all of
the other bits so the return value should either be one of 0x or
0x.
I found another interesting thing,constant_time_msb worke
> 3. The compiler wasn't written by a fanatic who put
> the "right shift of negative signed values is
> undefined" rule above common sense.
>
> This is only implementation-defined behavior, not undefined behavior. It is
> not permitted to crash the system or launch the missiles. (n1256.pdf 6.
On 12/11/15 17:41, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Andy Polyakov
>> Sent: Friday, December 11, 2015 10:07
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] CBC ciphers + TLS
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>> }
>>
>>
>> ... Both versions
>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
>> bits).
>
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Andy Polyakov
> Sent: Friday, December 11, 2015 10:07
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
> OpenSSL 1.0.2d
>
> >&
>> static inline unsigned int constant_time_msb(unsigned int a) {
>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>> }
>
>
> ... Both versions
> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
> bits).
Hardcod
>>> C does not make such a guarantee, though recent-ish POSIX does. (This
>>> system is a windows one, thought, right?)
>> There are DSPs that only support 32 bit, they don't have a concept
>> of 8 bit. But I think there is various code that assumes that
>> char is 8 bit, and I doubt you can get
On 11/12/2015 00:16, Kurt Roeckx wrote:
On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:
C does not make such a guarantee, though recent-ish POSIX does. (This
system is a windows one, thought, right?)
There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.
On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a
On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:
> C does not make such a guarantee, though recent-ish POSIX does. (This
> system is a windows one, thought, right?)
There are DSPs that only support 32 bit, they don't have a concept
of 8 bit. But I think there is various code that
On 10/12/2015 19:13, Benjamin Kaduk wrote:
On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:
On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote:
On 10/12/2015 18:33, Viktor Dukhovni wrote:
On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
static inline unsigned int cons
On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:
>> On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote:
>>
>> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>>>
>>>
static inline unsigned int constant_time_msb(unsigned in
> On Dec 10, 2015, at 12:45 PM, Jakob Bohm wrote:
>
> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>>
>>
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> - return 0 - (a >> (sizeof(a) * 8 - 1));
>>> + re
On 12/10/2015 11:45 AM, Jakob Bohm wrote:
> 3. The compiler wasn't written by a fanatic who put
> the "right shift of negative signed values is
> undefined" rule above common sense.
This is only implementation-defined behavior, not undefined behavior.
It is not permitted to crash the system o
On 10/12/2015 18:33, Viktor Dukhovni wrote:
On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
static inline unsigned int constant_time_msb(unsigned int a) {
- return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
The replacement i
On 10/12/2015 17:53, Matt Caswell wrote:
On 10/12/15 11:55, Jayalakshmi bhat wrote:
Hi Matt,
Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.
static inline unsigned int constant_time_msb(unsigned int a) {
-*return
On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
> static inline unsigned int constant_time_msb(unsigned int a) {
> - return 0 - (a >> (sizeof(a) * 8 - 1));
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }
The replacement is not right. This function is supposed
On 10/12/15 17:04, Benjamin Kaduk wrote:
> On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> Thanks for the patch. Unfortunately patch did not work. I continued
>> debugging and found that issue was in constant_time_msb.
>>
>> static inline unsigned int constant_time_msb(unsigned
On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 -
On Thu, Dec 10, 2015 at 6:55 AM, Jayalakshmi bhat
wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -return 0 - (a >> (sizeof(
On 10/12/15 11:55, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1
Hi Matt,
Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.
static inline unsigned int constant_time_msb(unsigned int a) {
-*return 0 - (a >> (sizeof(a) * 8 - 1));*
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1
On 09/12/15 23:13, Benjamin Kaduk wrote:
> On 12/09/2015 05:04 PM, Matt Caswell wrote:
>>
>> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>>> Hi Matt,
>>>
>>> I could build and execute the constant_time_test. I have attached the .c
>>> file and test results. 34 tests have failed. All failures are
>
On 10/12/15 04:47, Viktor Dukhovni wrote:
> On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:
>
>> unsigned char c = op(a, b);
>> if (is_true && c != CONSTTIME_TRUE_8) {
>> printf( "Test failed for %s(%du, %du): expected %u "
>> "(TRUE), got %u at line
On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:
> unsigned char c = op(a, b);
> if (is_true && c != CONSTTIME_TRUE_8) {
> printf( "Test failed for %s(%du, %du): expected %u "
> "(TRUE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_TRUE_8, c,__LINE_
On 12/09/2015 05:04 PM, Matt Caswell wrote:
>
> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> I could build and execute the constant_time_test. I have attached the .c
>> file and test results. 34 tests have failed. All failures are
>> around constant_time_eq_8. This is the function I
On 09/12/15 11:44, Jayalakshmi bhat wrote:
> Hi Matt,
>
> I could build and execute the constant_time_test. I have attached the .c
> file and test results. 34 tests have failed. All failures are
> around constant_time_eq_8. This is the function I had mentioned in the
> earlier mails.
Not quite
Could you extract the disassembly of one of the failed
calls to constant_time_eq_8() in the test program, perhaps
the compiler generates incorrect code for this deeply
nested group of near-edge arithmetic operations?
On 09/12/2015 12:44, Jayalakshmi bhat wrote:
Hi Matt,
I could build and execut
On 08/12/15 17:27, Jakob Bohm wrote:
> On 08/12/2015 11:57, Matt Caswell wrote:
>> On 07/12/15 05:18, Jayalakshmi bhat wrote:
>>> Hi All,
>>>
>>> Is there inputs or suggestions.
>> Have you run the tests on this platform? i.e. "make test"
>>
>> I'm particular interested to know if the constant_ti
On 08/12/2015 11:57, Matt Caswell wrote:
On 07/12/15 05:18, Jayalakshmi bhat wrote:
Hi All,
Is there inputs or suggestions.
Have you run the tests on this platform? i.e. "make test"
I'm particular interested to know if the constant_time_test passed.
He can't. WinCE is not a self-hosting pla
On 07/12/15 05:18, Jayalakshmi bhat wrote:
> Hi All,
>
> Is there inputs or suggestions.
Have you run the tests on this platform? i.e. "make test"
I'm particular interested to know if the constant_time_test passed.
Matt
>
> Thanks and Regards
> Jaya
>
> On Fri, Dec 4, 2015 at 11:37 AM, Ja
Hi Jakob,
Here are more details,
OS WinCE 6.0
CPU ARMARCH4.
Family ARM
Compiler ARM CC
VersionMicrosoft (R) C/C++ Optimizing Compiler Version 14.01.60511 for
ARM
Regards
Jaya
On Fri, Dec 4, 2015 at 5:35 AM, Jakob Bohm wrote:
> For clarity, which version of WinCE,
l.org
Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
OpenSSL 1.0.2d
Hi All,
Is there inputs or suggestions.
Thanks and Regards
Jaya
On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat
mailto:bhat.jayalaks...@gmail.com>> wrote:
Hi Matt,
s3_cbc.c uses t
Hi All,
Is there inputs or suggestions.
Thanks and Regards
Jaya
On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat <
bhat.jayalaks...@gmail.com> wrote:
> Hi Matt,
>
> s3_cbc.c uses the function constant_time_eq_8. I pulled only this
> function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d.
Hi Jakob
CPU is ARMARCH4. WinCE version is 6.0. I will get the compiler details
shortly.
Regards
Jaya
On Fri, Dec 4, 2015 at 6:05 PM, Jakob Bohm wrote:
> For clarity, which version of WinCE, and which CPU (Arm,
> MIPS, PPC, x86, SH3, SH4, ...)?
>
> Which Microsoft Compiler version (EVC3, EVC4,
Hi Matt,
s3_cbc.c uses the function constant_time_eq_8. I pulled only this
function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed this
function as constant_time_eq_8_local and used it in s3_cbc.c instead of
constant_time_eq_8. This renaming was just to avoid multiple definitions.
Hi Matt,
I replaced constant_time_eq_8 usage in s3_cbc.c with the implementation
available in OpenSSL 1.0.1e. Things worked fine.
Regards
Jaya
On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell wrote:
>
>
> On 04/12/15 11:31, Jayalakshmi bhat wrote:
> > Hi Matt,
> >
> > Thanks a lot for the response
C ciphers + TLS 1.0 protocol does not work in
OpenSSL 1.0.2d
On 04/12/15 11:31, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks a lot for the response.
>
> Is your application a client or a server? Are both ends using OpenSSL
> 1.0.2d? If not, what is the other end using?
On 04/12/15 11:31, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks a lot for the response.
>
> Is your application a client or a server? Are both ends using
> OpenSSL 1.0.2d? If not, what is the other end using?
>>>Our device has both TLS client,server apps. As client, device communicates
>>>wi
For clarity, which version of WinCE, and which CPU (Arm,
MIPS,PPC, x86, SH3, SH4, ...)?
Which Microsoft Compiler version (EVC3, EVC4, one of the
Visual Studio projects, 3rd party compiler) and which
exact compiler version (reported by running the compiler
executable (named according to CPU) with
Hi Matt,
Thanks a lot for the response.
Is your application a client or a server? Are both ends using OpenSSL 1.0.2d?
If not, what is the other end using?
>>Our device has both TLS client,server apps. As client, device
communicates with radius server, LDAP server etc.As server device is
accessed
Hello Jaya
We're going to need some more information. There isn't a generic problem
with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
there is something specific about your environment that is causing the
issue. Comments inserted below.
On 04/12/15 06:53, Jayalakshmi bhat wrot
Hi All,
Recently we have ported OpenSSL 1.0.2d. Everything works perfect except the
below explained issue.
When we enable only TLS 1.0 protocol and select CBC ciphers, TLS handshake
fails with the error "bad record mac".
Error is in function static int ssl3_get_record(SSL *s). Error happen
48 matches
Mail list logo
