[Cryptography] RFC possible changes for Linux random device

Jerry Leichter leichter at lrw.com
Fri Sep 19 11:40:58 EDT 2014


On Sep 18, 2014, at 10:27 AM, Jonathan Thornburg <jthorn at astro.indiana.edu> wrote:
>> 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.
> 
> It's perhaps worth noting that OpenBSD has had this (and turned it on
> by default) since around 2000.  In fact, the OpenBSD implementation uses
> per-page encryption keys.  See
>  http://www.openbsd.org/papers/swapencrypt.pdf
>  http://www.openbsd.org/papers/swapencrypt-slides.pdf
> for the paper & slides presented at Usenix Security 2000.
Nice paper.  Tt's interesting to see how the technological concerns have changed over the intervening decade and a half.  In particular, no one today would need find it of interest to show that the overhead of encrypting pages before writing them to disk isn't a big deal.

However, they attacked a different problem:  Ensuring that data no longer referenced by any process will also be (logically) wiped from swap within a known time T.  They divide the backing store into sections (nominally of 512KB each) and assign a key to each section.  Once a key has been in use for T seconds, a new key is chosen and any pages in that section that are still in use are re-encrypted.  Any that are no longer in use still contain their old data, but can no longer be decrypted as the old key is gone.  (The paper, however, notes that they hadn't yet implemented re-encryption. So the implementation they based the paper on didn't actually solve the problem they set out to solve!  Do you know whether they ever finished the implementation and added it to the standard distributions?)

The keys, BTW, are stored in volatile kernel memory and are never written to the swap device.
                                                        -- 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/20140919/ac8cf07a/attachment.bin>


More information about the cryptography mailing list