Skip to content

zeroize: Relax Zeroize trait bounds for Vec #276

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

Merged
merged 1 commit into from
Oct 13, 2019

Conversation

tony-iqlusion
Copy link
Member

@tony-iqlusion tony-iqlusion commented Oct 13, 2019

This changes the trait bounds for the Zeroize impl on Vec<Z> from:

Z: Clone + Default + Zeroize

to just:

Z: Zeroize

This is based on my experience trying to switch curve25519-dalek from clear_on_drop to zeroize in this PR:

dalek-cryptography/curve25519-dalek#289

Notably there were several places I was unable to use Zeroizing in conjunction with Vec because it requires Clone and Default in order for the current safe impl of zeroizing the excess capacity in
Vecs. IMO this is an implementation detail leaking out which places undue burden on the user and reduces overall utility.

This is another way of saying: this change effectively reverts #180. I think we can eventually bring this functionality back using an unsafe impl which writes zeroes to the excess capacity.

In general my opinion is if you're storing secrets in Vec, it's best to avoid mutating that Vec and causing reallocations in the first place. This is the goal of the SecretVec type in secrecy:

https://docs.rs/secrecy/latest/secrecy/type.SecretVec.html

This changes the trait bounds for the `Zeroize` impl on `Vec<Z>` from:

    Z: Clone + Default + Zeroize

to just:

    Z: Zeroize

This is based on my experience trying to switch `curve25519-dalek` from
`clear_on_drop` to `zeroize` in this PR:

dalek-cryptography/curve25519-dalek#289

Notably there were several places I was unable to use `Zeroizing` in
conjunction with `Vec` because it requires `Clone` and `Default` in
order for the current safe impl of zeroizing the excess capacity in
`Vec`s. IMO this is an implementation detail leaking out which places
undue burden on the user and reduces overall utility.

This is another way of saying: this change effectively reverts #180.
I think we can eventually bring this functionality back using an unsafe
impl which writes zeroes to the excess capacity.

In general my opinion is if you're storing secrets in `Vec`, it's best
to avoid mutating that `Vec` and causing reallocations in the first
place. This is the goal of the `SecretVec` type in `secrecy`:

https://docs.rs/secrecy/latest/secrecy/type.SecretVec.html
@tarcieri tarcieri force-pushed the zeroize/loosen-vec-bounds branch from 2152e42 to 89870e9 Compare October 13, 2019 20:25
@tony-iqlusion tony-iqlusion merged commit 9a82d85 into develop Oct 13, 2019
@tony-iqlusion tony-iqlusion deleted the zeroize/loosen-vec-bounds branch October 13, 2019 20:37
@tony-iqlusion tony-iqlusion mentioned this pull request Oct 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant