From: "Martin Boßlet" <martin.bosslet@...>
Date: 2012-05-29T18:09:26+09:00
Subject: Re: does this leak more than the size of the string via timing side channels

2012/5/29 rooby shoez <lists@ruby-forum.com>:
> Thanks for the advice I will probably go with your technique Martin. I
> am considering using your technique as well as the original solution I
> inquired about. I have a question though, will it work to compare every
> character or will it also return false as soon as it detects that one is
> not = ?

I'm not sure I fully understand, where exactly in your code would that be?

> def message_authentic?(ciphertext, key, mac)
>
> computed_mac =
> OpenSSL::Digest::SHA256.new(OpenSSL::HMAC.digest(OpenSSL::Digest::SHA256.new,OpenSSL::Digest::SHA256.new("mac"
> + key).to_s, ciphertext))
>
> provided_mac = OpenSSL::Digest::SHA256.new(mac)
> comparisons = [true]
> computed_mac.length.times do |i|
> a += [string1[i] == string2[i]]
> end
> comparisons.inject(:==)
> end
>
> Is it at all beneficial to add the second way of comparison as well or
> is it just as protected with == after the hash values have been
> obtained? And you are pretty confident that this is no vulnerable to
> timing side channels ?

Yes, it was also recommended by Dan Boneh during his online
cryptography course, and he can be trusted :)
The comparison of the hashes can be done using plain ==, as there's
nothing to be gained from timing this comparison. Even if you figure
out the hashes by timing them, it's not possible to get to the original
value from there.
Then again computing the hash itself from the original value is also not
vulnerable because the algorithm for the hash will always take the same
time as it ideally doesn't care about its underlying input and won't take
different code paths for different inputs.


-Martin