Silk Road forums
Discussion => Security => Topic started by: LouisCyphre on August 05, 2012, 07:53 pm
-
This document is an introduction to the primary GPG configuration file, gpg.conf. In GPG 1.4.x it is the only configuration file, but GPG 2.0.x usually includes a separate configuration file for GPG Agent (gpg-agent.conf).
This guide requires basic use of the command line and use of a text editor, such as Notepad (Windows), TextEdit (OS X), Nano (Linux, BSD, OS X), Vim (Linux, BSD, OS X) or Emacs (Linux, BSD, OS X). More advanced editors, like Vim and Emacs, will display different parts of the config file in different colours to make them easier to read.
To view or modify your gpg.conf file you first need to locate it. It is in the GPG home directory for your user account, usually ~/.gnupg/ on Linux and OS X, but elsewhere on Windows machines. Some customised configurations may have it elsewhere, such as on a USB stick. If you already know your GPG files are on the USB stick (with GPG4USB) you can skip this location step and open the GPG home directory.
To locate the home directory for GPG open up a terminal (shell or DOS prompt on Windows) and type:
gpg --version
This will display output something like the following:
gpg (GnuPG) 1.4.12
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Above the list of algorithms you will see a line that begins with "Home:" which tells you where your GPG home directory is. Open the directory or folder specified.
The GPG home directory will contain a number of files. At minimum it will contain the following files:
gpg.conf = The GPG configuration file
pubring.gpg = Your public keyring, it contains all the public keys you have
random_seed = A file for introducing (pseudo) randomness to the encryption process
secring.gpg = Your secret keyring, it contains all the private keys you have
trustdb.gpg = The trust database for the keys you have
The first thing you should do is make a backup of your gpg.conf file. Name the backup something like gpg.conf.bak. That way if you make a mistake you can always copy from the backup and start again.
Once that is done, open the gpg.conf file in the text editor of your choice. You will see that most lines begin with the hash (#) symbol. This means they are comments and are not used by GPG as configuration. They provide instructions within the file and you should leave those explanations in place. I will not be including most of them in this guide.
The majority of the options that can be added to the gpg.conf can also be used on the command line. It is also possible to override these settings on the command line if a particular case calls for it. Furthermore it is possible to have multiple gpg.conf files and use different ones with the gpg --options command.
Where a key needs to be specified in an example (code snippet) I will use the traditional "0xDEADBEEF" entry. You should replace this with the key ID for your key.
Now, on with the configuration options.
*****
Option 1: No greeting
By default this is commented out, you should uncomment this otherwise you will see the GPG copyright notice every time GPG is invoked on the command line.
Default setting:
# Uncomment the following option to get rid of the copyright notice
#no-greeting
New setting:
# Uncomment the following option to get rid of the copyright notice
no-greeting
Option 2: Default key
The default key is used for signing messages and is the one you generally use. If it is not specified here then it needs to be specified on the command line. Most GUIs will keep their own record of the default key or will report what is set here.
Default setting:
# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.
#default-key
You should uncomment this line and include the key ID for your preferred key. The key ID is the hexadecimal code you see next to your name in the key list (either GUI or command line). The key can be specified in short form (with or without the 0x at the beginning) or long form.
I use the long form, like this:
# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.
default-key 0x7E8BE6B1DD7B4576
You should do something similar:
# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.
default-key 0xDEADBEEF
Option 3: Encrypting to yourself
This is the option that tells GPG to include your key (the specified key) every time you encrypt a message. So you never have to remember to include it when encrypting to someone. Particularly useful if, for example, your high and a bit scattered. ;)
Below the default key there is a section for a default recipient. Ignore this, it does not do what you assume, leave it commented out.
Instead skip further down to the encrypt-to section.
# Use --encrypt-to to add the specified key as a recipient to all
# messages. This is useful, for example, when sending mail through a
# mail client that does not automatically encrypt mail to your key.
# In the example, this option allows you to read your local copy of
# encrypted mail that you've sent to others.
#encrypt-to
The easy solution here is to uncomment this line and specify the same key as you did for the default key:
encrypt-to 0xDEADBEEF
There is, however, another option that is not included in the gpg.conf file by default. This is the hidden-encrypt-to option which will encrypt to the specified key, but hide that in the message. If an encrypted message is intercepted it can be examined and the key IDs it is encrypted with will be visible. If the hidden-encrypt-to option is used an analysis of a message will show that one of the keys was anonymous.
hidden-encrypt-to 0xDEADBEEF
Note: the hidden-encrypt-to option will only conceal your key ID, it will not conceal the key IDs of other recipients. To conceal other recipients key IDs refer to my previous guide on this topic:
http://dkn255hz262ypmii.onion/index.php?topic=29235.0
Also, if a message is signed that signature will reveal the sender's key. For this reason it may be preferable to clearsign the text of a message and then encrypt that signed message to preserve anonymity.
Option 4: character set
By default GPG uses the standard Latin-1 (ISO-8859-1) character set. If you want to use extended characters or are communicating with people in parts of the world where that is common (e.g. northern Europe or Asia), it is polite to be able to reproduce those characters correctly. In which case the charset option should be used.
Default setting:
# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set. Please check the man page
# for supported character sets. This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation. Note that future version of GnuPG will change to UTF-8
# as default character set. In most cases this option is not required
# as GnuPG is able to figure out the correct charset at runtime.
#charset
I usually set this to Unicode (UTF-8):
charset utf-8
Note: to get the full benefit of this you may need to set this in other environments as well (e.g. Firefox, Thunderbird, your text editor, etc.).
Option 5: Group names
Group names are used to specify or override key selection on the command line. Group lines can be used by email GUIs if they match a relevant email address. Most people won't use these options unless they use the command line, but it is worth mentioning.
Multiple group names can be included here for different keys or sets of keys. The comments in the file also includes important information about how group names are handled, with examples:
# Group names may be defined like this:
# group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678". Note there is only one level of expansion - you
# cannot make an group that points to another group. Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients. In these cases it is better to use the key ID.
#group mynames = paige 0x12345678 joe patti
For example, I have a group line for Pine because the PGP Club key does not contain any reference to the username Pine and because other keys are referring to PGP Club in the comment field. So I added this line:
group pine = 0x19B63B71E9094AF9
This enables me to just use the word "pine" when encrypting to Pine when I use the "-r" or "-R" flags.
Option 6: Keyservers
Most people won't use the keyservers and will want to leave this entire section commented out. There are two main reasons for this.
The first reason is that the keyservers are public, they can be accessed by anyone and once a key is on there it cannot be removed. Most people on Silk Road want to fly under the radar, so they leave keys on vendor pages or the PGP keys thread. A small number use the keyservers, but invariably those keys give no indication (or little indication) that they relate to Silk Road.
The second reason is that by default GPG will not use Tor. It will connect to the Internet directly from your IP address.
If you are using the separate Vidalia bundle (with Privoxy) instead of or in addition to the Tor Browser Bundle it can be safe to use keyservers with GPG with some configuration changes. If you do not or cannot do this then you should disable the keyservers.
The default keyserver configuration is this:
keyserver hkp://keys.gnupg.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com
If you want to disable keyserver access then change that section to this:
#keyserver hkp://keys.gnupg.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com
If you want to use keyservers safely either leave that section as the default or add an alternate keyserver:
#keyserver hkp://subkeys.pgp.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com
keyserver hkp://pool.sks-keyservers.net
To use the keyservers safely you need to tell GPG to use the Vidalia proxy server in the keyserver-options sections. To do that add the following line:
#keyserver-options auto-key-retrieve
keyserver-options http-proxy="127.0.0.1:8118"
You will need to have the Vidalia bundle running for this to work. If you use the Tor Browser Bundle you can run the Vidalia bundle in addition and at the same time.
The remaining options included in the gpg.conf file can remain commented out, but you should skip to the end of the file to add some more comments.
Option 7: Expert mode
This is not included by default as it opens up options that take a lot of reading and research to understand. If you do include it, leave it commented out and then uncomment it when you need it:
#expert
My instructions on creating large keys in expert mode are here:
http://dkn255hz262ypmii.onion/index.php?topic=28474.0
Option 8: Trust model
Trust is used by GPG to determine whether a key is safe to use, including whether to encrypt to a key. By default GPG will prevent you from encrypting to an untrusted key without a prompt asking you to confirm if you really want to.
Because we are outside of the Web of Trust and most people do not locally sign the keys they receive, using GPG on the command line will always trigger this prompt. While most GUIs override this by default.
Command line users will find this prompt becomes very irritating very quickly. To permanently override it, add the following option:
trust-model always
Note: this will stop the trust database (trustdb.gpg) from updating. If you like that to be updated you will need to periodically comment this line out and update the database. Once a month should be fine. If you don't know what this refers to then you're not using the trust database.
Option 9: DSA 2 keys
Originally DSA only supported SHA-1 and not SHA-2, to provide SHA-2 support to DSA keys you should add this option:
enable-dsa2
Option 10: Version concealment
If you do not want GPG to reveal the version number and the type of operating system you use (Windows, OS X, Linux, etc.) then add this option:
no-emit-version
Option 11: Key ID display format
By default GPG will display and identify keys in the short form without the 0x at the beginning (e.g DEADBEEF). This is the same as setting:
keyid-format short
The alternatives are 0xshort (e.g. 0xDEADBEEF):
keyid-format 0xshort
Long format (e.g. 12345678DEADBEEF):
keyid-format long
0xlong format (e.g. 0x12345678DEADBEEF):
keyid-format 0xlong
I use the 0xlong format, but most people prefer either the default short format or the 0xshort format.
Option 12: Preference lists
This is where you set the order in which you want GPG to select the algorithms for ciphers, hash digests and compression. There are four lines you should specify: default-preference-list, personal-cipher-preferences, personal-digest-preferences and personal-compress-preferences.
The default-preference-list should be the same as the personal-cipher-preferences, personal-digest-preferences and personal-compress-preferences; in that order.
If these preferences are set when a new key is created the key will inherit these preferences as its own. A key generated before these preferences were set may need to be updated if you want them to match.
There are two types of settings which can be used to specify a cipher, digest or compression algorithm: the name of it (e.g. AES256) or the GPG code for it (e.g. S9).
To view the supported algorithms with the corresponding GPG codes, run the following command:
gpg -v --version
On my system the result is:
gpg (GnuPG) 1.4.12
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12),
CAMELLIA256 (S13)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)
My installation of GPG 1.4.12 has been customised and may include more ciphers than some installations. I also use the GPG codes to specify the algorithm preferences. It may not be the best option to just copy my settings, but if your copy of GPG includes all the same ciphers as mine then you are welcome to use the same settings:
default-preference-list S9 S10 S13 S8 S12 S7 S11 S2 S3 S4 H10 H9 H8 H11 H3 H2 H1 Z2 Z3 Z1 Z0
personal-cipher-preferences S9 S10 S13 S8 S12 S7 S11 S2 S3 S4
personal-digest-preferences H10 H9 H8 H11 H3 H2 H1
personal-compress-preferences Z2 Z3 Z1 Z0
I've left IDEA out of that list because of prior patent restrictions (the patent is expired, but not many people use it anymore or have it installed), but if you want to include it just add it to the end of the ciphers:
default-preference-list S9 S10 S13 S8 S12 S7 S11 S2 S3 S4 S1 H10 H9 H8 H11 H3 H2 H1 Z2 Z3 Z1 Z0
personal-cipher-preferences S9 S10 S13 S8 S12 S7 S11 S2 S3 S4 S1
personal-digest-preferences H10 H9 H8 H11 H3 H2 H1
personal-compress-preferences Z2 Z3 Z1 Z0
If you want to select your own order it might be easier to use the algorithm names instead of the GPG codes. In general larger cipher strengths and hash sizes are better.
Option 13: Comments
It is possible to add a comment to ASCII armoured GPG output which appears under the version information, if it is included. To include a comment use:
comment some text here
In that example the result would be:
Comment: some text here
I do not recommend using this option at all, but it is worth mentioning because some programs will add a self-promoting comment to the gpg.conf file. GPGTools for Mac is a prime example of this.
*****
There are many other options, but this is a solid configuration file based on those options available. Also, this guide has already reached 17Kb, so I need to wind it up here.
Hopefully you will find this useful.
[/code]
-
Louis, this and the one on how to create larger keys is ridiculously useful :)
My only concern now is making sure it gets collated into some place so it doesn't just disappear into the ether.
I was saying to karma7 that we'd be coming up with comprehensive documentation for newbs/adepts/experts later on, but it looks like you're way ahead of us there :D
Oh, and...
POST 1000!!
WOOT!!
Now I feel that I deserve a cake with candles or something. You can even have a slice for the tutorials. Ohnomnomnomnom! Hmmmm. With this diet I have been thinking of little else than chocolate cake, truffles and jelly beans. It's like trying not to think of a pink elephant balloon. O_o
-
Louis, this and the one on how to create larger keys is ridiculously useful :)
Ah yes, this one:
http://dkn255hz262ypmii.onion/index.php?topic=28474.0
My only concern now is making sure it gets collated into some place so it doesn't just disappear into the ether.
I've started using the notify feature as a method of bookmarking them. That's how I'm able to quickly haul up the URLs in other posts.
I was saying to karma7 that we'd be coming up with comprehensive documentation for newbs/adepts/experts later on, but it looks like you're way ahead of us there :D
When I first saw the state of GPG usage here shortly after joining, I knew I had to.
I expect some people, like you and Kmf, will make copies of them and distribute them through other underground communities. Frankly I think that's a good thing.
Oh, and...
POST 1000!!
WOOT!!
Congratulations! :)
Now I feel that I deserve a cake with candles or something. You can even have a slice for the tutorials. Ohnomnomnomnom! Hmmmm. With this diet I have been thinking of little else than chocolate cake, truffles and jelly beans. It's like trying not to think of a pink elephant balloon. O_o
God damn it! Now you're making me hungry.
-
Louis, thanks so much for this and your command line tutorial, great stuff, and you present it really well.
I have a couple multi-distro machines that I want to share a common encrypted gpg installation instead of manually (and yes, stupidly) syncing each distros' .gnupg folder.
I've been putting that off too long, instead using gpa until I saw your posts, so I have no excuse to put it off any longer.
Thanks, man, I can't wait for more!
And Pine, wtf with mentioning chocolate cake on a stoner board?
Seriously, if it weren't for the fact that I am too high and cannot immediately locate my pants, I'd be in my car on the way to buying dangerous and embarrassing quantities of said cake.
Now I can only fantasize about it.
Thanks for that...
Damnit, people deliver pizza, why not cake?
-
Louis, thanks so much for this and your command line tutorial, great stuff, and you present it really well.
Thanks.
I have a couple multi-distro machines that I want to share a common encrypted gpg installation instead of manually (and yes, stupidly) syncing each distros' .gnupg folder.
I've been putting that off too long, instead using gpa until I saw your posts, so I have no excuse to put it off any longer.
You're better off exporting the public and secret keyrings and then importing them rather than syncing the full ~/.gnupg/ directories. Otherwise strange things can happen with the trust database and the like.
Thanks, man, I can't wait for more!
And Pine, wtf with mentioning chocolate cake on a stoner board?
Seriously, if it weren't for the fact that I am too high and cannot immediately locate my pants, I'd be in my car on the way to buying dangerous and embarrassing quantities of said cake.
Now I can only fantasize about it.
Thanks for that...
Heheh. :)
Damnit, people deliver pizza, why not cake?
That's a really good idea.
-
Damnit, people deliver pizza, why not cake?
Wow, I think that would really work. Emergency cake + 24 hour delivery. *sprints to the patent office*
The business from just our 'reefer madness' buddies alone! We'll be rich!
Tell you what, let's use SR to corner both ends of the market.. *diabolical laugh* :D
-
I have a couple multi-distro machines that I want to share a common encrypted gpg installation instead of manually (and yes, stupidly) syncing each distros' .gnupg folder.
I've been putting that off too long, instead using gpa until I saw your posts, so I have no excuse to put it off any longer.
You're better off exporting the public and secret keyrings and then importing them rather than syncing the full ~/.gnupg/ directories. Otherwise strange things can happen with the trust database and the like.
Thanks, I was worried that I would mess something up and send out the wrong key or something even worse.
Ideally I would love to share a Home directory amongst the machines, but that is another project.
[/quote]
Damnit, people deliver pizza, why not cake?
Wow, I think that would really work. Emergency cake + 24 hour delivery. *sprints to the patent office*
The business from just our 'reefer madness' buddies alone! We'll be rich!
Tell you what, let's use SR to corner both ends of the market.. *diabolical laugh* :D
...it worries me that I actually put significant thought into this.
I can imagine the "free samples" requests, and people getting scammed with Betty Crocker fakes sold as home made....
ok, enough.
-
I have a couple multi-distro machines that I want to share a common encrypted gpg installation instead of manually (and yes, stupidly) syncing each distros' .gnupg folder.
I've been putting that off too long, instead using gpa until I saw your posts, so I have no excuse to put it off any longer.
You're better off exporting the public and secret keyrings and then importing them rather than syncing the full ~/.gnupg/ directories. Otherwise strange things can happen with the trust database and the like.
Thanks, I was worried that I would mess something up and send out the wrong key or something even worse.
Ideally I would love to share a Home directory amongst the machines, but that is another project.
Yes and the solution is an NFS server.
-
Thanks, I found this useful.
Does GPG Keychain Access delete all the traces (hidden files, logs etc.) when deleting the keys in app? Or do I have to delete something manually?
Thanks
~Q~
-
Thanks, I found this useful.
Does GPG Keychain Access delete all the traces (hidden files, logs etc.) when deleting the keys in app? Or do I have to delete something manually?
Keys are only stored in the keyring files (pubring.gpg and secring.gpg), when a key is deleted the entire file is rewritten. You should not need to do anything manually.
-
Thanks, I found this useful.
Does GPG Keychain Access delete all the traces (hidden files, logs etc.) when deleting the keys in app? Or do I have to delete something manually?
Keys are only stored in the keyring files (pubring.gpg and secring.gpg), when a key is deleted the entire file is rewritten. You should not need to do anything manually.
Ok, thanks, I'm safe. My security level I – Mission Ready!. I still need to learn how to use VirtualMachine on USB or on TrueCrypted Partition. I Never managed to get Tails working on USB. Tails LiveCD is working, but I really hate to use it. My Macbook sounds like 2000W Vacuum cleaner when running it from a DVD
~Q~
~Q~
-
gpg (GnuPG) 1.4.12
Supported algorithms:
...
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
...
If anyone is wondered to see symmetric ciphers, here is why:
GnuPG employs a hybrid encryption scheme[1][2], using both asymmetric and symmetric encryption methods. Asymmetric encryption uses one key to lock the data, and another key to unlock it. Symmetric encryption utilizes the same key or password. A file that is password protected, is utilizing a symmetric security method, in that it is the same password to unlock or lock the file.
Note: It is also possible to encrypt files using only a symmetric cipher with gpg, the password itself will function as the key. You can encrypt the file using gpg's --symmetric argument:
gpg --symmetric doc2encrypt
GnuPG's hybrid encryption scheme works as follows. For every encrypted message sent, GnuPG generates a random session key. The actual data content is symmetrically encrypted using a symmetric cipher utilizing the random session key as the password to the cipher. The resultant is known as ciphertext. The actual session key is then asymmetrically encrypted using the public encryption key. Together the encrypted session key and the ciphertext is sent to the recipient. The recipient would use the private encryption key to decrypt the session key, which then in turn would be used to symmetrically decrypt the ciphertext into text. Because session key generation is modeled after the random number generator as described in Peter Gutmann's paper: "Software Generation of Practically Strong Random Numbers" [3] (I am remembering some chapters on "random" numbers in The Art of Computer Programming Too: "Chapter 3 - Random Numbers". Vol. 2: Seminumerical algorithms), forfeiting possession of a single session key would only compromise the contents of one single message, rather than all messages received by a particular user.
In PGP and GnuPG, the public-key cipher is probably the weaker of the pair. But it is not only the reason why GnuPG uses hybrid encryption. Public-key encryption and decryption are more expensive and, thus, slower, than the corresponding operations in symmetric systems.
Because the use of a secure symmetric cipher is paramount, GnuPG is very conservative in its choice of ciphers. It currently offers 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192 and CAMELLIA256 ciphers.
3DES is the default cipher as specified in the OpenGPG standard. It is computationally slow, however. AES - otherwise known as the Advanced Encryption Standard - employs a variant of the Rijndael -- pronounced "rain-doll" -- algorithm. The Rijndael algorithm was chosen as the AES by the National Institues of Standards and Technology (NIST) on Nov 26, 2001 after a 5 year standardization process. GnuPG defines the AES256 cipher as the default cipher.
A short overview:
- DES used to be standard many years ago, but it has only 56 bits, so it’s not at all secure these days. Triple DES is a straightforward way of increasing the key length by applying DES three times (with three independent keys). This gives a key length of 3×56=168, but because of a known possible attack, the security is, in practice, only 112 bits. If you want more security than that, you’ll need to use a different algorithm. Triple DES has no known security breaches, but it is computationally slow. It’s still the default algorithm in the OpenPGP standard, but not in GPG any more.
- CAST5 (a.k.a. CAST-128) is a symmetric algorithm with a key size between 40 and 128 bits; if you’re going to use it, go for 128 bits. In most Linux installations, it’s the current GPG default. At present, there is no known way of breaking it short of brute force, so its security is also 128 bits.
- Blowfish key length is between 32 bits and 448 bits, so you have a reasonable choice (32 bits is basically pretty useless). Unfortunately, it does need a fair bit of memory. Blowfish is similar in structure to CAST5. Twofish is a similar algorithm, with a longer block size and key length of up to 256 bits. Neither has been cryptographically broken, but security specialist Bruce Schneier recommends the use of Twofish over Blowfish.
- AES stands for Advanced Encryption Standard and is now the NIST technique of choice to replace DES (formerly the most often used standard). AES uses a 128-bit key, AES192 uses a 198-bit key, and AES256 uses a 256-bit key. Each of these also uses a slightly more complicated algorithm than its smaller relatives. Which of these to choose is a little complicated, and cryptographers disagree. There are attacks on AES-256 and AES-192 that don’t exist on AES-128, but they’re still considered “secure” because of the computational cost of those attacks (i.e., it’s not in practice feasible to break them).
- AES-128 is a bit faster than AES-256, so it might be a more practical option; AES-256 probably isn’t any weaker than AES-128. Keys of 128 bits are likely to be secure for somewhere between 10 and 50 years, depending on whom you ask. AES is now the official US government standard (128-bit for secret classified information, 192- or 256-bit for top secret).
- Other ciphers are also available (e.g., the CAMELLIA ciphers used as the Japanese encryption standard).
Taking public key and cipher together, for a decent balance between security and speed, AES (128 or 256) or CAST5 with RSA 2048 is your best bet (AES+RSA is recommended by NASA). Certainly, if you want long-term security, you shouldn’t go with an asymmetric key length of less than 2048 bits or a symmetric key length of less than 128 bits. For more security over the much longer term, but at a slight performance cost, choose a longer RSA key length (e.g., 4096 bits). [4]
1. https://en.wikipedia.org/wiki/Pretty_Good_Privacy
2. http://www.gnupg.org/gph/en/manual.html#AEN210
3. http://www.usenix.org/publications/library/proceedings/sec98/full_papers/gutmann/gutmann.pdf
4. http://www.linuxpromagazine.com/Online/Features/Protect-your-Documents-with-GPG/(offset)/4