Re: Encrypted Swap

[Jeffrey Considine]

> >> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> >> disk.
> >> After it I will disassemble your decrypt programm and will find a key....
> >>
> >> In any case, if anyone have crypted data, he MUST decrypt them.
> >> And for it he MUST have some key.
> >> If this is a software key, it MUST NOT be encrypted( it's obviously,
> >> becouse in other case, what will decrypt this key?) and anyone, who have
> >> PHYSICAL access to the machine, can get this key.
> >> Am I wrong?

The key can be locked into memory. Locking just the key is better than
running setuid root to lock the whole application.

> RM> I think the point you are missing is that encrypted swap only needs to be
> RM> accessible for one power cycle.  Thus the computer can generate a key at
> No, computer can not do this.
> This will do some program,and this program is not crypted.
> Yes?
> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?

Waiting for entropy (mentionned by RM I think) would take care of
this. However, I imagine it takes a while to build up enough random
bits, especially if no users are logged on and the network isn't
up. Stalling for entropy before setting up the swap partition is
probably not a good idea. Switching keys from predictable to really
random or delaying encryption sounds expensive and/or messy and would
leave a small window right after booting where the swap file could be
decrypted relatively easily.

Perhaps a cheaper alternative that wouldn't really slow down most
applications would be to add a flag set by a system call toggling
whether the page was encrypted in the swap file. That way most
applications don't see a performance difference. If the flag was
inheritable, the security paranoid could use a shell or wrapper to set
it and run everything through that.

jef