PR #14 adds an opt-in zeroize feature that derives Zeroize on secret types. However, because all secret structs are Copy, ZeroizeOnDrop cannot be derived — callers must manually invoke .zeroize(). This means memory containing secret key material is not automatically cleared when values go out of scope.
The gap: SharedSecret, SecretKey, and UserSecretKey types across all schemes should ideally be !Copy so that ZeroizeOnDrop can be derived, ensuring secret material is erased automatically. This is a breaking API change and a maintainer decision, but the current state leaves secret zeroing entirely to the caller's discipline.
Related: PR #14 (feat: optional zeroize feature for secret types).
PR #14 adds an opt-in
zeroizefeature that derivesZeroizeon secret types. However, because all secret structs areCopy,ZeroizeOnDropcannot be derived — callers must manually invoke.zeroize(). This means memory containing secret key material is not automatically cleared when values go out of scope.The gap:
SharedSecret,SecretKey, andUserSecretKeytypes across all schemes should ideally be!Copyso thatZeroizeOnDropcan be derived, ensuring secret material is erased automatically. This is a breaking API change and a maintainer decision, but the current state leaves secret zeroing entirely to the caller's discipline.Related: PR #14 (feat: optional zeroize feature for secret types).