On Thu, Jul 31, 2014 at 2:11 PM, Wojtek Narczyński
But, AFAIK, the (necessary and sufficient) protection against timing attacks is the addition of randomized waits. In the protocol layer, not in pure encryption/decryption/hashing routines.
I agree that we don't have a lot of evidence for/against timing attacks in functional languages (that I know of). But adding a randomized delay never seemed the correct solution to me (granted, I had the luck to never had to write code sensitive to such issues, and I never wrote a timing attack exploit either), I don't think that doing it in the protocol layer makes it neither necessary nor sufficient. http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ This explains the pitfalls in some possible timing attack misconceptions -- xmpp: berdario@gmail.com bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just for signing commits)