Skip to content

Small zeroization fix#366

Open
emil-wire wants to merge 1 commit into
RustCrypto:masterfrom
emil-wire:fix/x-wing-expand-key-zeroize
Open

Small zeroization fix#366
emil-wire wants to merge 1 commit into
RustCrypto:masterfrom
emil-wire:fix/x-wing-expand-key-zeroize

Conversation

@emil-wire

Copy link
Copy Markdown

Just noticed that fn expand_keyin x-wing doesn't fully zeroize seed and sk_x_raw so I added explicit zeroization as a defense in depth measure.

@newpavlov

newpavlov commented Jul 21, 2026

Copy link
Copy Markdown
Member

Personally, I don't think we should explicitly zeroize temporary variables stored on stack since there is plenty of ways to spill sensitive data to stack and zeroize-on-drop does not help with moves (especially considering inefficient zeroization codegen for byte arrays, see: RustCrypto/utils#1504). Instead users should zeroize stack after sensitive computation is completed.

@emil-wire

Copy link
Copy Markdown
Author

That makes sense. I'd be happy to close this PR if that's your stated policy. I just noticed other crates in this workspace already explicitly zeroize transient stack buffers after use, for example hqc-kem and dhkem, so this just follows that existing pattern.

Rezeroize_stack: it seems broader but also harder to apply idiomatically inside this crate - it requires estimating stack usage, using an #[inline(never)] wrapper, and is still documented as best-effort/codegen-dependent. I’m not sure expand_key is the right place to introduce an arbitrary stack scrub size.

@newpavlov

Copy link
Copy Markdown
Member

I will leave this decision to @tarcieri.

I’m not sure expand_key is the right place to introduce an arbitrary stack scrub size.

Yes, this is why I wrote that stack zeroization should be done by users.

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.

2 participants