Encrypted ram disk?

[Karol Babioch]

Hi,

after setting up a full system encryption, which works just fine
basically, I know want to create a ram disk.

I though that /tmp could be outsourced to a ram disk, to speed things
up.

However I'm wondering whether it really makes sense to encrypt this. If
there is someone able to read my ram, there is nothing I can do about
it, so encryption wouldn't work, would it? Furthermore the content of
the RAM gets encrypted when suspending, as my swap partition is
encrypted. Moreover I think that it would slow down the ram disk, and
that the benefit wouldn't be that great at all.

So what do you think, is there any rational reason to encrypt a ram
disk, or is it fair enough, when I just create an unencrypted one
for /tmp?

Is there anything I can read about this topic?

--
Best regards,
Karol Babioch <karol@...>

[Tamir Daniely]

On Tue, Oct 27, 2009 at 10:34 PM, Karol Babioch <karol@...> wrote:

> Hi,
>
> after setting up a full system encryption, which works just fine
> basically, I know want to create a ram disk.
>
> I though that /tmp could be outsourced to a ram disk, to speed things
> up.
>
> However I'm wondering whether it really makes sense to encrypt this. If
> there is someone able to read my ram, there is nothing I can do about
> it, so encryption wouldn't work, would it? Furthermore the content of
> the RAM gets encrypted when suspending, as my swap partition is
> encrypted. Moreover I think that it would slow down the ram disk, and
> that the benefit wouldn't be that great at all.
>
> So what do you think, is there any rational reason to encrypt a ram
> disk, or is it fair enough, when I just create an unencrypted one
> for /tmp?
>
> Is there anything I can read about this topic?
>
> --
> Best regards,
> Karol Babioch <karol@...>
>

Hi,

>From a technical prospective, reading ram post system shutdown or crash is
definitely possible, the data is preserved for several minutes depending on
the ram technology, and the time the data can be accessed can be increased
significantly by cooling or freezing the ram itself.

I might be wrong and this is generally speaking because I'm not a linux
expert, but in my opinion a standard home pc wouldn't manage the processing
requirements for encrypting a file system on the ram in real-time (At least
not for any reasonable encyrptions) without major slowdowns. There are
though hardware encryption solutions that could handle the workload of
encrypting the ram in real time. You can look up information on
cryptographic hardware if it interests you.

I don't think this is realistic or necessery for home systems, I personally
am not afraid of someone stealing my ram to get to my facebook password. And
of course there are a lot easier ways to get the information.

Shauros

[solsTiCe d'Hiver-2]

http://xkcd.com/538/

[Ciprian Dorin, Craciun]

On Tue, Oct 27, 2009 at 11:46 PM, Tamir Daniely <tamirdaniely@...> wrote:

> On Tue, Oct 27, 2009 at 10:34 PM, Karol Babioch <karol@...> wrote:
>
>> Hi,
>>
>> after setting up a full system encryption, which works just fine
>> basically, I know want to create a ram disk.
>>
>> I though that /tmp could be outsourced to a ram disk, to speed things
>> up.
>>
>> However I'm wondering whether it really makes sense to encrypt this. If
>> there is someone able to read my ram, there is nothing I can do about
>> it, so encryption wouldn't work, would it? Furthermore the content of
>> the RAM gets encrypted when suspending, as my swap partition is
>> encrypted. Moreover I think that it would slow down the ram disk, and
>> that the benefit wouldn't be that great at all.
>>
>> So what do you think, is there any rational reason to encrypt a ram
>> disk, or is it fair enough, when I just create an unencrypted one
>> for /tmp?
>>
>> Is there anything I can read about this topic?
>>
>> --
>> Best regards,
>> Karol Babioch <karol@...>
>>
>
> Hi,
>
> >From a technical prospective, reading ram post system shutdown or crash is
> definitely possible, the data is preserved for several minutes depending on
> the ram technology, and the time the data can be accessed can be increased
> significantly by cooling or freezing the ram itself.
>
> I might be wrong and this is generally speaking because I'm not a linux
> expert, but in my opinion a standard home pc wouldn't manage the processing
> requirements for encrypting a file system on the ram in real-time (At least
> not for any reasonable encyrptions) without major slowdowns. There are
> though hardware encryption solutions that could handle the workload of
> encrypting the ram in real time. You can look up information on
> cryptographic hardware if it interests you.
>
> I don't think this is realistic or necessery for home systems, I personally
> am not afraid of someone stealing my ram to get to my facebook password. And
> of course there are a lot easier ways to get the information.
>
> Shauros

    Hello all!

    As pointed, the encryption of a RAM disk would be useless, because
the data would in the end reach in the RAM, but in another portion.

    Also instead of using a RAM disk (like the one for init-rd) I
would advise you to use tmpfs, which was created specifically for this
purpose. (It has lower overhead, and it ocupies only as you use it.)
But in this case (as in the case of a RAM disk), encryption of swap is
mandatory.

    Just out of curiosity: what solution did you use for full system
encryption? And if this thread was started, what solutions do other
ArchLinux users recommend?

    Ciprian.

[darose]

On 10/28/2009 12:11 PM, solsTiCe d'Hiver wrote:
> http://xkcd.com/538/

lol!

DR

[Alexander Lam]

Besides, even with traditional filesystem encryption, the encryption key
stays in RAM.

[Thomas Bächler-2]

Ciprian Dorin, Craciun schrieb:
>     Just out of curiosity: what solution did you use for full system
> encryption? And if this thread was started, what solutions do other
> ArchLinux users recommend?
>
>     Ciprian.

I guess that would be it:
http://mailman.archlinux.org/pipermail/arch-general/2009-October/008409.html

[Thomas Bächler-2]

Tamir Daniely schrieb:
>> >From a technical prospective, reading ram post system shutdown or crash is
> definitely possible, the data is preserved for several minutes depending on
> the ram technology, and the time the data can be accessed can be increased
> significantly by cooling or freezing the ram itself.

Yes, this is a problem. It is possible to wipe the encryption key from
memory when hibernation has finished or generally before poweroff, but I
have no idea if this is done in Linux.

What poses a bigger problem is suspending: Your RAM stays powered all
the time and contains your encryption key. cryptsetup has (in its latest
release candidate) gained a feature where you can "suspend" a volume by
killing the encryption key and later "resume" it by reentering the
passphrase. I think it should even be possible to combine this with full
system encryption, using a chroot with static cryptsetup and a minimal
static shell, which would reside either in a tmpfs or on an unencrypted
disk.

[Karol Babioch]

On Mi, 2009-10-28 at 18:50 +0100, Thomas Bächler wrote:
> ryptsetup has (in its latest
> release candidate) gained a feature where you can "suspend" a volume
> by
> killing the encryption key and later "resume" it by reentering the
> passphrase.

Have you more information about this? Would be great to have this
working. I know its a little bit paranoiac, but my intention is
curiosity whether I can get it working, not the little amount of special
security I get ;).

