-
Notifications
You must be signed in to change notification settings - Fork 72
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
Consider zeroing and mlocking temporary values. #24
Comments
Yup, as long as your temporary value is an Adding a new type
|
The |
One remaining example is the local variable |
Our cryptographic data structures are munlocked and zeroed on drop, and mlocked on creation. In some calculations, however, we create temporary values from which secrets could be computed. Can we make sure none of this leaks, ideally without polluting the code with lots of explicit method calls for mlocking and zeroing, and without unreasonable overhead?
If I wrap a temporary value in
SecretKey
, it should be safe, right? Should we split that functionality out ofSecretKey
into a generalSecret
that mlocks and zeroes? We'd then haveSecretKey(Secret(Fr))
, but it would be less weird to useSecret
s for local variables.And we'd probably need something similar for
Vec
s.The text was updated successfully, but these errors were encountered: