[random delay for mitigating side channel attacks]
that is not enough. to mitigate _network attacks_ you need at least predictable random delay. i was toying around in adding that to vincent hanquez tls library but did not find the time to do that in the end. it would be great to see others do that of course :). talk from sebastian schnitzler on 29c3: http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_si... slides: http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf abstract: http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf it should be stressed that delay does only help against network side channels. if you have an attacker on the same physical hardware, you will at least need branchless code. that is a very hard problem. i think it's pretty much impossible to solve that problem in haskell alone. maybe with a dsl that generates code it's possible though. cryptol looks interesting in that regard (whenever it gets back it code generators). offloading the computation to a fpga that only you have access to should solve cache-line side-channels. http://cryptol.net regarding observable gc behavior it's interesting to see tedu's recent blogpost about attacking string compare in lua. http://www.tedunangst.com/flak/post/timing-attacks-vs-interned-strings tob