Silk Road forums

Discussion => Security => Topic started by: 16bitgirl on June 28, 2012, 12:58 pm

Title: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on June 28, 2012, 12:58 pm
Despite being a computer geek, I found GPG a bit tricky to use at first, and I'm guessing I'm not alone, so here is my guide to GPG usage.

First off - import the keys of the sellers you want to send stuff to. On their user page, they should have a block of text that looks like this:

Quote
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Something or other
Charset: This line may or may not be here

RandomStuffLikeRDri646D7xb24RG (etc etc)
-----END PGP PUBLIC KEY BLOCK-----

Copy that entire block (including the lines with -----BEGIN----- and -----END-----) into a text file, say, lucykey.txt (I've decided my pretend seller is called Lucy), save it in your home directory, then open up a terminal window / command line, which should start out in your home directory. Type the following command:
Code: [Select]
gpg --import lucykey.txtAnd GPG will show you some information about the name of the person, for example:
Code: [Select]
gpg: key 7A8B9C0D: public key "Lucy <lucy@sky.diamonds>" imported
gpg: Total number processed: 1
gpg:               imported: 1
Which means that GPG now knows how to encrypt files for "Lucy", the part before the email address being what GPG calls her. To encrypt a text file, such as top_secret.txt for Lucy, you'd type:
Code: [Select]
gpg -e --armor -r "Lucy" top_secret.txtGPG will ask if you want to trust the key, and assuming you answer "y", it'll spit out a file called top_secret.txt.asc which is the PGP-encoded version of top_secret.txt, and can only be read by Lucy. This'll look a lot like those PGP public key blocks, like this:
Quote
-----BEGIN PGP MESSAGE-----
Version: Something or other

RandomStuffLikeRDri646D7xb24RG
-----END PGP MESSAGE-----
Just copy that whole block from top_secret.txt.asc to Lucy, and she'll be able to read it!

Now, personally I didn't quite like the way that worked. I mean, what if some time later, I want to encrypt top_secret.txt for Mary-Jane? After I'd done it, I might forget whether top_secret.txt.asc was Lucy's version or Mary-Jane's version. So I created a bash script! Here it is, in all its glory:
Code: [Select]
#!/bin/bash
if [ "$#" -ne 2 ]; then
    echo "usage: $0 recipient_name text_file_to_encrypt"
    echo "The recipient name must contain no spaces, but email addresses also work."
    exit 1
fi
gpg -e --armor -o $2-$1.asc -r "$1" $2
echo
echo "File $2 has been encrypted, and saved as $2-$1.asc"

# This script is released to the public domain. In countries where
# this is not possible, such as Soviet Russia (Domain Publics YOU!),
# then this script is released under the following license:
#
# DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
#                    Version 2, December 2004
#
# Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
#
# Everyone is permitted to copy and distribute verbatim or modified
# copies of this license document, and changing it is allowed as long
# as the name is changed.
#
#            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
#   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
#
#  0. You just DO WHAT THE FUCK YOU WANT TO.
Save this script somewhere in your path (I recommend the name gpg-encrypt), remembering to run chmod +x on the file. Then, all you have to type is the following:
Code: [Select]
gpg-encrypt Lucy top_secret.txtAnd instead of giving you a file named top_secret.txt.asc, it'll give you a file named top_secret.txt-Lucy.asc, eliminating any confusion! The script also tells you what it's called the file just to make it easier to find. Anyway, I hope this information and script helps people who find GPG as cumbersome as I do :D

Note: If your vendor's PGP username has a space in it - say...
Code: [Select]
gpg: key 1C2D3E4F: public key "Lucille Ball <i@love.lucy>" importedThen you must use the email address instead of the username, as in...
Code: [Select]
gpg-encrypt i@love.lucy top_secret.txtThe script above has been updated to tell you this if you try and use usernames with spaces :D

Second note: If you forget your vendor's PGP key name, simply type the command...
Code: [Select]
gpg --list-keysOr if the list of keys is too long and half of it scrolls away into oblivion...
Code: [Select]
gpg --list-keys | less
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on June 28, 2012, 01:09 pm
And instead of giving you a file named top_secret.txt.asc, it'll give you a file named top_secret.txt-Lucy.asc, eliminating any confusion! The script also tells you what it's called the file just to make it easier to find. Anyway, I hope this information and script helps people who find GPG as cumbersome as I do :D

Nice, the only drawback is if you don't want a bunch of filenames which show who they're encrypted to.  That can be avoided by keeping them in an encrypted volume (e.g. TrueCrypt), though.

Also you can see the keys a file has been encrypted to by using "gpg -v $filename" (after entering your passphrase if you also encrypted it to yourself).  The only time that won't work is if the "throw-keyid" option was used when the file was created.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on June 28, 2012, 01:24 pm
Ah, I did not know of this option! Curse you GPG, with all your twisty little turns! You're quite right though about not keeping the files around, personally I use shred or srm on the files once I'm done with them, but a TrueCrypt partition would also work excellently :)
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on June 28, 2012, 01:26 pm
Ah, I did not know of this option! Curse you GPG, with all your twisty little turns! You're quite right though about not keeping the files around, personally I use shred or srm on the files once I'm done with them, but a TrueCrypt partition would also work excellently :)

