[openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

On 12/11/15 17:41, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Andy Polyakov
>> Sent: Friday, December 11, 2015 10:07
>> To: openssl-users at 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).
>>
>> Hardcoded 8 is not reference to char C type, but to units in which
>> sizeof(variable) is measured. For example when we say ILP32 or LP64,
>> what do we mean and what role does 8 play in the drama?
> 
> The distinction you're drawing is meaningless.

Right, I've let practical myself talk too soon, sorry. Yet we do adhere
to ILP notion when describing platform requirement, so 8 is kind of
implied anyway. But in case one chooses to switch to CHAR_BIT. I want to
remind that not all platforms OpenSSL [still] supports are sufficiently
standard compliant. There are platforms that are *partially* compliant
or stuck between standards. But I'd say that it would be safe to assume
that if CHAR_BIT is not defined, then it's 8.

> (Also, such platforms are generally DSPs which are not likely to be
> able to run OpenSSL anyway.)

As fun fact, OpenSSL does run on TI C6000 series DSP and even optimized
for C64x+ and forward.

Anyway, this has little to do with problem at hand, as all assumptions
made implicitly or explicitly do apply to the platform in question. If
it turns to be compiler bug, then no argument about standard compliance
would justify it. And we'll face the usual dilemma, do we give in and
arrange a kludge (e.g. with #ifdef _MSC_VER), or send user to said
compiler vendor... Latter is kind of counter-productive, former is
<blank>...