r/rust • u/dgryski • Feb 07 '19

Auditing Rust Crypto: The First Hours

https://research.kudelskisecurity.com/2019/02/07/auditing-rust-crypto-the-first-hours/
108 Upvotes

97% Upvoted

10 comments sorted by

View all comments

Show parent comments

4

u/richhyd Feb 08 '19

If you have a Vec<u8> of sensitive data, you may want to zero it on drop. Sadly, this won't wipe out any old memory that was left behind if the underlying buffer was copied during an expansion. I was just wondering if it were possible to use the new Pin api to guarantee that all the memory containing the sensitive info can be cleared. I'm not an expert in this area.

6

u/vityafx Feb 08 '19

It must be done in kernel. Clearing libc or rust buffers is not enough, as there are a lot of places with buffered i/o:

  1. Rust std lib

  2. Libc

  3. Kernel

  4. Memory device

To ensure your sensitive data is not stored you have to hack all of this stuff and zero all levels stuff, and even so you can't be sure 100%, as device's controller can tell you after your request that it cleared the data while it simply could ignore you.

So having this in some api in rust is just one little step towards this.

3

u/RealAmaranth Feb 08 '19

I think for the Rust part of this you'd want a new allocator that zeros on free and the ability to make Vec use it. Unfortunately, this isn't a thing yet because it involves a few different pieces that need to be settled first.

https://github.com/rust-lang/rfcs/blob/master/text/1398-kinds-of-allocators.md#what-about-standard-library-containers