Ensure that KDF data is zeroized

[AaronFeickert]

The codebase includes several KDFs that handle secret data. Even though underlying input data (like secret keys or ECDH shared secrets) may be zeroized, it should be checked that subsequent KDF output data is also zeroized.

[jorgeantonio21]

Would love to tackle this one :)

[AaronFeickert]

For KDFs that don't already produce a zeroizing type, there are options:

• Wrap the result in a Zeroizing type to ensure it's zeroized on drop, and check for copies/moves
• Produce a custom array type for this purpose, ensure it zeroizes on drop (zeroize has a custom macro for this), and check for copies/moves

[AaronFeickert]

After discussion with @jorgeantonio21, it was suggested that one approach might be to build a generic design similar to that of SafePassword. This would wrap the key type T (either a u8 array or some other type) in a Hidden<Box<T>> wrapper that ensures the secret data stays in one place on the heap and won't accidentally be displayed or tossed into a debug log. We can then zeroize on drop via an impl Drop that zeroizes via the mutable reference accessible in Hidden (and which will work even on clones). Finally, we can ensure that access to the secret data is limited by only exposing it by reference (or mutable reference, which may be necessary if we need to generate the output in place). If a caller needs ownership, we either refactor the caller (safer from a data perspective, but likely more engineering risk) or implement an into_inner that consumes the data and returns it (which requires that we modify the caller to ensure it zeroizes its new data).

Such a generic design should ensure that different KDF output types are properly enforced by the type system, even if the underlying key types are the same. Even though the KDFs themselves (should) enforce domain separation, enforcing by type should help to keep design intent more clear.

[AaronFeickert]

Maybe the type differentiation could be done in a similar fashion to the hashing API, where a macro is used to generate a struct that's used during instantiation. So we could have a macro that generates an effectively empty struct implementing some KDFOutputType marker trait. Then, we build KDFOutput<T: Zeroize, K: KDFOutputType>, where T is the underlying key type and K is stored as PhantomData. The SafePassword-like hiding and zeroizing and reference access functionality then goes into KDFOutput.

[AaronFeickert]

Here's a work-in-progress toy example that could be useful here and for other types of data that need to be hidden and zeroized and otherwise carefully managed.

[jorgeantonio21]

I am much in favor of using the approach outlined in the comment above. It offers a nice API to deal with any KDF that has to be carefully manipulated. @AaronFeickert maybe we can make a PR out of it and further discuss it.

[AaronFeickert]

The link is to a PR now.