http://xkcd.com/538/

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

On Tue, Oct 27, 2009 at 10:34 PM, Karol Babioch <karol@babioch.de> 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@babioch.de>

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.

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

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@babioch.de>

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@babioch.de>

Santhosh Joseph schrieb:

For disk encryption, why not use truecrypt ?

Why use truecrypt?

Santhosh Joseph schrieb:

On Fri, Oct 30, 2009 at 4:21 PM, Thomas Bächler <thomas@archlinux.org> 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.