[lkml]   [2004]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mlock(1) wrote:
> On Sat, 25 Sep 2004 04:58:48 +0200, Andrea Arcangeli said:
>>I don't even think "save their key securely" (I mean saving anything
>>related to the swapsuspend encryption key on disk) is needed. A mixture
>>of a on-disk key + passphrase would not be more secure than a simple
>>"passphrase" alone, because the on-disk key would be in cleartext and
>>readable from the attacker. the only usable key is the one in the user memory,
>>it cannot be saved in the computer anywhere. Peraphs for additional
>>security (and to avoid having to type and remember it) one could use an
>>usb pen to store and fetch the key... but then I leave the fun to the
>>usb folks since to do that usb should kick off before resume overwrites
>>the kernel image ;)
> Well, obviously saving the actual key on the disk is a losing idea, but saving
> "key hashed by passphrase" would work (similar to how PGP or SSH don't save the
> actual key, but rather the key hashed by something).
> I suspect that having the *entire* key be the passphrase remembered by the user
> is also a non-starter security-wise (unless we do something like Jari Ruusu's
> loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to
> be all too many blocks in the swsusp area that are "known plaintext" and easily
> brute-forceable for most passphrases that users are likely to actually use.
> So in order to make it at all secure, we really need to save on the disk
> a key with O(128 bits) of entropy, perturbed by enough bits that are *not*
> to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
> Do any of the crypto experts lurking have ideas/opinions on just how many
> bits we need to store externally (be it in a USB dongle, a thumbprint, a
> passphrase, whatever)?

Not really a crypto expert, but... use a random session key, at least
128 bits. Encrypt _that_ with the passphrase or whatever, eliminating
any known plaintext. Since this decryption is only done once at bootup,
we don't care how slow it may be, so use an iterated scheme (like
Blowfish crypt). That way the user could dial it to take 500ms or so on
the local machine to try a passphrase, making weak passphrases a lot
harder to bruteforce. Or the kernel should iteratively encrypt it at
suspend for some fixed time, then store the iteration count.

So long as suspend/resume is supported, there's a risk that someone
captures a suspended system and steals a disk image. Later they force
the owner to reveal the passphrase. Now they can see not only the
useful contents of memory but any old stuff that's been sitting in swap
since the last reboot (like PGP keys). This could be avoided by making
the system somewhat forward-secret: generate a random key per vma and
zero it out of RAM when the vma goes away (assuming the vma is the right
unit for it). If the IVs are chosen based on position in the swap
device then there should be very little overhead.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:06    [W:0.080 / U:1.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site