I'm assuming you're using a linux, and have a couple ideas...
Extract to RAM
An easy way would be to still create the decrypted file, but don't write it to disk. Put it in ram, with for instance a ramfs or tmpfs filesystem. Though, problems could be:
- The file may not fit in ram
- ramfs may increase in size until all ram is used (subsequently probably crashing)
- tmpfs may be written to your on-disk swap (also see that link for the difference between tmpfs & ramfs).
Your /tmp
or other folders (like /run
, /run/shm
, /run/user
) may already be mounted as a tmpfs, you can check with mount|grep tmpfs
.
To create a new tmpfs you can do this (optionally with a size in bytes if you wish, similar to -o size=16384
, I think it defaults to half of ram):
sudo mount -v -t tmpfs tmpfs /mountpoint
To use the older ramfs, that will not be written to swap, but doesn't have size limits this should work:
sudo mount -v -t ramfs ramfs /mountpoint
Though the link above warns:
ramfs file systems cannot be limited in size like a disk based file system which is limited by it’s capacity. ramfs will continue using memory storage until the system runs out of RAM and likely crashes or becomes unresponsive
Also, kernel documentation here also warns & says:
One downside of ramfs is you can keep writing data into it until you fill
up all memory, and the VM can't free it because the VM thinks that files
should get written to backing store (rather than swap space), but ramfs hasn't
got any backing store. Because of this, only root (or a trusted user) should
be allowed write access to a ramfs mount.
A ramfs derivative called tmpfs was created to add size limits, and the ability
to write the data to swap space. Normal users can be allowed write access to
tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.
Extract to an encrypted device or folder
If the above RAM problems are too much, you could use another program to encrypt the file on-disk again, but so it can be read & used unencrypted "on-the-fly" (ex. the decrypted version looks & acts like a regular file, but stays encrypted on-disk). You could create an encrypted partition or container file with dm-crypt/LUKS/truecrypt with cryptsetup, or an encrypted folder with eCryptFS or EncFS, and then decrypt your file there.
For example, to create a 1GB LUKS container file with ext4, mounted to the folder mountpoint-folder
, do this:
head -c 1G /dev/zero > 1G
sudo cryptsetup -v luksFormat 1G
sudo cryptsetup -v luksOpen 1G container
sudo mkfs.ext4 -v /dev/mapper/container
sudo mount -v /dev/mapper/container <mountpoint-folder>
And then decrypt your file into the mountpont-folder
where it will be readable, even though it's written to disk encrypted again.
eCryptFS is already installed in Linux Mint, Ubuntu, and many other distributions, do you may only need to run ecryptfs-setup-private
and then use the created ~/Private
folder.
EncFS probably has to be installed (similar to apt-get install encfs
) and then see it's man page here or here, a command like encfs ~/.secret ~/decrypted
should work.
Also, EncFS has a neat --reverse
feature that "takes as source plaintext data and produces enciphered data on-demand. This can be useful for creating remote encrypted backups, where you do not wish to keep the local files unencrypted."
1Hi, otus. I am new to stackexchange and I wasn't sure where to post the question. I will close the question but could you please point me in the right direction as to where i should post this question? – None – 2016-02-13T13:32:40.987
1Does simply using
-out /dev/stdout
work? – Iwillnotexist Idonotexist – 2016-02-13T21:22:45.207