Date: Fri, 25 Oct 2013 13:36:45 -0600
> What reason do you have to believe that crypto is using any signed
> arithmetic? I would not.
Here's an example that's at least slightly interesting, from the latest
version of LibTomCrypt:
kappa[i] =
(key[pos ] << 24) ^
(key[pos + 1] << 16) ^
(key[pos + 2] << 8) ^
(key[pos + 3] );
key is a pointer to unsigned char. Of course, the array element becomes
signed after promotion. The shift by 24 then executes an undefined
behavior whenever the shifted value is >127.
So the interesting thing is that the developer is basically doing things
right and getting hosed by the arithmetic conversions. I'm not sure
there's a fix for this that's prettier than an explicit cast to
unsigned? That's unfortunate since it breaks the symmetry of the four
cases; of course the other three do not require the cast.
John
> arithmetic? I would not.
Here's an example that's at least slightly interesting, from the latest
version of LibTomCrypt:
kappa[i] =
(key[pos ] << 24) ^
(key[pos + 1] << 16) ^
(key[pos + 2] << 8) ^
(key[pos + 3] );
key is a pointer to unsigned char. Of course, the array element becomes
signed after promotion. The shift by 24 then executes an undefined
behavior whenever the shifted value is >127.
So the interesting thing is that the developer is basically doing things
right and getting hosed by the arithmetic conversions. I'm not sure
there's a fix for this that's prettier than an explicit cast to
unsigned? That's unfortunate since it breaks the symmetry of the four
cases; of course the other three do not require the cast.
John
Received on 2013-10-25 21:36:59