Comment by joeyh | Hacker News Reader

Comment by joeyh | Hacker News Reader

Parent Full thread

http://hackage.haskell.org/package/securemem implements constant-time bytestring comparisons for haskell. With the bonus that the data is scrubbed when GC'd. This is used by parts of the haskell TLS stack, for example http://hackage.haskell.org/package/cipher-aes

I don't think that laziness makes things much harder. Compare a C function with if foo return 0 in the middle and a Haskell function that lazily builds thunks that don't end up being evaluated in a particular branch. There's obvious things to do to both to make them run in constant time. The hard part about dealing with a timing attack in both cases is recognising that the function is used in such a context and needs to be constant time.

AFAIK, the haskell TLS stack has not yet been audited. For this reason, there's some reluctance to use it in parts of the Haskell community. Although http-conduit and http-client-tls do use it, so everyone writing programs that hit https from haskell using conduit is using it already.

> http://hackage.haskell.org/package/securemem implements constant-time bytestring comparisons for haskell. With the bonus that the data is scrubbed when GC'd.

As far as I understand, this is not sufficient.

Some things that are needed in addition are (at least):

* constant time math operations (multiply, divide, exponentiation, etc.)

* no branching based on secrets (running the code results in no branch conditions based on secret data)

Here's an interesting article on implementing a form of Elliptic Curve Cryptography without even local timing attacks: http://blog.cr.yp.to/20140323-ecdsa.html

Why can't timing be handled external to the scrambling or descrambling operations? Look at the time, do the crypto, then check the time and sleep as necessary so that this particular operation takes about as much time as the worse-case. Something like:

  cryptofunc x = do
    begintime <- gettime
    result <- purecryptofunc x
    endtime <- gettime
    sleep (worstcase - (endtime - begintime))
    return result

Properly implemented crypto takes a constant number of instructions to encrypt/decrypt, regardless of key, plaintext, etc.

Time to sleep() would vary across processors, os-es, and even load (!), so it's not exactly a workable solution. Not to mention it would be grossly inefficient (Context switch on every crypto primitive? No thanks).

This still would allow side channel attacks on cpu utilization. cpu utilization can be inferred, for example if the attacker has a vm on the same machine, or the attacker can make a second request which completes sooner if the cpu is less utilized.

while not a completely terrible idea, sleep doesn't give you any guarantee of when it'll wake your code up again, only that it'll be asleep for at least X time. I think this is ok, but someone with more info on these sorts of bugs would be better place to comment.

It also seems reasonable to add a random length of time to the sleep time, so that differences in computation time are indistinguisable from the randomness added by the random variable. I could be completely wrong though.

(also, you probably need to force with seq or deepseq the result of purecryptofunc before getting the second time, or you might be adding that evaluation time to another part of the code, and then this code becomes just a constant time added to the computation)

> The AES implementation uses AES-NI when available (on x86 and x86-64 architecture), but fallback gracefully to a software C implementation.

> The software implementation uses S-Boxes, which might suffer for cache timing issues. However do notes that most other known software implementations, including very popular one (openssl, gnutls) also uses similar implementation.

Oh, well if OpenSSL does it..

Downvotes for quoting from the pages linked, which are defending their use of non-constant time operations by referencing OpenSSL. Do you guys have working brains?

Reply on news.ycombinator.com