The "-v" flag invokes verbose mode so it will display more detail about whatever it is doing.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on June 28, 2012, 03:06 pm
The "-v" flag invokes verbose mode so it will display more detail about whatever it is doing.

Nah... for real fun use gpg --list-packets

Or make it a little easier on yourself and use pgpdump:

http://www.pgpdump.net/
http://www.pgpdump.net/about.html

As the site says it makes --list-packets more human readable.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on June 28, 2012, 03:43 pm
Or you could, as I suggested, use the much simpler option of shred :P It overwrites the file repeatedly with both randomness and those fancy patterns that stop forensic file recovery, does the same thing to the file name, and removes the file afterwards, with the -u flag. Personally, for ultimate paranoia, I'd recommend:

Code: [Select]
shred -u -n 50 OH_NOES_NOONE_MUST_EVER_SEE_THIS.txt :)
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on June 28, 2012, 03:50 pm
Licensing info removed from this post, placed into the script itself.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: CaliTrees on June 28, 2012, 03:52 pm
Instead of truecrypt you can use dm_crypt modules for encrypting your root, home and swap partitions.  Keep it GPL yo.  There's good documentation for gentoo and archlinux.

I know some really like CLI but there is a GTK2 gui app you can use instead.  http://gpg-crypter.sourceforge.net/  You would still need to use your keyring to add the public keys of your coorespondants.  However you can use seahorse for a GUI to do that.

Nice lil bash script.  I'm really waiting for a browser plugin too, that would rock.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on June 28, 2012, 03:57 pm
You know, I could never get Seahorse to work properly, and by the time I'd figured things out, it was the command line where I had my knowledge. But hopefully these graphical apps can help others :)
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: CaliTrees on June 28, 2012, 04:01 pm
Seahorse is used to just import the public keys.  So you open it, go to file import and find your text file.  Once that's done you can close it and open GPG-crypter and it'll have your imported key.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on June 28, 2012, 04:06 pm
Seahorse is used to just import the public keys.  So you open it, go to file import and find your text file.  Once that's done you can close it and open GPG-crypter and it'll have your imported key.

Personally I find that "gpg --import pubkey.asc" is quicker.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: vlad1m1r on June 28, 2012, 05:37 pm
Despite being a computer geek, I found GPG a bit tricky to use at first, and I'm guessing I'm not alone, so here is my guide to GPG usage.

First off - import the keys of the sellers you want to send stuff to. On their user page, they should have a block of text that looks like this:

Quote
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Something or other
Charset: This line may or may not be here

RandomStuffLikeRDri646D7xb24RG (etc etc)
-----END PGP PUBLIC KEY BLOCK-----

