Optionally support Zeroize with the right disclaimers

[AtropineTears]

Hello,

I have compiled a list of reasons on why Zeroize Support would be good for this library. This is a continuation of #28 and #29

Reasons

1. Zeroize Support is supported in top cryptography libraries like a multitude of Dalek's libraries.
2. Zeroize Support is easy to implement using the Zeroize Derive Trait.
3. Adding Zeroize Support would make this library stand out better.
4. Zeroize Support will help others with using your library in a secure manner.
5. Zeroize is a secure dependency that is well maintained.
6. You can always add Zeroize as an optional dependency.
7. It would add a simple .zeroize() method and ability to clear memory on drop

Personal Reasons

My personal reason is that I am developing two cryptography libraries that require Zeroize support. I would really appreciate it if Zeroize was implemented.

[thomwiggers]

Honestly, I'm not too convinced by the reasons you give. Please forgive me for being a bit blunt here, but I want to make clear that the security gains here can be subtle and don't necessary transfer in the same ways you expect:

1. Zeroize Support is supported in top cryptography libraries like a multitude of Dalek's libraries.

Dalek implements everything in Rust and might have more control over what they're doing with the variables, secret keys and stack than we do. PQ also has special challenges here, as discussed previously, due to the XXL stack usage. "$other_library does it" doesn't really transfer.

4. Zeroize Support will help others with using your library in a secure manner.

Does it? If you care about leaking memory values then the stack space used outside of anything Zeroize can cover should be a major concern, and there's not much we can do about this at this point. Indeed, Zeroize might give a false sense of security.

2. Zeroize Support is easy to implement using the Zeroize Derive Trait.
3. Adding Zeroize Support would make this library stand out better.
4. Zeroize is a secure dependency that is well maintained.
5. You can always add Zeroize as an optional dependency.
6. It would add a simple .zeroize() method and ability to clear memory on drop

These are not security arguments, but rather arguments about marketing and why it won't be a big maintenance burden. I'm not worried about that.

However, I guess there's a somewhat higher probability that the secret key structs will be heap-allocated, in which case Zeroize might be more helpful than not doing anything. I would merge a PR (you want to be changing pqcrypto-template) that adds it optionally, and it should be accompanied by a relevant piece of text in the READMEs about what Zeroise does and does not supply.

[thomwiggers]

I am developing two cryptography libraries that require Zeroize support.

Off-topic advice; I would take a careful look at what Zeroize does and does not protect in your particular usecase and what promises you make about that. Managing memory is hard :)

[AtropineTears]

Thank you for the thorough response. I will look into learning more about Zeroize and other related information before proceeding. Much appreciated.

[niluxv]

The main thing to worry about is probably secret memory being swapped out (to potentially unencrypted swap). The only proper solution is that the user configures ephemerally encrypted swap. (Although it is probably more likely for the heap to get swapped out, the stack could be swapped too, and as pointed out zeroizing the stack is not really possible.)

In any case, @AtropineTears, if you allocate secrets on the heap it might make sense to use a special "secure" allocator, like the one in libsodium. Such allocators do not only zeroize on deallocation, but will also ask the operating system nicely whether it could consider to not swap the memory out. (I have written something similar in rust but that is too much WIP to recommend.)

And note that even without support from this library you could just create a newtype wrapper around a secret key and implement zeroize on drop for that.