(author here) Getting around timing attacks is not too different in Haskell from doing the same thing in C. First, there's 2 different classes of timing issues

(author here) Getting around timing attacks is not too different in Haskell from doing the same thing in C. First, there's 2 different classes of timing issues: 1) cryptographic ones 2) and the others (for the lack of better classification) For cryptographic ones, it's hard to enumerate all the counter measures used/not used, but some examples: - use of blinding with RSA - with ghc 7.8, exponiantiation is using GMP expmod_safe - AES is using native instruction when possible. - Use of scrubbed memory/memory constant where possible - some lowlevel cryptographic implementations are actually in C (hash, aes, ..) Also, while I'm linking against specific set of cryptographic implementations by default, there's nothing preventing anyone from pulling different crypto implementations from other places. For the other issues, it's usually just a deal of strictness, and not bailing/notifying error too early. (e.g. This is what Bleinchenbacher and CRIME are all about). - data comparaison is time constant by comparing all bytes where necessary: prevent padding attack - there's routines to evaluate boolean values without bailing too early (False && ... -> would bail at the first false) - lots of part in tls is using strict bytestring, and strict values. - the GC is adding a lot of noise potentially hiding timing issues, potentially exacerbated by pure values instead of mutable values (like you would in C) Also, I don't want to claim there's no issues or ever will be. Hopefully there's no such things, but I welcome any audits and questions about stuff that look fishy. But people shouldn't only looks at the cryptographic side of security; openssl had so many issues about basic unchecked values, buffer underflow, overflow that's not even funny anymore. Just sayin'