Copy that entire block (including the lines with -----BEGIN----- and -----END-----) into a text file, say, lucykey.txt (I've decided my pretend seller is called Lucy), save it in your home directory, then open up a terminal window / command line, which should start out in your home directory. Type the following command:
Code: [Select]
gpg --import lucykey.txtAnd GPG will show you some information about the name of the person, for example:
Code: [Select]
gpg: key 7A8B9C0D: public key "Lucy <lucy@sky.diamonds>" imported
gpg: Total number processed: 1
gpg:               imported: 1
Which means that GPG now knows how to encrypt files for "Lucy", the part before the email address being what GPG calls her. To encrypt a text file, such as top_secret.txt for Lucy, you'd type:
Code: [Select]
gpg -e --armor -r "Lucy" top_secret.txtGPG will ask if you want to trust the key, and assuming you answer "y", it'll spit out a file called top_secret.txt.asc which is the PGP-encoded version of top_secret.txt, and can only be read by Lucy. This'll look a lot like those PGP public key blocks, like this:
Quote
-----BEGIN PGP MESSAGE-----
Version: Something or other

RandomStuffLikeRDri646D7xb24RG
-----END PGP MESSAGE-----
Just copy that whole block from top_secret.txt.asc to Lucy, and she'll be able to read it!

Now, personally I didn't quite like the way that worked. I mean, what if some time later, I want to encrypt top_secret.txt for Mary-Jane? After I'd done it, I might forget whether top_secret.txt.asc was Lucy's version or Mary-Jane's version. So I created a bash script! Here it is, in all its glory:
Code: [Select]
#!/bin/bash
if [ "$#" -ne 2 ]; then
    echo "usage: $0 recipient_name text_file_to_encrypt"
    exit 1
fi
gpg -e --armor -o $2-$1.asc -r "$1" $2
echo
echo "File $2 has been encrypted, and saved as $2-$1.asc"
Save this script somewhere in your path (I recommend the name gpg-encrypt), remembering to run chmod +x on the file. Then, all you have to type is the following:
Code: [Select]
gpg-encrypt Lucy top_secret.txtAnd instead of giving you a file named top_secret.txt.asc, it'll give you a file named top_secret.txt-Lucy.asc, eliminating any confusion! The script also tells you what it's called the file just to make it easier to find. Anyway, I hope this information and script helps people who find GPG as cumbersome as I do :D

+1 for a very well put together post 16bitgirl well done! If you need help encrypting Truecrypt/LUKS partitions please let me know I'd be happy to help.

V.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: bogben on June 28, 2012, 07:13 pm
Or you could, as I suggested, use the much simpler option of shred :P It overwrites the file repeatedly with both randomness and those fancy patterns that stop forensic file recovery, does the same thing to the file name, and removes the file afterwards, with the -u flag. Personally, for ultimate paranoia, I'd recommend:

Code: [Select]
shred -u -n 50 OH_NOES_NOONE_MUST_EVER_SEE_THIS.txt :)

Yes but is it truely random? Not if it uses /dev/urandom and very likely not if it uses /dev/random as srm does. Of course I susupect that either of these is plenty random enough to stop a local police force techie and if the big boys are after you why don't you know all this and plenty more besides!
As it happens both shred and srm suffer from the same problem in that they are incapable of tracking down various places on the disk the auto save function (or whatever) places it as is often the case, especially with the newer ext4 formats in linux. Thus my paranoia makes me run :
shred -v -u -n 35 /dev/sdc1 on any disk/usb that I worry about, followed by (after the tedious reformatting):
sfill -v /media/USB1
I do not recommend this you have a disk bigger than about 4GB and would like to turn your computer off within 5 full days of begining this  :-\
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on July 02, 2012, 10:12 am
A caveat - the first version of my script will not accept recipient names with a space in them. Email addresses work, though. I'll update the first post with the new version of the script, which just adds this info to the usage guide you see if there's too few/many parameters.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on July 02, 2012, 01:21 pm
Yes but is it truely random? Not if it uses /dev/urandom and very likely not if it uses /dev/random as srm does. Of course I susupect that either of these is plenty random enough to stop a local police force techie and if the big boys are after you why don't you know all this and plenty more besides!
As it happens both shred and srm suffer from the same problem in that they are incapable of tracking down various places on the disk the auto save function (or whatever) places it as is often the case, especially with the newer ext4 formats in linux. Thus my paranoia makes me run :
shred -v -u -n 35 /dev/sdc1 on any disk/usb that I worry about, followed by (after the tedious reformatting):
sfill -v /media/USB1
I do not recommend this you have a disk bigger than about 4GB and would like to turn your computer off within 5 full days of begining this  :-\

Well, there's no such thing as true randomness in computers, unless you use specialist hardware like... I dunno, a device that generates randomness from the measured speed of a guinea pig wheel or something. Also, half of what shred and srm use now aren't random (or pseudorandom) patterns, but some specific pre-defined patterns that are supposedly great for wiping the magnetic patterns so as to be forensically unrecoverable. You are correct, however, that some newer filesystems and some harddrives (and most flash drives) will have areas you can't access that may contain sensitive data. To make matters worse, your method of wiping the "entire" device may not actually wipe the entire device, as quite often (always with flash devices), there will be parts of the disk that aren't shown to your computer, used for various purposes including replacing space from disk areas that have gone bad. This is certainly a concern, and I do hope that the next iteration of the ext filesystem includes features to specifically allow secure erasing utilities to get around the problems caused by these newer filesystems.

