[Haskell-cafe] Tor project

[Tobias Florek]

 > [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_side_h264.html

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