Open jac-cbi opened 1 week ago
@jac-cbi Hello,
sorry forgot to enable the issues. Now it is enabled.
I should also mention I just completed reading through RustCrypto #1046 regarding redoing the interface for zeroize
. Regardless of the outcome, it seems stalled, there's a lot of great insight in there about the intended uses of Zeroize
and friends.
Based on this discussion, it would seem than zeroize
/ ZeroizeOnDrop
should only be implemented on sensitive flat types. Would it make sense to have a newtype_zbuffer!()
for PrivateKey
and SharedSecret
which implements Drop
and zeroizes?
All,
I'm in the early stages of writing my project, which is in Rust, and relies on ML-KEM / Kyber (both, one for FIPS world, the other for non-fips).
safe-oqs
QI originally incorporated a fork of liboqs-rust, safe-oqs because it had updated the submodule of liboqs to include the recently released ML-KEM. However, I now have a few questions, and @Scarjit and @joernheinemann don't have issues open on their fork...
@thomwiggers should liboqs-rust just pull in the relevant changes from safe-oqs? I looked at the diff between main branches, there's not much there. Just updated liboqs commit and exposing ML-KEM / ML-SIG. The rest is mostly renaming their crate
Real Q re
Zeroize
Outside of that, my real question is this: Does liboqs-rust zeroize sensitive buffers on Drop? I see
OQS_MEM_secure_free()
, and a build check to ensure it's used overfree()
, but I don't see theDrop
trait implemented on the Rust side in the macros.Drop
only appears to be implemented forKem
andSig
, which, afaict, are just handles. Additionally, thatDrop
implementation is callingOQS_KEM_free()
, which does not securely zero the memory.Would it make sense to just
#[derive(Zeroize, ZeroizeOnDrop)]
from thezeroize
crate?