It may well be best to keep all these files in an encrypted partition, and then to securely erase said partition when you're done with it (especially in countries like the UK where you can go to prison if you don't hand over your decryption keys if the police ask for them). Either that, or disguising an encrypted partition as a second encrypted swap partition that you "forgot" to switch on in an operating system like FreeBSD. Encrypted swap partitions should be indistinguishable from other encrypted partitions, and have the advantage that the OS generates the encryption key at random on boot, since you have no need to know what it is, and so you have a perfectly legitimate reason for being "unable" to hand over such an encryption key. As in, you "deactivated the second encrypted swap partition temporarily, meant to turn it back on but forgot to, and there's no way of retrieving the key for it". Of course, if the fake-swap partition were mounted in an app like TrueCrypt when a hypothetical LE raid happened, even if you immediately unmounted it they might be able to retrieve the key from RAM unless your encryption app overwrites that area of memory when unmounting or something.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on July 03, 2012, 08:24 am
It may well be best to keep all these files in an encrypted partition, and then to securely erase said partition when you're done with it (especially in countries like the UK where you can go to prison if you don't hand over your decryption keys if the police ask for them).

I just read Section 49 of RIPA.  Wow, that's pretty special (and by "special" I mean it's completely fucked).  Now, IANAL, but (I've done a bit of digging through legislation in the past and) ...

Subsection (3) is just nasty, it gives them carte blanche to invoke it whenever they damn well please.

There may be some wriggle room available in Subsection (4), especially (4)(a), (4)(b) and (4)(c).  More so when it is combined with Section 50(1).

http://www.legislation.gov.uk/ukpga/2000/23/part/III  (clearnet)

It appears that the legislation demands that the notice must be delivered in writing or a a recordable form {49(4)(1)}, must describe the protected information being sought by the order {49(4)(2)} and must specify the matters the order relates to (e.g. a trial or investigation) {49(4)(3)}.  Which means that if a notice is made relating to messages encrypted to a GPG key and which were intercepted or covered a particular period, then the notice must specify which actual messages they want decrypted.

Plus Section 49(9) exempts keys (or subkeys) which are used to make digital signatures.  While Section 50 subsections (1) and (2) indicate that a person served with a notice had the option of providing the key or providing the decrypted data.  The rest of Section 50 appears to deal with situations where a key is no longer available or not available to the target of the notice.

Now, let's assume that someone in this situation has all the data which LE and/or spooks want and will comply with every legal request, but otherwise wishes to minimise the damage.  Let's also assume that the notice relates only to data encrypted with OpenPGP/GPG.  Here's what I would try:

1) Upon receipt of a notice confirm that it explicitly cites which messages or files they want (e.g. filenames, all email sent and received between dates X and Y, etc.) *and* that the specified data does actually relate to whatever reason there've given for the notice/demand.

2) If the notice does not explicitly specify the messages, files or the specific issue (subject matter) that they want, then decline on the grounds that the order does not provide the right detail.  This is just a delaying tactic and will not last, but the aim is to make sure that they explicitly list each file or message they want (are aware of).  Everything else is off the table.  Go through the first and second points here until they get it right.

3) When they (finally?) do get it right, decrypt the relevant data and provide them with the decrypted data.  Perhaps in conjunction with some log of the decryption process so they know the data hasn't been doctored (a video file of the screen during the decryption ought to be enough).

It's still possible that this might not be enough for them, or a conspirator might still be encrypting data to the relevant public key or they might have invoked Section 51, which is probably the worst part and explicitly mentions demanding keys under certain circumstances.  So let's continue where we left off.

4) If the notice specifies the messages of files, but they demand doing the decryption themselves for some verification process (or whatever other reason) then provide them with a spreadsheet containing two columns: the filename or message identifier and the GPG session key for the symmetric cipher used for that specific message.  Use "gpg --show-session-key" to obtain the session key for each message, the process will decrypt the file.  The filth (LE/spooks) will use "gpg --override-session-key $SESSIONKEY $filename.txt" to obtain what they want.  It's possible that the number of files or messages may make this painful them.  If you're using gpg-agent (for passphrase caching) it should be a lot easier to extract session keys with a script than it would be for those keys to be used to decrypt the corresponding files (it can be done, of course, but with more coding time spent on that script).

5) If the number of files is constantly changing as a result of others encrypting to that key then session keys won't cut it.  A key will be required to decrypt the specified messages, but that key will also be able to be used to decrypt any other file or message that has been encrypted with that key.  If Section 51 is invoked to demand the key the situation is the same as if the key needs to be provided instead of session keys.

If the key must be provided, then only provide the encryption subkey's secret component.  Details of how to do this (and keep a copy of just the encryption subkey against exactly this type of situation) is here:

http://dkn255hz262ypmii.onion/index.php?topic=28859.0

