On Tue, 7 Aug 2001 02:41:01 -0400
Crutcher Dunnavant <crutcher@datastacks.com> wrote:
CD> ++ 07/08/01 10:27 +0400 - John Polyakov:
>> Hello.
>>
>> On Mon, 6 Aug 2001 22:55:19 -0700 (PDT)
>> Ryan Mack <rmack@mackman.net> wrote:
>>
>> RM> Apparently some of you have missed the point. Currently, the only way
>> to
>> RM> write any form of encryption application is to have it run setuid root
>> so
>> RM> it can lock pages in RAM. Otherwise, files (or keys) that are
>> encrypted
>> RM> on disk may be left in an unencrypted state on swap, allowing for
>> RM> potential recovery by anyone with hardware access. Encrypted swap
>> makes
>> RM> locking pages unnecessary, which relieves many sysadmins from the
>> anxiety
>> RM> of having yet-another-setuid application installed on their server in
>> RM> addition to freeing up additional pages to be swapped.
>>
>> 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?
CD> Yes, you are wrong. The encryption key for the swap space can be created
CD> at boot time. We can wait for the hardware to give us enough entropy
CD> into the random number gen, and make a key. Then we mount the swap
CD> space, and all reads/writes go through that key. But the key is never
CD> recorded. The swap data is gone, even to legitimate users of the system,
CD> after a reboot.
And what program will access to timer or any other clock or any other hardware?
What programm will generate this key?
This program and key generation algorithm can not be encrypted.
Yes?
If this is true, we read this one and generate our key.
Am wrong again?
P.S. We don't look at the e-cards and other removable devices, isn't it?
CD> It is thus perfectly reasonable to wish to encrypt swap. In addition,
CD> there are good reasons to move in the direction of a non-All-Powerful
CD> root user. This is what the work in capabilities begins to approach.
CD> So simply waving your hands and saying that root can see it, so what
CD> does it matter, is not a long term solution to the problem.
CD> Crutcher <crutcher@datastacks.com>
CD> GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
CD> R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$
--- WBR. //s0mbre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/