powersoftau icon indicating copy to clipboard operation
powersoftau copied to clipboard

Memory isn't zeroed

Open kpcyrd opened this issue 8 years ago • 2 comments

I'm having trouble locating the code that zeroes memory containing the seed that is is computed in src/bin/compute.rs.

As far as I can tell the following bytes need to be zeroed so the value isn't leaked after the program terminates:

  • the private key
  • bytes gathered from OsRng (r)
  • the text entered by the user (user_input)
  • the hash computed from the previous two (h)
  • the buffer seed that holds a copy of h (digest is only a pointer as far as I can tell)
  • rng, the ChaChaRng that is created from that seed
  • possibly some temporary variables in keypair(...) and Accumulator::transform(...)

kpcyrd avatar Nov 12 '17 23:11 kpcyrd

I can only recommend destroying the machine afterward, which is something most of us need to do anyway in anticipation of backdoors.

As is stated on the powersoftau README:

In general, participations should beware of side-channel attacks and assume that remnants of the randomness will be in RAM after the computation has finished.

The computations involved are very expensive, and there are many more places where secrets (or data derived from secrets) are stored in memory for efficiency purposes. As an example, there's a massive heap object containing coefficients computed in parallel, and some heap locations are used for storing different representations of the secrets.

I'm generally a fan of defense-in-depth, but there are many ways we can screw up when secrets end up on the heap (like vector reallocation, maybe jemalloc bugs), and it's even harder to keep track of everything when multithreading is involved. We'd also have to account for disk swapping which is very likely considering how much memory is consumed by the process. And the user is probably leaking the entropy they're providing over stdin somewhere else on the machine too.

All of this can be done obviously, though it's not really easy to do in safe Rust code due to compiler optimizations. I think we'd pay too much in code complexity and the cost of auditing, and we'd probably miss something anyway. I don't want to give people false assurances, so I just recommend destroying the machine.

ebfull avatar Nov 13 '17 23:11 ebfull

For people who aren't able or willing to destroy a machine, it is probably still worth disabling swap before running the compute process and switching off the machine immediately afterward.

To disable swap, run swapoff -a as root and then cat /proc/swaps to check that no swap devices are active.

daira avatar Nov 13 '17 23:11 daira