directory that stores only in RAM (for decrypting to)

English Hardware
1

Sorry if this is the incorrect forum category, but I don’t know where else it might go.

I don’t encrypt entire partitions, but I do encrypt certain important individual files, so that I have several .gpg files here and there. When decrypting these .gpg files, I would prefer to not decrypt them to my hard drive. Rather, I want to only store the decrypted files in RAM. Accordingly, I’m looking for a directory that only stores in RAM.

What I’ve come up with so far is:

/dev/shm and /run/tmpfiles.d

However, I can’t really be sure that those directories are really RAM, as, for one thing, their size is recorded to be 4 gigs, whereas I have 8 gigs of RAM. Also, I tried putting a large file in those directories (a disc image), but after doing that, I checked a RAM meter and it did not show the appropriate increase in usage. So those two things make me think that those directories are NOT RAM. On the other hand, what does suggest that those directories are RAM is that storing files in them does not survive a reboot.

So… are those directories actually RAM? If not, how can I write to RAM?

2

On 03/04/2014 05:16 AM, rybnik wrote:
>
> Sorry if this is the incorrect forum category, but I don’t know where
> else it might go.
>
> I don’t encrypt entire partitions, but I do encrypt certain important
> individual files, so that I have several .gpg files here and there.
> When decrypting these .gpg files, I would prefer to not decrypt them to
> my hard drive. Rather, I want to only store the decrypted files in RAM.
> Accordingly, I’m looking for a directory that only stores in RAM.

Out of curiosity, why not just use full disk encryption? Super easy to
setup, and it makes all of this much easier. Just a thought…

> What I’ve come up with so far is:
>
> /dev/shm and /run/tmpfiles.d

/dev/shm is what I use, yes.

> However, I can’t really be sure that those directories are really RAM,
> as, for one thing, their size is recorded to be 4 gigs, whereas I have 8
> gigs of RAM. Also, I tried putting a large file in those directories (a
> disc image), but after doing that, I checked a RAM meter and it did not
> show the appropriate increase in usage. So those two things make me
> think that those directories are NOT RAM. On the other hand, what does
> suggest that those directories are RAM is that storing files in them
> does not survive a reboot.
>
> So… are those directories actually RAM? If not, how can I write to
> RAM?

RAM? Usually. Always? I’m not sure on that. The fact that the size is
less than your total RAM is a good indicator that it’s actually RAM and
not just generally virtual memory; however, I believe /dev/shm and
anything else from ‘tmpfs’ should actually be considered “virtual memory”,
meaning it is RAM whenever possible but could also be sent to swap (files
or partition) which may or may not be encrypted on your system (see my
note about full disk encryption again). If you have no swap (like my
laptop here) then there is no reason to think that any swapping will
happen to disk and you’re safe; if you do have swap, encrypt it, or be
sure to make sure you do not put enough in /dev/shm to use it, or be sure
to somehow clean it up before you lose control of your disks.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

3

On some of my systems, I mount “/tmp” as “tmpfs”. I do that with an entry in “/etc/fstab”


none   /tmp    tmpfs   defaults        0 0

though you can probably use “tmpfs” in place of that “none”.

It defaults to half of RAM size (your 4G). As far as I know, there is no guarantee that it won’t be partly in swap. I recommend that you encrypt swap.

If you don’t hibernate, then you can randomly encrypt swap. That way, you don’t have to enter a key on boot. (If you want details, ask).

4

Thank you, both.

Noted. But doesn’t that adversely affect read/write speeds? My hard drive is only 5400rpm.

I see. The files I encrypt are small text files (bank info, etc.) , so from that, I think it’s safe to say that they get put into RAM.

Aha.

5

Disk speed should not be relevant here. There is no addition disk activity with an encrypted partition. The additional cost is CPU cycles to do the encryption/decryption.

I’m using crypto (actually, an encrypted LVM) on several systems. Even on a older slowish 32-bit system, the cost of the crypto is small enough that I do not notice it.

6

On 2014-03-04 18:06, rybnik wrote:
>
> Thank you, both.
>
> ab Wrote:
>> Out of curiosity, why not just use full disk encryption? Super easy to
>> setup, and it makes all of this much easier. Just a
>> thought…
>
> Noted. But doesn’t that adversely affect read/write speeds? My hard
> drive is only 5400rpm.

No.

Actually, the faster the hard disk is, the more the delay due to
encryption would be noticed.

The delay is CPU and memory bound. If they are reasonably fast, they
have the data ready for the disk faster than the disk can write it.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)