[security] Widespread Timing Vulnerabilities in OpenID implementations

Phillip Hallam-Baker hallam at gmail.com
Thu Jul 15 16:48:33 UTC 2010


What if the compiler unrolls the loop during optimization

Once unrolled it will be optimized back to the original


Sent from my iPhone

On 15 Jul 2010, at 12:41, Nate Lawson <nate at rootlabs.com> wrote:

> James A. Donald wrote:
>> On 2010-07-15 2:45 PM, Nate Lawson wrote:
>>> Starting the compare at a random point is much more difficult and
>>> error-prone than implementing a constant-time compare function.  
>>> Please
>>> see Taylor's original note, which included such a constant-time  
>>> function.
>>
>> The starting point of the compare only has to be unpredictable to the
>> attacker, rather than true random, so not so difficult.
>
> We're talking 6 lines of code for the constant time implementation  
> (not
> counting comments). I'll paste it again just to be clear:
>
> /*
> * Constant time compare for secret values.
> * Returns 0 if they are equal, non-zero if they aren't.
> */
> int
> secret_cmp(uint8_t *a, uint8_t *b, size_t n)
> {
>    int result = 0;
>
>    // Catch bad programming case of zero length
>    if (n == 0)
>        return 1;
>
>    // Compare all bytes of array, accumulating differences
>    while (n--)
>        result |= *a++ ^ *b++;
>
>    return result != 0;
> }
>
> I can't even imagine how a pseudorandom implementation can be as  
> simple
> or obviously correct/secure. Please enlighten me.
>
> -- 
> Nate Lawson
> Root Labs :: www.rootlabs.com
> +1 (510) 595-9505 / (415) 305-5638 mobile
> Solving embedded security, kernel and crypto challenges
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security


More information about the security mailing list