[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