Sensitive data is not explicitly zeroed after use despite existing zeroization helpers

[clr34m3r]

While reviewing mpcium’s codebase, I noticed that sensitive cryptographic material does not appear to be explicitly wiped from memory after use, even though the repository already includes utilities designed specifically for secure zeroization. This suggests that key shares and other secrets may be left to Go’s garbage collector, which is non-deterministic and not designed for security-sensitive memory handling.

The codebase already provides explicit helpers in memory.go:

• security.ZeroBytes([]byte)
  • Overwrites the byte slice
  • Calls runtime.GC()
• security.ZeroString(*string)
  • Clears the string reference
  • Runs GC twice
• SecureBytes
  • Wrapper that zeroes its internal byte slice when released

These utilities indicate that the project is aware of the need for memory zeroization and has already implemented primitives to support it. However, during review of the signing and resharing flows, I do not see these helpers being invoked after sensitive data is used. Based on what I can see, this implies:

• Key shares and intermediate secrets remain in memory
• Cleanup is deferred entirely to Go’s garbage collector
• There is no deterministic guarantee that sensitive buffers are wiped promptly (or at all)

Ideally, mpcium should:

• Explicitly zero sensitive buffers immediately after use
• Invoke security.ZeroBytes, SecureBytes.Release(), or equivalent
• Ensure resharing / signing sessions have clear lifecycle boundaries for cleanup
• Treat GC as a fallback, not a security mechanism

Is the absence of explicit zeroization in signing / resharing flows intentional? Or there are code paths that already wipe sensitive data that I may have missed?

[anhthii]

hi @clr34m3r thanks for creating the issue. My apologies, I missed the notification for your issues. We will check and give feedback asap

[anhthii]

hi @clr34m3r good catch on this one, will be better if we use the implemented utitlity

  Specific Missing Zeroizations (Line-by-Line)

  | File                       | Line(s)       | Variable                  | Sensitivity            | Action Needed                                             |
  |----------------------------|---------------|---------------------------|------------------------|-----------------------------------------------------------|
  | ecdsa_signing_session.go   | 120           | keyData                   | HIGH (marshaled share) | defer security.ZeroBytes(keyData)                         |
  | ecdsa_signing_session.go   | 125-132       | data, s.data              | CRITICAL (key share)   | Zero all fields before Close()                            |
  | eddsa_signing_session.go   | 111           | keyData                   | HIGH                   | defer security.ZeroBytes(keyData)                         |
  | eddsa_signing_session.go   | 116-123       | data, s.data              | CRITICAL               | Zero before Close()                                       |
  | ecdsa_keygen_session.go    | 100-101       | saveData, keyBytes        | CRITICAL               | defer security.ZeroBytes(keyBytes) + zero saveData fields |
  | eddsa_keygen_session.go    | ~88-95        | saveData, keyBytes        | CRITICAL               | Same as ECDSA keygen                                      |
  | ecdsa_resharing_session.go | 141, 171, 175 | share, saveData, keyBytes | CRITICAL               | Zero old share + new share + marshaled bytes              |
  | eddsa_resharing_session.go | 131, 158, 160 | share, saveData, keyBytes | CRITICAL               | Same as ECDSA resharing                                   |

Some place we can improve, we welcome for contribution on this issue. Thanks!