You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is instead advised to derive ZeroizeOnDrop where Zeroize is derived, as this will make the zeroing out of memory happen automatically as the struct goes out of scope, and takes the mental burden of ensuring this is done correctly everywhere off the programmer.
Even though we agree that it would be good and probably safer as well to take the mental burden of manually zeroizing the secret-keys off the programmer, we have found that this approach does not ensure that memory is reliably erased.
Detailed Description
To test this one needs to implement the ZeroizeOnDrop derive on SecretKey and run the following test:
#[test]fnzeroize_on_drop(){let sk = SecretKey::new(JubJubScalar::from(1u64),JubJubScalar::from(2u64));let ptr_a:*constJubJubScalar = sk.a();let ptr_b:*constJubJubScalar = sk.b();// dropping the value should zeroize the underlying jubjub-scalardrop(sk);// but the memory is not erasedunsafe{assert_eq!(
core::slice::from_raw_parts(ptr_a,1)[0],JubJubScalar::from(1u64));assert_eq!(
core::slice::from_raw_parts(ptr_b,1)[0],JubJubScalar::from(2u64));};// let's try again and call zeroize explicitly before dropping:letmut sk =
SecretKey::new(JubJubScalar::from(1u64),JubJubScalar::from(2u64));let ptr_a:*constJubJubScalar = sk.a();let ptr_b:*constJubJubScalar = sk.b();
sk.zeroize();drop(sk);// now the memory is zeroedunsafe{assert_eq!(
core::slice::from_raw_parts(ptr_a,1)[0],JubJubScalar::from(0u64));assert_eq!(
core::slice::from_raw_parts(ptr_b,1)[0],JubJubScalar::from(0u64));};}
If the memory were to be erased on drop the test would not pass.
Relevant Context
We have already explored this route as part of the audit of our bls-signature scheme. See dusk-network/bls12_381-bls#6
The text was updated successfully, but these errors were encountered:
Summary
From the phoenix-audit:
Even though we agree that it would be good and probably safer as well to take the mental burden of manually zeroizing the secret-keys off the programmer, we have found that this approach does not ensure that memory is reliably erased.
Detailed Description
To test this one needs to implement the
ZeroizeOnDrop
derive onSecretKey
and run the following test:If the memory were to be erased on drop the test would not pass.
Relevant Context
We have already explored this route as part of the audit of our bls-signature scheme. See dusk-network/bls12_381-bls#6
The text was updated successfully, but these errors were encountered: