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_my...@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 <leebr...@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? > YES! 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
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
