Cryptography 3: Using Your GnuPG Key
by darkotter on Feb.08, 2010, under Guest speakers
Bonjour tout le monde, et bienvenue a la troisiemme ‘post in this series’. I can’t really speak French. This week it’s time to engage in some actual encryption, although only to ourselves at this point.
Encrypting a Message Symmetrically
GnuPG can also be used to do standard symmetric encryption. This is simply standard encryption with no use of public keys, you type a passphrase in when you encrypt the file, and anyone who knows (or can guess) that passphrase can use it to decrypt the message. To do this in GnuPG simply execute (in a terminal):
gpg -c {FILENAME}
It is worth noting that it is possible to encrypt a message using GnuPG so that it can be decrypted with multiple private keys, and or a symmetric passphrase. To do this, simply add the -c option in with the other options for the other commands to indicate that you want the message to include symmetric encryption.
Encrypting a Message Asymmetrically
Much like the -c switch, to specify that you want a message encrypted asymmetrically (public key encryption) you simply have to add a short switch, in this case -e. The trick with encrypting a message asymmetrically though is specifying the recipient. This can be done in two ways. Firstly, if you do not otherwise supply any recipients, GnuPG will prompt you for them when you run the command. The second option is to specify each recipient on the command line, using the -r switch.
So, to encrypt a message and be prompted for recipients execute (in a terminal):
gpg -s -e {FILENAME}
N.B. I’ve added in the -s switch here because you really should use it – see the signing section below.
If you would rather specify each recipient on the command line you can, for example:
gpg -s -e -r hello@darkotter.com -r test@example.com
Note that, provided you added all the configuration to your gpg.conf file as discussed in the last post, whenever you use the -e switch you will be added as an extra recipient in addition to those you specify for the message, so you will be able to read any messages you send (handy for e-mail so you can still read them in your sent items folder), and if you should wish to encrypt something to yourself you need not specify yourself as a recipient (simply hit enter when GnuPG prompts you without entering any recipients).
Signing a Message
The other major operation that you can perform with GnuPG is signing a message. This uses your private key to sign a cryptographic digest (much like a fingerprint of the message) so that anyone who has a copy of your public key can verify that you made the message in question, and it has not been modified since you made it. The switch to indicate the message should be signed is -s, and it can of course be mixed with the other operations witches discussed (and usually is, it is considered usual to always sign any message that you are encrypting asymmetrically using -e, so much so that these options are usually supplied together as -se). You can also use it on its own:
gpg -s {FILENAME}
This might be useful if for example you wanted to make a public message, but show that you made it, much like your real signature on a public document. However, there is a problems with doing this, namely, people can only easily read the file this creates using GnuPG. Although they do not even need your public key to read the message (although it’s publicly available anyway of course, so they can easily acquire it to also be able to validate your signature), they do need GnuPG to process it as the file created is in the OpenPGP binary file format, and not everybody has GnuPG installed.
There is however a way round this, namely clear-signing. Unlike the other operations discussed so far, clear-signing can only be performed on it’s own as a single operation. It also modifies the file you give it directly, so be sure to try it out on something not too valuable first. Clear-signing adds a GnuPG/PGP signature to a file which can be verified using GPG or other PGP software, but it does it in such a way that the original content of the file is human readable. For example:
gpg -o- --clearsign msg.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
hello world, this is Matthew Gadd speaking.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCgAGBQJLbvTmAAoJEEN0HODG5Tot/YUQALOOsR6GrAXFBDn+X5Zi+zv/
+gcihRcKr8gqmUOCvvTd6vmLKWijM+XRIqRnGWST7H97UkC11eh4VmiHjfaGRWED
DzSvIPqvd3L7rzSvwqb/6Ir/dm6ylG2EbRjp+enZMbIhNiphXiC/B5OfsdoSLjNz
FEh5hckE/p/ad1rdaY70GyJn4gHn3YCYrGldBBK/qWh28QAlngzR7XfH27k3HJBY
lzAX8xowG38YzMaXQf3N2ptm/GE6Ewcug9MIz7Ccep4JtuKvaZXNKiXnzONl1jOK
rjSAUBOM2tkk8Gl4tDOJIddh5gTXCU0oCk9/WI2DV2YHG5qU+U6nn5OIlonBUJ6a
1+DsK2n5US7a9+rB2+xlV/fm+yPS4YDFvtd0tpmydHn0ciSS/Nrv7bjvZcr3Mh8R
bE8dM1GXVVlGivQCssVuexacgGq0r6FNbaU903+bnOM1h6aAr0MRFtsXQtYLeKpN
LcbTv3JaEML9Lo91JeimzjOi9QlbUeGjgeHbgiesUy9oay/zkufcy5s/VlI4d/2T
pHFwuAb9pNONet+iVF/cAxhJ0LR97CLQM1T4o3FkWgs+fdUUsyfgAL3r9SZd3g8T
iwtc0WV8YsHiSAr6WoagyGNxhJ8anOOj4SVWbOtbx8UHXNlc+AaobBOLOqz6GilZ
tVyWa7BU8UOE0XWTGsaL
=74RL
-----END PGP SIGNATURE-----
This ensures that the message can be verified, and the message is still readable. This is commonly used in e-mails to mailing lists, so those with GnuPG can verify the sender of the messages, but other people on the mailing list who may not have it can still easily read the message.
However, this signature has still modified the file which poses a problem. For instance, what if you wanted to distribute an announcement as a pdf file, and wanted to sign it but have it readable by everyone. Clear-signing it would corrupt the pdf file, and signing it normally would mean that only those with GnuPG or other PGP software could read the (un-corrupted) announcement. However, there is a third option:
gpg -b {FILENAME}
The -b option is the short option for the detached-sign operation. This creates an additional file (by default named the same as the input file, but with .sig as a suffix) which contains the signature. This means that you have to distribute two files if you want the signature to be available. However, the original file is unmodified (so anyone can still read it easily, and binary files will remain uncorrupted, source files can still be compiled etc.), and anyone with PGP software can run it on the additional file containing the signature. GnuPG will then search for the file that has been signed (according to the filename stored in the signature, and it will prompt you for the files location if it cannot find it) and then check the signature against the data in the file. This form of signing is commonly used to verify the integrity of tarballs available for download - the signature file is also made available for download, and users who wish to verify the download can obtain this in addition to the tarball in order to verify it.
Mixing Operations
The first three operations we have discussed (symmetric and asymmetric encryptions, and signing) can all be mixed for the same message simply by adding the options together. For instance:
gpg -c -s -e {FILENAME}
Will produce a message that can be decrypted with the passphrase you specify, or it can be decrypted by any of the recipients you supply using their private keys, and once decrypted by either message it can be verified that you were the author of the message.
Clear signing and detached signing cannot be mixed with any other operations however - this is simply due to the nature of what they do and trying to use a method of signing designed to keep a message easy to read in addition to encryption would of course not make sense.
The PGP format
All of these operations (including clear signing and detached signing) create files which are in the OpenPGP format. Excepting clear-signing they all create files in the binary format by default (for detached signing, the signature file is binary although the source file may not be). However, there is also an ASCII variant of the OpenPGP format (which basically consists of the binary data encoded in base64 and wrapped in headers to indicate that it is an OpenPGP message).
In order to create a file in the ASCII format, simply add the Whereas normally GPG creates files with the In general I choose which format to use based on the following rules. If it's for an e-mail, always ASCII (although like most Linux e-mail software, my e-mail client handles the encryption and this choice for me anyway). If it's not for e-mail and it's a large-ish file (more than about one megabyte) then use the binary format. Otherwise, always use the ASCII format (just in case). It's worth noting, that while using GPG from the command line is very versatile, for many people it's not the easiest option. Fortunately there are many frontends for GnuPG and PGP that integrate it into various pieces of software. Most Linux e-mail clients (including Evolution which I use) support GPG natively - once you've set up your key, you simply tell the e-mail client which key to use for your e-mail account, and then you can choose to encrypt a message, and it will handle constructing the encrypted e-mail for you (PGP has it's own PGP/MIME extension to e-mail formats which can be used, similar to S/MIME for X.509 security), and will supply GPG the recipients of the message from the e-mail recipients you entered. Clear-signing is also supported by most, and is often enabled as the default for all messages by some people. I note (mainly because of its popularity) that Thunderbird does not support GPG itself, although this may be because excellent support for GPG can be added to Thunderbird by installing the EnigMail extension. IIRC, EnigMail also supports helping a user to generate a private key without using the command line (although I recommend using the command line as described so we can set our own security options). As for encrypting or signing files, there are many graphical frontends available for GPG to do this. My favourite, which is available for the GNOME desktop, is Seahorse (which you may recall me instructing you to install earlier). Seahorse provides a nice GUI for managing your keys, as well as a passphrase caching agent. For file encryption it integrates with Nautilus (GNOME's default file manager) so that you can right click on any file and select to encrypt or sign it (or decrypt if it's already encrypted). Seahorse provides graphical prompts for recipients and other details so that the command line need not be used at all for most encryption tasks. Seahorse also provides a plugin to GEdit (GNOME's default text editor) which allows you to encrypt, sign, or decrypt ASCII format PGP messages simply by selecting them in GEdit and clicking the appropriate button. That concludes today's post, I hope you found it interesting, and possibly even useful. In the next post I plan to cover how to obtain other people's public keys (as well as how to tell whether you can trust them) so that you can use these techniques to send messages to other people. DO out.-a switch in addition to other options, for example:
gpg -a -s -e {FILENAME}</code
.gpg or .pgp extension, when the ASCII format is used the generated files will have the .asc extension. The main advantage of the ASCII format is of course that it can be safely transmitted over mediums which only support the transfer of ASCII data (for example e-mail - your e-mail client encodes binary data in base64 for you when you send attachments to work around this). However the disadvantage of it is that any message will be longer in the ASCII format as the base64 encoding increases the length of data it encodes.Ease of Use
Next Time
2 Comments for this entry
1 Trackback or Pingback for this entry
-
gnupg public key
March 30th, 2010 on 4:11 pm[...] it with a simple password, you can use GnuPG and symmetric key encryption for the job. Using thisCryptography 3: Using Your GnuPG Key tmacukThe other major operation that you can perform with GnuPG is signing a message. … do not even need [...]
February 8th, 2010 on 11:19 am
A well written article. It does remain to be pointed out that public key cryptography is no longer secure. The best cryptography remains a single-use secret key, much longer than the original message. The problem of securely transmitting the key remains.
February 8th, 2010 on 4:35 pm
Actually Monte, public key cryptography remains relatively secure until the advent of quantum computing. However, you are correct that no current form excepting the one which you describe can currently be proven to provide perfect security (in case you’re wondering, the type to which you refer is one-time-pad encryption).
However, much as it is not perfectly secure, encryption such as this is still the best available choice for general use, for several reasons.
It is so expensive and time consuming to break RSA that in general it is not worth it for a message sent by the general public – so no-one will bother to read your messages.
Also, although a one-time-pad is feasible for certain specialist applications (e.g. the hotline between the president of the USA and Moscow), the problem of key distribution that it creates (and which RSA solves) makes it so expensive and logistically difficult as to be impossible.
There is of course quantum encryption which has been proven to be perfectly secure mathematically (and has the advantage that not only would an eavesdropper be unable to read the message, but you would be made aware that there was an eavesdropper). However, while it has been implemented it is still strictly laboratory technology.
You are correct that the only completely secure (and thus best in terms of pure security) form of encryption is one-time-pad (unless you are rich enough to use quantum cryptography), however RSA is still considered secure enough for general use. In fact, assuming that you use a key larger than 3072 bits (which you will be if you followed the steps in my earlier guides) it is considered to be secure for the next ten years, and is accepted by the NSA to protect documents classified to top secret level. This of course does also rely on using a matching level of symmetric cipher security – again using the custom settings I described will use AES256 encryption, which is believed to be secure even after the advent of quantum computing. I have no doubt it is possible to gain access to messages encrypted using these techniques by other methods however – for example the world-renowned rubber-hose cryptanalysis attack.