[rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts
kevin at sb.org
Fri Jan 10 12:27:31 PST 2014
Given that the crypto philosophy of the core Rust libraries is "don't put crypto in the core Rust libraries", I don't think a type like this needs to be in the core libraries. But I do think this is a good opportunity for a third-party library to create this type and promote itself as the set of building blocks for doing crypto in Rust. Furthermore, I could also imagine there being official Rust documentation that recommends this third-party library to anyone who wants to do crypto.
On Jan 10, 2014, at 11:29 AM, Tony Arcieri <bascule at gmail.com> wrote:
> Hi there Rustafarians,
> 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
> - Ensure it's zeroed out (and munlocked) after use (via RAII-style conventions?)
> - 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.
> Why is it important to have a type like this in the Rust standard library? IMO, so all the cryptographic libraries in Rust can use the same type for this purpose and in doing so interoperate easily (i.e. I should be able to get a cryptographic key read from TLS and decrypted into one of these buffers and use it with another library while still ensuring everything will get locked/zeroed)
> It would also mean that anyone using Rust would have a lot easier time writing code with good crypto hygiene, at least if all the crypto libraries used it, because this type would take care of doing all of this sort of thing for you automatically.
> Most other languages completely punt on this problem. Can Rust do better? Is this the sort of thing that belongs in the Rust standard library?
> Tony Arcieri
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4118 bytes
Desc: not available
More information about the Rust-dev