Once the encryption subkey (with its alternate passphrase) has been handed over, update your master copy to do the following:

* Revoke the subkey that has been provided to LE/spooks.
* Create a new encryption subkey.
* Export the public key and disseminate it everywhere that you have previously.

If using that key for encrypting local files or non-transmitted files, stop doing that and switch to a new key explicitly for that purpose which is not provided to others or use a different encryption method.

Either that, or disguising an encrypted partition as a second encrypted swap partition that you "forgot" to switch on in an operating system like FreeBSD. Encrypted swap partitions should be indistinguishable from other encrypted partitions, and have the advantage that the OS generates the encryption key at random on boot, since you have no need to know what it is, and so you have a perfectly legitimate reason for being "unable" to hand over such an encryption key. As in, you "deactivated the second encrypted swap partition temporarily, meant to turn it back on but forgot to, and there's no way of retrieving the key for it". Of course, if the fake-swap partition were mounted in an app like TrueCrypt when a hypothetical LE raid happened, even if you immediately unmounted it they might be able to retrieve the key from RAM unless your encryption app overwrites that area of memory when unmounting or something.

At that point you have to start looking into the feasibility of using the same trick as in _Cryptonomicon_; to build an electro-magnet into the doorway that LE will have to cart your stuff through when they seize it.  I haven't even vaguely looked into whether or not it would do enough damage to the drives.  RAM, however, isn't that fond of electro-magnetic fields, not does it retain data after a shutdown for long.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: 16bitgirl on July 04, 2012, 07:07 pm
Yes, the RIP Act is really quite fucked up. They brought it in alongside a flurry of tabloid scaremongering, claiming it would help catch paedophiles and terrorists (the two most tabloid-friendly excuses for doing anything). However, not only is RIPA a horrendous violation of privacy, it actually protects those two groups, especially the bloody paedophiles. If you were a paedophile with an encrypted partition of child porn, would you rather:

A) Refuse to hand over the encryption keys, and get up to two years in jail, on a rather obscure sounding charge?
B) Hand over the keys, get many years in jail with extra beatings and bum-rape thrown in, and be both on the Sex Offenders Registry and under probation for the rest of your life?
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: LouisCyphre on July 06, 2012, 01:06 pm
Yes, the RIP Act is really quite fucked up. They brought it in alongside a flurry of tabloid scaremongering, claiming it would help catch paedophiles and terrorists (the two most tabloid-friendly excuses for doing anything).

Like tabloids really have a leg to stand on after the Milly Dowler thing.  Their real objection to cryptography is it would prevent them from rifling through someone's data for the next story.

However, not only is RIPA a horrendous violation of privacy, it actually protects those two groups, especially the bloody paedophiles. If you were a paedophile with an encrypted partition of child porn, would you rather:

A) Refuse to hand over the encryption keys, and get up to two years in jail, on a rather obscure sounding charge?
B) Hand over the keys, get many years in jail with extra beatings and bum-rape thrown in, and be both on the Sex Offenders Registry and under probation for the rest of your life?

Nice point, I guess they really didn't think that one through.
Title: Re: Easy guide to GPG for Linux/BSD/Unix/OS X, plus automated shell script
Post by: bogben on July 06, 2012, 07:45 pm
Lol, I wasn't actually suggesting a random noise generator was required for secure deleterion :p I was being facetious. You are quite right that USB are the worst offenders as far as not being able to get all the data off it are concerned, the shred and srm commands are not infallibale (I'm not sure what is except secure-wipe of whatever its called) but rather a slightly easier method than DBAN (itself not foolproof as it doesn't overwrite bad sectors). The trick is to make it too hard and expensive for LE to justify digging far enough to find whatever you have missed.

RIPA is a supremely nasty piece of legistlation that makes encryption alone insufficient in the UK. The answer has to be the hidden partition or complete off-site storage (I store all my relevant files in a symmetrically encrypted file in an otherwise unused tormail). Louis has the right of it, but I would say that on top of that its worth changing keys every so often, I delete, revoke and recreate my keys about once a month, that way the most I can be forced to decrypt is 1 months worth of communication. The rest is beyond my ability to recover (as the key generation date will show).

I'm not sure about the electromagnet around the door, seems like the raid team would spot it? In any case I think RAM holds memory for about 15 minutes, though this can be extended by freezing it. I suspect that if you are high priority enough for them to send in techs with liquid nitrogen with the raid team you had better make sure you are using something that DOES wipe RAM (truecrypt in TAILS would work as it clears the RAM on shutdown).

Tabloids! Ha! The Sun called SR "Evil.com" which tells you all you need to know about them.