-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zero keys/secrets upon Drop #63
Comments
seems like clear_on_drop is the popular choice: I have not yet tried the "clear_stack_on_return" in my own project and so far have only used this crate to clean secrets on the heap: #[derive(Clone, Debug, PartialEq)] Whereas clear stack on return seems straight forward: https://docs.rs/clear_on_drop/0.2.3/clear_on_drop/fn.clear_stack_on_return.html |
It sounds like |
This zeroes out the master "Key" struct (used to derive all phase keys), as well as the derived phase keys. We might also consider making the plaintext return values of Receive be Zeroized<Vec<u8>>, since we allocate them, but I don't know how much that might impact callers. We should also make sure that upstream SPAKE2 zeroes its internal secrets. refs #63
Ok, that zeroes out the main Should we change the |
What I think what we want, however, is our key type to be as opaque as possible and only implement |
As far as I can tell, we are blocked on RustCrypto/AEADs#65 ? |
While this would be good to have, I don't think this is going to happen any time soon. |
I've seen curve25519-dalek use some tools/libraries to zero out the memory of sensitive data structures (keys, intermediate values used to derive keys) just before they get dropped. We should do something similar. A lot of our temporaries are on the stack, so we should zero those too.
Basically, if the application above us is careful with their own memory, then our library should not introduce any additional exposure of secrets.
I think @david415 had some ideas on this one.
The text was updated successfully, but these errors were encountered: