On 10/01/14 19:29, Tony Arcieri wrote:
There's a particular type I'd love to see in core Rust: a bytebuffer
for crypto purposes which automatically provides what I'd call "good
crypto hygiene". It'd do the following things:
- Avoid being paged out to swap by use of mlock/VirtualLock
This is a general memory setting, which is required for all sorts of
use-cases: disk io buffers, device driver buffers, off-screen rendering,
caching, important interactive elements (mouse pointers and application
menus, for instance), which would hamper the user experience if they
were paged in/out, etc. I'd go as far as to say that any system with
swapping needs an easy way to lock memory like this. It's not even
really a crypto problem, since swap can (and probably should be)
encrypted too, if you encrypt your filesystem(s).
I would like to see a platform-independent implementation in std::mem --
std::mem::lock(buf, len) and it's unlock() opposite, perhaps.
- Ensure it's zeroed out (and munlocked) after use (via RAII-style
conventions?)
Isn't this just a dtor thing?
- Be able to interact directly with the I/O layer so it's easy to get
data in/out of these buffers without having to thunk it through a
bunch of intermediate types that won't have these properties, i.e. it
should be possible for me to read an encryption key from a file
without going through a [u8] that wouldn't get locked/zeroed
automatically.
This sounds like a general IO optimisation, which virtually any
block-based io use-case could benefit from.
--
Lee
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
