Re: Security Diligence

On Feb 8, 2014, at 9:23, Lester Caine <lester@lsces.co.uk> wrote: > > Specifically looking at the 'timing attack', as I understand it, if a comparison > process scans all elements and simply sets a flag when failure is detected which is not used until > all characters have been processed. Which is the reason for establishing 'safely' the > number of characters involved. Using 64bit functions rather than 32bit will also change the way that > process works? I think the one simple detail you are missing is that many/most string comparisons will short-circuit as soon as it hits a character that doesn't match. If you think about that a little bit I am sure you can think of a nice algorithm for narrowing in on the password character by character. That is, if 'aaaa' consistently takes longer to compare against the password compared to 'bbbb' then there is a good chance that the first character of the password is 'a'. Looking at the firebird implementation that seems to be the case there as well. Of course, network jitter and other factors make this a complicated attack, but that doesn't change the fact that there is a faint signal there and with enough iterations it has been proven to be possible to separate that signal from the noise. As a fun little experiment for yourself, try implementing an iterative timing attack against your local Firebird database password and see if you can find the signal in the noise. -Rasmus