Using zeroize-on-drop in mc-transaction-core

[cbeck88]

Historically, most objects in transaction-core did not implement Zeroize.
This is because curve25519-dalek::RistrettoPoint did not implement Zeroize and so it was impossible.

Now, it does implement Zeroize, but not drop(Zeroize). This means, we know how to zeroize it, but it is not automatically zeroized on drop. Many (maybe not all?) sensitive types in TransactionCore also derive Zeroize now.

Generally, we want "secrets" to be zeroized on drop. This represents an implementation hardening step that can protect against information leaks, by reducing the window for an adversary who has hacked into your device from obtaining secrets that are resident in memory.

However, in a typical transaction almost everything is a secret in our model. Not only are your private keys a secret, but also who you are sending money to is a secret.

• tx_private_key should be zeroized on drop
• tx_out_shared_secret should be zeroized on drop
• Your friend's public address should be zeroized on drop
• Which inputs you selected to spend, and which ring input is the real input, should be zeroized on drop.
• Pseudo-output blinding factors should be zeroized on drop, because they can be used to unblind amounts in a transaction.
• Possibly the whole Tx should be zeroized, but this might be overkill.

Zeroizing on drop has additional consequences.

• Drop types cannot be Copy. Some types like CompressedRistrettoPublic are Copy.
• This can interfere with some optimizations (although it is probably minor).
• I am not sure how it interacts with Prost.

This issue tracks discussion and implementation around:

• What types if any should be Zeroized on Drop?

An alternative approach is:

• Types are not usually marked zeroize-on-drop, instead, variables are Zeroizing wrappers around types that implement Zeroize. This has other tradeoffs compared to using Zeroize on drop.

One basic step we can take is, try making Tx object Zeroize on drop and test if this has performance implications for the consensus network. IIRC a large part of the consensus enclave has to do with deserializing these objects, calling validate by passing a reference, and then possibly re-encrypting it and passing it to peer enclaves, and there is not much reason to make copies of parts of the Tx for other purposes, so this change may clean up a large number of secrets on its own. Then we can follow up by seeing what copies of secrets if any are made during Tx validation and ensure that we clean up those also.

---

• Zeroize Tx on drop Make the Tx object zeroize itself on drop #2925
• Zeroize tx_private_key on drop
• Zeroize tx_out_shared_secret on drop
• Zeroize transaction builder arguments, such as public address (and amounts?) of an output
• Zeroize inputs, true ring input, on drop
• Zeroize pseudo-output blinding factors on drop