Skip to content
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

Rethink zeroization when ZeroizeOnDrop is available #89

Closed
fjarri opened this issue Jan 8, 2022 · 0 comments · Fixed by #97
Closed

Rethink zeroization when ZeroizeOnDrop is available #89

fjarri opened this issue Jan 8, 2022 · 0 comments · Fixed by #97
Labels
blocked Blocked by a third-party library enhancement New feature or request
Milestone

Comments

@fjarri
Copy link
Contributor

fjarri commented Jan 8, 2022

We may want to change SecretBox trait bounds and remove CanBeZeroizedOnDrop in favor of zeroize::ZeroizeOnDrop, which is available in zeroize since in 1.5. See RustCrypto/utils#699 and RustCrypto/utils#652.

In particular, the approximate course of action is:

  • Derive ZeroizeOnDrop for public secret types (SecretKey, Signer, SecretKeyFactory)
  • Assert the third-party types we use internally implement ZeroizeOnDrop (e.g. SigningKey). This can be asserted in compile-time.
  • We may be able to use the objects from the secrecy crate (e.g. SecretBox) instead of our custom one.
  • Also see the static_assertions crate if a static check is needed that backend types implement ZeroizeOnDrop.

Currently blocked by chacha20poly1305 (at 0.9) conflicting with zeroize 1.5.

@fjarri fjarri added enhancement New feature or request blocked Blocked by a third-party library labels Jan 8, 2022
@fjarri fjarri added this to the v1.0.0 milestone Jan 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Blocked by a third-party library enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant