[rust-dev] Ephemeral byte arrays for cryptographic keys/plaintexts

Tony Arcieri bascule at gmail.com
Fri Jan 10 16:23:11 PST 2014

Okay, first, I'm glad to hear that people are interested in general
solutions to the problems that I posed which are orthogonal to crypto but
could still benefit crypto applications.

On Fri, Jan 10, 2014 at 2:25 PM, Bill Myers <bill_myers at outlook.com> wrote:

> At any rate, note that what you are trying to do only provides some
> mitigation and is far from a complete solution

Hence "best crypto hygiene" not "crypto-safe memory type for Rust!"

> in practice you can't prevent leakage of all confidential data in this way

You mean attackers could potentially reach /dev/kmem? Yes, at that point,
all bets are off ;)

> what about hibernation while the key is in memory?

Seems useful actually! But clearly the way memory is being saved (encrypted
or not) is important.

> what about plaintext decrypted with the key?

I guess you're vicariously attempting to ask what the threat model is here,
and spelling out some potential compromises. I'd say what about:

1) hardware-attached DMA devices, i.e. firewire memory inspection via tools
like Inception: http://www.breaknenter.org/projects/inception/
2) Cold-boot attacks: https://en.wikipedia.org/wiki/Cold_boot_attack

We really need to back up here and get back to what I was really talking
about, which is best crypto hygiene. This isn't about building a virtual
safe with 4" thick steel walls for cryptographic applications. This is
about using the language to enforce cryptographic best practices, which do
NOT provide any guarantees about securing cryptosystems, they merely make
the attacker's job harder.

But we should back up even further yet:

On Fri, Jan 10, 2014 at 12:50 PM, Lee Braiden <leebraid at gmail.com> wrote:

> 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).

Yes, this isn't just a crypto problem. I want to solve my crypto-problems,
but if there are bigger fish to fry here, then cool ;)

Isn't this just a dtor thing?


This sounds like a general IO optimisation, which virtually any block-based
> io use-case could benefit from.

Yup! Can we solve it? ;)

Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140110/7b325e58/attachment-0001.html>

More information about the Rust-dev mailing list