[Cryptography] RFC possible changes for Linux random device

[Jerry Leichter]

On Sep 17, 2014, at 6:16 PM, Viktor Dukhovni <cryptography at dukhovni.org> wrote:
>> We're talking much bigger changes here, but if we're going to think big:
>> Encrypted swap space, with *per process* encryption keys, would be almost
>> as effective, without the potential for such a denial of service attack.
>> The per-process swap key would go into this kind of "crypto-secure" memory,
>> but that would be a strictly limited bit of memory.
> 
> Why should the key be per-process, and not system-wide?
Just on general isolation principles.  There is never a need for one process to be able to read another process's swap space, so why should it even have the capability?

In fact, if you think of it in "capability" terms, using encryption to enforce the capabilities, it's a natural.  "Per-process" is not a good characterization, however; rather, it should be per memory region.  That way it's easy to have some shared memory with no key, or shared memory with a key you need to make any sense of it - or even have encrypted disk-mapped I/O.

>  Instead
> each process could simply have a non-secret key identifier, allowing
> periodic key rotation.
Key rotation solves an entirely different problem.  And, in the context of encrypting swap space, I'm not even sure *what* problem it solves!

>  At which point, is this really much better
> than existing encrypted swap devices?
Existing encrypted swap devices attempt to prevent one attack:  Seizure of a swap device leaking information about what was in memory in the running processes.  They're fine for that.  Key rotation is essentially irrelevant for that attack.  It becomes relevant if you think about attacks that leak the encrypted swap contents, and maybe the keys, over a period of time.  But then making it harder for a process to determine some other process's swap encryption key might be of interest as well.

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140918/cd2aa3e9/attachment.bin>