Zero memory on drop

[fxha]

I have a question about the hash memory management but also for other related repositories. As it seems RustCrypto use GenericArray and/or raw arrays for sensitive data like keys and internal buffers but the memory is not overwritten/zeroed on reset or when the buffer/struct is dropped for most crates, right? Are there any plans to change this?

[newpavlov]

Yes, you are right, currently most crates do not zeroize inner state on drop. IIUC to implement it without hacks we will need either generic-array support (e.g. by implementing Zeroize trait.) or const generics.

[tarcieri]

@newpavlov you can do a Zeroize impl without explicit support for generic-array by borrowing the contents of the latter as a byte slice and calling zeroize() on that. IterMut will also work.

[newpavlov]

@tarcieri Maybe we can transform the whole hash state into byte slice (using unsafe code) and call zeroize on it?

[tarcieri]

@newpavlov or you can just call zeroize on each value in its state in a Drop handler. zeroize is designed to support structured data. If they're GenericArray you just need to call as_ref() (or as_slice()?) first iirc

When const generics land it should be possible to derive a Zeroize impl and drop handler using zeroize_derive (the same thing would be possible with first-class generic-array support for zeroize, but that doesn't exist).

[tarcieri]

@fxha is there a particular hash function or set of them you'd specifically like to have this in?

We can add optional zeroize features to high-priority crates.

[fxha]

I think it's good practice to (optionally) erase secret data and don't leak keys in memory.

[tarcieri]

I agree (in fact I wrote the most popular crate for it).

However hash functions are a bit of an odd fish in this regard. Ones based on the Merkle–Damgård construction (which constitute a large number of the ones in this repo, including the popular sha2) effectively output their internal state upon finalization (which is what enables length extension attacks). If that internal state were reversible to a secret, that would be a preimage attack against the underlying hash function.

I think the hash functions where this would be relevant are, as you pointed out, ones with keys, i.e. ones which provide PRFs.

As far as I know the only one in this particular repo that applies to is blake2.

[burdges]

Zeroize cannot prevent the type from being used after zeroing. Internal states often include constants, so zeroizing can leave an internal state that functions but provides less security.

[fxha]

@tarcieri I don't quite remember, but I was using Blake2 and noticed that my key was copied or something like this. Cleaning the internal state isn't a high priority but basic cleanup should be provided.

[newpavlov]

I wonder if we should make the reset capability optional... It would allow us to remove the caching of initial state and thus secret key inside hasher state will be overwritten as soon as first block of data has been processed. How often in your opinion users need to reset MAC states?

[koraa]

How about adding the Zeroize trait for blake2 at least? I am trying to implement a noise-like protocol where hmac-blake2 is used as a KDF. Right now I am using libsodium including sodium_malloc/free to make sure ephemeral secrecy is guaranteed.

The lack of well thought-through zeroization in RustCrypto is a major blocker for moving away from sodium.

[tarcieri]

I think an optional zeroize feature which adds a Drop impl that zeroizes the relevant state is probably the best approach, along with a ZeroizeOnDrop impl.

The problem with Zeroize is it might leave the hasher in an invalid state without consuming it.