thoughtpolice/salt — Issue #10: Secret keys shouldn't get paged out.
Author: thoughtpolice
Created: 2011-10-14 15:33:37+00:00
State: open
Labels: api, big project, security

Talking with Dan Peebles, he mentioned someone else working on NaCl bindings (Michael Stone) brought up the fact that you should use something like `mlock(2)` on secret keys to ensure they're never paged to disk.

This would require changing the representation of the `SecretKey` type, although it needed consolidation anyway (it's merely aliased as ByteString everywhere.) However, it will also break any sort of compiler portability at this point I think, as the underlying runtime will need to support something like pinned arrays. In GHC, a pinned array is never moved by the garbage collector, so foreign libraries can safely use it without fear of the pointer moving. So we can safely `mlock(2)` that page afterwords.

However, there are other concerns afoot in that if you were to call, say, `readFile :: FilePath -> IO SecretKey` on a secret key, it could potentially make a copy of that key somewhere in memory before returning a pinned, locked array. And *that* page could get paged out.

There may need to be GHC support for this ticket to really be sound/doable without mass FFI bindings.