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
Implement Zeroize #553
Comments
Moving to rust-secp. I'm surprised that no such issue already exists. The TL;DR is that these zeroing crates (there are a couple, IIRC the other popular one is called
Having said this, I would like to support this somehow, even if the library doesn't have first-class support for it. I don't know either whether this is feasible. |
I believe this is a lost cause. The compiler may copy secret bytes to unexpected locations as a result of optimizations and there's no way to prevent that. Also the only thing this protects against is leakage due to UB. Rust has much less UB than C, so the value is questionable and the significant effort required to actually make this possible would be better spent at preventing (the remaining) UB in the first place. |
@sanket1729 but the immediately following section says that copies and moves undermine the crate and that you need to use |
@apoelstra thanks for pointing that out. I am with @Kixunil now, this is a very hard problem to solve and our resources are better invested elsewhere. |
subtle is about being constant time, not about zeroing memory. zeroize is about traits to zeroize memory. Accordingly, I don't believe this is fruitless regarding functionality. I also don't believe implementing Not to say that magically gives you time or makes it a priority. I just wanted to to highlight the benefits/impacts over it. |
@kayabaNerve thanks for explaining, that sounds at least doable (even though I still find value questionable). |
Yeah, memory access will always be a question of "If someone already has that much access, isn't it moot?" My preference is to minimize copies, and do what I can, even if sure, the second I perform multiplication, the underlying lib probably makes a few copies (hopefully on the stack, at least). The stack ones will hopefully get cleared out soon, and I can know my long lived ones aren't just available for the next program which calls |
They already aren't. The kernel zeroizes allocated pages. It'd be a huge vulnerability if it didn't. |
Some systems do not offer that behavior, per malloc's memory being undefined (justifying calloc), nor do I believe Linux is complete in that behavior. Beyond apparently being configurable when compiling the kernel, both Linux and Windows seem to only zero pages before handing off to a distinct process. While I did say, "next program" (which may still be feasible on some embedded systems), there are other concerns where a process both manages a secret key and exposes some level of memory buffer access to users (though Rust thankfully prevents most of these). |
That's something completely different. The process gets zeroed memory from the kernel but it doesn't zero it's own which means that if you allocate, write something and then deallocate the next allocation may obtain the pointer containing what you just wrote (or may not).
Rust protecting against this is exactly my point. It's no longer that big issue (as an interesting data point, according to a recent report, Google found no vulnerabilities in their Rust code so far). If we focus our time on getting |
I don't know how feasible it is, but as there are a lot of secrets here, it would make sense.
The text was updated successfully, but these errors were encountered: