Archive

Archive for the ‘GnuPG’ Category

caff gpg.conf file settings

2014-04-01 1 comment

After years of using caff for my PGP key-signing needs I finally come across the answer to a question I’ve had since the beginning.  I document it here so that I may keep my sanity next time I go searching for the information.

My question was “how do you make a specific certification in a signature?”.  As defined in RFC 1991, section 6.2.1, the four types of certifications are:

     <10> - public key packet and user ID packet, generic certification
          ("I think this key was created by this user, but I won't say
          how sure I am")
     <11> - public key packet and user ID packet, persona certification
          ("This key was created by someone who has told me that he is
          this user") (#)
     <12> - public key packet and user ID packet, casual certification
          ("This key was created by someone who I believe, after casual
          verification, to be this user")  (#)
     <13> - public key packet and user ID packet, positive certification
          ("This key was created by someone who I believe, after
          heavy-duty identification such as picture ID, to be this
          user")  (#)

Generally speaking, the default settings in caff only provide the first level “generic” certification. Tonight I found information specific to ~/.caff/gnupghome/gpg.conf. This file can contain, as far as I know, can contain three lines:

personal-digest-preferences SHA256
cert-digest-algo SHA256
default-cert-level 2

I can’t find any official information on this file as the man pages are a little slim on details.  That said, if you use caff you should definitely create this file and populate it with the above at a minimum with the exception of the default-cert-level.  The default-cert-level should be whatever you feel comfortable setting this as.  My default is “2″ for key signing parties (after I’ve inspected an “official” identification card and/or passport).  The other two settings are important as they provide assurances of using a decent SHA-2 hash instead of the default

Gemalto USB Shell Token bit the dust… Now what?

2013-09-01 1 comment

I went to sign an outgoing message tonight and my Gemalto USB Shell Token wouldn’t light up when I plugged it into my USB port.  After doing the typical troubleshooting I am left with the thought that the device has given up the ghost.  This isn’t a big problem because I saved the card the SIM came out of and I’m able to use my token on my personal laptop with a traditional card reader.  My work computer, however, does not have one of these fancy card readers (maybe I can find my USB one somewhere?).

I can buy another Gemalto device but I’m wondering if there is a better device to use?  I mean, the Gemalto lasted almost 500 signatures.  But I guess I can now take advantage of the failure to try something else.  Does anyone have any suggestions?

Secure GnuPG configuration

2013-07-09 3 comments

Someone recently asked what my GPG.conf file looks like since he hadn’t updated his in… years.  Okay, let’s take a look and I’ll try to explain what each setting is and why I feel it is important.  I’m not guaranteeing this as being complete and I welcome input from others.

keyserver-options auto-key-retrieve

This says that if a program needs a public key but it’s not in my keyring that it should automatically reach out to the keyserver (see below) and download it.

use-agent

This says to use the GPG agent. I cannot remember, right now, why this was a good idea. Perhaps it isn’t?

auto-key-locate cert pka ldap hkps://hkps.pool.sks-keyservers.net
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem
keyserver-options no-honor-keyserver-url
keyserver-options auto-key-retrieve

Almost the fun stuff there.  This is just setting up the keyserver that I wish to use (note the use of hkps instead of hkp).

default-preference-list AES AES192 AES256 TWOFISH SHA1 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2
personal-cipher-preferences AES256 TWOFISH AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
personal-compress-preferences BZIP2 ZLIB ZIP

Okay, the fun stuff. These are all the algorithms that I wish to use. If you setup your GPG key to advertise these then it will make it easier for others to use the most secure algorithms since they will already know what you can do. The first line just lists all the preferences. The second, third, and fourth lines actually provide the preferences in order of them being used. If you’ll note my preferred cipher is AES with a 256-bit key and my preferred hash (digest) is SHA with a 512-bit key.  There are other options available and a quick

gpg --help

should provide what options are available to you. For instance, my current installation says that its supported algorithms are:

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

I’ve omitted 3DES, MD5, and SHA1 from my preferences due to their weaknesses but I could still use them according to my GnuPG software.

Again, this wasn’t meant to be a strict “thou must do this to be secure” but rather a “this is what I’m doing” sort of thing. I’d appreciate feedback!

Inadvertant data leakage from GnuPG

2013-07-01 10 comments

I was recently introduced to a privacy issue when refreshing your OpenPGP keys using GnuPG.  When refreshing your public key ring using a public key server GnuPG will generally use the OpenPGP HTTP Key Protocol (HKP) to synchronize keys.  The problem is that when you do refresh your keys using HKP everyone that you maintain in your public key ring is sent across the Internet unencrypted.  This can allow anyone monitoring your network traffic to receive a complete list of contacts in which you may hope to use OpenPGP.

The fix is quite simple: in your gpg.conf file make sure that your keyserver entries include hkps:// instead of hkp://.  This will force GnuPG to wrap HKP in SSL to keep the key exchange private.

Happy encrypting!

Categories: Encryption, GnuPG, OpenPGP, Privacy Tags: , , , , ,

Poll Results: Do you use OpenPGP or GnuPG?

2013-03-07 2 comments

So this poll is a bit stale but the information is interesting nonetheless.

So what do these poll results mean, exactly?  Well, scientifically not much.  I mean, I guess we could make some sort of scientific bearing here.  Let’s try:

So of the people responding to the completely voluntary poll on this not-so-well-read blog and felt the need to respond, a vast majority have setup OpenPGP or GnuPG and over half use it on at least a semi-regular basis.  That’s encouraging, really, that of the 72 respondents, 42 of you use your keys somewhat regularly and are protecting yourself.

I wonder about the 10 people that responded that you have keys but never use them.  Why is this?  You’ve come so far to not use the technology that’s been provided!

So this was fun.  Perhaps I’ll find another question to ask where I won’t forget that I asked it.

Categories: GnuPG, OpenPGP, Poll

Hashing Algorithm: Is your GPG configuration secure?

2013-02-21 3 comments

If your email messages are being signed using SHA-1 you may not be getting the security you think you are.  Attacks on the hashing algorithm have caused much pain to those that use it.  Luckily SHA-2 is available and hopefully we’ll start seeing SHA-3 out in the world soon.

You’ve probably already seen SHA-2 in the wild designated as SHA-224, SHA-256, SHA-384, and SHA-512.  Because of the weaknesses found in SHA-1 it’s important to not use that algorithm any longer.  That means when you generate hashes you shouldn’t use sha1sum but rather one of the SHA-2 tools: sha224sum, sha256sum, sha384sum, or sha512sum.  Depending on the length of time you need to protect the data the strength of the hash will be important.  A larger key will be more secure for a longer period of time than a shorter one.

GNU Privacy Guard (GPG) has a default of using SHA-1, however, unless you manually select another algorithm in your gpg.conf file (usually found in ~/.gnupg).  To use something other than the default you should add the following lines:

personal-cipher-preferences AES256 TWOFISH AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP

These lines establish not only the preferences for which algorithms to use (for cipher, digest (hashing), and compression) but also in what order to use them.  You can determine what algorithms are available to you by asking GPG in the command line:

$ gpg --version
...
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

GPG will show specifically what is supported based on what’s built into the code when the package was built.

Using the proper algorithm is important for maintaining a secure communications environment so do your research and use something  in which you feel comfortable.

My web of trust

2013-01-26 Leave a comment
Web of Trust built on 26 Jan 2013

Web of Trust – 26 Jan 2013

I created my web of trust graphic (select the graphic to zoom in to see detail) this morning showing the additions from the key-signing event at FUDCon Lawrence.  I’m also working on building the Fedora web of trust and I may do one for Red Hat as well.

If you’d like to create your own web of trust graphic you can follow the instructions on Aaron Toponce’s website.

Categories: GnuPG, OpenPGP Tags: ,

New year, updated keys.

2012-01-03 Leave a comment

GnuPG LogoI run a SKS key server and watch my daily numbers to see how many keys get updated, etc.  Being a numbers guy I wondered how many people, like me, update their GPG keys, I specifically update the expiration date and generate new encryption keys annually, at the beginning of the new year.  Apparently I’m not alone:

Daily Histogram

Time New Keys Updated Keys
2012-01-02 266 210
2012-01-01 251 6422
2011-12-31 191 99
2011-12-30 287 133
2011-12-29 326 112
2011-12-28 297 154
2011-12-27 290 133
2011-12-26 248 84
2011-12-25 146 55
2011-12-24 157 81
2011-12-23 216 99
2011-12-22 330 152
2011-12-21 326 146

Specifically these keys were updated at 1700Z.  I’m not sure I have the ability to see which keys were updated but I’d love to know how that happened.

Categories: GnuPG Tags:

FUDCon Blacksburg PGP Key Signing Event

2011-12-19 Leave a comment

If you are planning on attending the FUDCon Blacksburg PGP (GnuPG) Key Signing Event please go to the event page and sign up now.  Additional instructions will be sent to you as we get closer to the event date.

Also, Nick (nb) is planning a CAcert Assurance event as well (probably will co-exist with the PGP key signing).

Hope to see everyone there!

Fedora Web of Trust keysigning at FUDcon Pune

2011-11-01 Leave a comment

I, unfortunately, will not be in attendance to join this event but I did want help advertise this event.  While the Fedora Web of Trust (WoT) is getting its act together you can start participating immediately!  FUDcon Pune is hosting a keysigning event on 05 November 2011.  If you are available please go and get your key signed and sign other people’s keys so the trust can build.

Hope everyone has a great time in Pune!

Follow

Get every new post delivered to your Inbox.

Join 202 other followers