--
Best regards,
Karol Babioch <karol@...>

[Thomas Bächler-2]

Karol Babioch schrieb:

> On Mi, 2009-10-28 at 18:50 +0100, Thomas Bächler wrote:
>> ryptsetup has (in its latest
>> release candidate) gained a feature where you can "suspend" a volume
>> by
>> killing the encryption key and later "resume" it by reentering the
>> passphrase.
>
> Have you more information about this? Would be great to have this
> working. I know its a little bit paranoiac, but my intention is
> curiosity whether I can get it working, not the little amount of special
> security I get ;).

http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3639

This, and the manpage of the new cryptsetup release candidates.

[Karol Babioch]

On Do, 2009-10-29 at 16:37 +0100, Thomas Bächler wrote:
> This, and the manpage of the new cryptsetup release candidates.

Thanks. I will try to set this up as soon as this version gets stable.

--
Best regards,
Karol Babioch <karol@...>

[Santhosh Joseph]

On Thu, Oct 29, 2009 at 9:19 PM, Karol Babioch <karol@...> wrote:
> On Do, 2009-10-29 at 16:37 +0100, Thomas Bächler wrote:
>> This, and the manpage of the new cryptsetup release candidates.
>
> Thanks. I will try to set this up as soon as this version gets stable.
>
> --
> Best regards,
> Karol Babioch <karol@...>
>


For disk encryption, why not use  truecrypt  ?

-Joseph

[Thomas Bächler-2]

Santhosh Joseph schrieb:
> For disk encryption, why not use  truecrypt  ?

Why use truecrypt?

[Santhosh Joseph]

On Fri, Oct 30, 2009 at 4:21 PM, Thomas Bächler <thomas@...> wrote:
> Santhosh Joseph schrieb:
>>
>> For disk encryption, why not use  truecrypt  ?
>
> Why use truecrypt?
>
>
http://www.truecrypt.org/

Main Features:

    * Creates a virtual encrypted disk within a file and mounts it as
a real disk.

    * Encrypts an entire partition or storage device such as USB flash
drive or hard drive.

    * Encryption is automatic, real-time (on-the-fly) and transparent.

    * Parallelization and pipelining allow data to be read and written
as fast as if the drive was not encrypted.

    * Provides plausible deniability, in case an adversary forces you
to reveal the password:

      Hidden volume (steganography) and hidden operating system.

    * Encryption algorithms: AES-256, Serpent, and Twofish. Mode of
operation: XTS.

-Joseph

[Thomas Bächler-2]

Santhosh Joseph schrieb:
> On Fri, Oct 30, 2009 at 4:21 PM, Thomas Bächler <thomas@...> wrote:
>> Santhosh Joseph schrieb:
>>> For disk encryption, why not use  truecrypt  ?
>> Why use truecrypt?
>>
>>
> http://www.truecrypt.org/

You didn't answer my question. We discussed dm-crypt and you suggested
to use truecrypt - without relating in any way to the problem being
discussed or providing a solution that truecrypt may or may not have for
it. Why is that? Can you even boot from a truecrypt-encrypted volume on
Linux? If so, is that implemented on Arch Linux? How secure is
truecrypt's key setup and how does it work?


The only advantage of truecrypt against LUKS is the plausible
denialbility feature that LUKS doesn't have, and the "hidden volumes",
which IIRC only work with FAT32 file systems on truecrypt and are thus
useless.

Also, truecrypt has had serious security problems in the past, and
instead of fixing them right away and informing the public, they just
took the website down for several months until they released a new
(on-disk incompatible) version (this is only as far as I remember it
though, and I don't have a source for it, but it must have been 3 years
ago or so).

LUKS has a mathematically/cryptographically well-founded key setup
procedure that makes brute force attacks against the passphrase
infeasible in pratice and thus provides a very high level of security.
It also allows to use any cipher and cipher operation mode available in
the Linux kernel, which includes (but is not limited to) the ones
provided by truecrypt.