Silk Road forums
Discussion => Security => Topic started by: hootsmon on October 08, 2012, 07:19 am
-
so i've got the basics with gpg down, using gpa I have encrypted a file, and I can decrypt it, but i end up with a plaintext version of the file on the file system. I want to be able to decrypt the file into memory, or the clipboard. That way (hopefully) the plaintext never hits the disk, and I don't have to worry about shredding. any ideas?
-
so i've got the basics with gpg down, using gpa I have encrypted a file, and I can decrypt it, but i end up with a plaintext version of the file on the file system. I want to be able to decrypt the file into memory, or the clipboard. That way (hopefully) the plaintext never hits the disk, and I don't have to worry about shredding. any ideas?
gpa, like most other gpg frontends, uses the clipboard to both encrypt and decrypt. Your message is never written to disk unless you save it to a file.
If you're worried about the swapfile, just turn it off. Just su to root, and use the command swapoff -a
If you want to turn swap on again, you can re-enable it with the command: swapon -a
Also, you can encrypt your swap file with a key that changes every time you reboot, but those instructions are beyond the scope of what I can cover here.
-
The way you phrase the question makes me wonder if you are not quite using GPG properly (ie: encrypting files that contain messages? why not just encrypt the message itself). There is no reason to save the plaintext, gpg --d , paste ciphertext, enter password, it displays the plaintext and doesn't save it anywhere. If you are worried about swap your best option is to just encrypt it with a random key.
-
But it is possible your question is not indicative of not properly using GPG, for example you could decrypt an encrypted .pdf and not want to save it to disk. I imagine you can output the decryption of a .pdf onto your terminal , but it will not be very helpful. In such a scenario one solution might be to load the ciphertext in a virtual machine and decrypt it there.
-
thanks guys.
I hope you don't mind no quotes, too lazy atm.
The file is on the disk, and encrypted. It needs to stay on the disk because I need its contents.
using gpa, there doesn't seem to be a way to decrypt it other than using the file manager and saving it in the clear to a file.
So one option given, if I'm remembering right, is to not use gpa and to use gpg on the command line, I can live with that.
for what it's worth my disks are already encrypted including swap. this is for an extra layer.
-
thanks guys.
I hope you don't mind no quotes, too lazy atm.
The file is on the disk, and encrypted. It needs to stay on the disk because I need its contents.
using gpa, there doesn't seem to be a way to decrypt it other than using the file manager and saving it in the clear to a file.
So one option given, if I'm remembering right, is to not use gpa and to use gpg on the command line, I can live with that.
for what it's worth my disks are already encrypted including swap. this is for an extra layer.
I don't get the problem. With gpa open, you click the clipboard icon. In clipboard, you use File, Open and then open your encrypted file, which will show up encrypted in the clipboard pane. I'm presuming that the file is saved or stored as ascii armored? If not, maybe that is the problem.
Use File, Decrypt in the clipboard pane to decrypt the file. The decrypted file is only on the clipboard. Nothing is saved to a file.
-
I also am not understanding the problem (if the solution is not 'do it in a virtual machine').
-
kmfkewm/Nightcrawler, I think he/she is asking this:
A PGP message is usually only a couple of kilobytes in size at the most. Therefore you can encrypt and decrypt PGP messages in main memory or RAM with ease. Once you switch the machine off, about five or ten minutes later the data is completely irrecoverable, which is a nice security feature.
However you are talking about PGP encrypted *files* if I am not mistaken. Most people will have about 4 GB - 16 GB at the most worth of RAM, with about half of that being used by the OS and other associated process/services. So you'll have about 50% - 75% of your RAM to use in practice for other applications, including your desire to decrypt to RAM.
So you are asking if you can decrypt a file (presumably quite a bit less than the size of your main memory or RAM), to this store, instead of to the hard disk.
I think the answer is yes, you can, so long as the file is sufficiently small in size, but I don't know the correct terminal command, I'll check back later with some info.
-
With gpa open, you click the clipboard icon. In clipboard, you use File, Open and then open your encrypted file, which will show up encrypted in the clipboard pane
Obviously I didn't read the instructions, and this, while may seem basic to you, didn't occur to me, and I didn't discover it. My file isn't armored, but I will do that. Thanks again. sorry to perplex you all and I appreciate your perseverance and patience
-
you can decrypt an encrypted file and have it display on terminal with gpg -d and it just treats it as any other ciphertext, the output will not be very helpful in 99.99% of cases though, your shell doesn't know what to do with a pdf file it just displays the raw bytes. To get it so that you can view it with a pdf reader, I don't know of a solution other than to save the output as a .pdf on the disk and then open it with the pdf reader. I tried to pipe the decrypted output to a reader from my terminal in the following way and it failed to work:
gpg -d test.pdf.gpg | evince
a solution would therefor be to put the ciphertext in a virtual machine, then decrypt it and save it as a .pdf file, then open that file. You can do all of this from memory with a virtual machine, but without a virtual machine I don't know how else you would load the plaintext as a .pdf file with your reader without having to write it to the HD, since the file is saved as a .pdf only in the virtual machine which you can configure to be entirely in the hosts RAM.
-
If you decrypt a PGP message, the decrypted plaintext will be displayed in terminal, and - I assume - only stored in the RAM.
If you decrypt an encrypted file, like a pdf, the decrypted file will get stored on the hard drive, in the same directory as the original encrypted text. If you want to securely delete it, you can use the shred command.
If you use full disk encryption (which I highly recommend), this whole problem is non-existent.
-
If you use full disk encryption (which I highly recommend), this whole problem is non-existent.
incorrect. it's only non existent when the computer is off, while it's on and in use, it's decrypted.
-
If you use full disk encryption (which I highly recommend), this whole problem is non-existent.
incorrect. it's only non existent when the computer is off, while it's on and in use, it's decrypted.
Fair enough, I see your point.
I guess the bottom line is, if somebody gets hold of your computer while the encrypted disk is mounted, you are caught dead in the water.
Maybe, if you're a skilled programmer, you could reprogram gpg in such a way that it automatically securely erases any file saved to the hard drive after reading. Until that's possible, you'll have to manually shred it.
-
I use ramfs for this purpose. Let's say that you want to use /ramfs as a mount point. The syntax would be something like: mount -t ramfs /ramfs /ramfs
Memory pages that back ramfs contents are guaranteed never to be swapped out (unlike tmpfs), so I find it ideal for temporarily decrypting small files I wish to never lie on my HDD.
I don't recommend relying on the shred command, especially on journaling file systems like ext3/4, XFS, or JFS -- it's not secure.
-
The problem with FDE, is that the judge/jury are seriously unlikely to believe you've "lost" your passphrase if they have evidence you've been logging in periodically and there is a record of this.
Every tool has a place, and also limitations. Things like FDE should be treated for what they are, a last resort. Like the forensic scientist doing a AMA over in the other thread is saying, the best thing is to have a small footprint in the first place.
-
In the USA it doesn't matter if you have lost your passphrase or not, probably. You can just plead the fifth. There have been a few CP cases thrown out by the judge because all the prosecution had was an IP address. The accused refuse to decrypt their drive, the government experts have to admit that an IP address is not solid proof, the judge throws the case out.
-
In the USA it doesn't matter if you have lost your passphrase or not, probably. You can just plead the fifth. There have been a few CP cases thrown out by the judge because all the prosecution had was an IP address. The accused refuse to decrypt their drive, the government experts have to admit that an IP address is not solid proof, the judge throws the case out.
If everybody did FDE it'd be no big deal. But almost nobody does. So using FDE is always suspect. Remember how you were saying intelligence info != evidence? ;)
To my mind it is preferable that you have no physical footprint whatsoever. No usb keys, no portable media. It may be possible just to have a thin client setup so there is no local storage at all. You have your computer (like the Pi) magnetically attached to a drainpipe across the city half way up some skyscaper, and you login to that remotely. I'm pretty sure this is possible.
So, you can do this with the regular net, where you have rented space on machine in some server farm across the globe in another jurisdiction. The practical problem there is almost nobody has enough bandwidth to do that without serious frustration unless you're from Japan or South Korea or similar.
So, if you have some specialized network hardware capable of delivering > 50 - 100 Mbps from A to B for a range of several kilometers, then this is an ideal way to make busting you extremely complicated. They can have your password, no problem. But they only have a dumb terminal, no data unless they've tapped your station. Actually best of all, you'd have all your "real" hardware lying about for them to investigate, none of which you use for SR related business.
Now I'm sure there's holes in such an idea, but the principal seems sound. Thoughts?