Archive

Archive for the ‘Encryption’ Category

Signing PGP keys

2014-06-21 2 comments

If you’ve recently completed a key signing party or have otherwise met up with other people and have exchanged key fingerprints and verified IDs, it’s now time to sign the keys you trust.  There are several different ways of completing this task and I’ll discuss two of them now.

caff

CA Fire and Forget (caff) is a program that allows you to sign a bunch of keys (like you might have after a key signing party) very quickly.  It also adds a level of security to the signing process by forcing the other person to verify that they have both control over the email address provided and the key you signed.  The way caff does this is by encrypting the signature in an email and sending it to the person.  The person who receives the message must also decrypt the message and apply the signature themselves.  Once they sync their key with the key server the new signatures will appear for everyone.

$ gpg --keyserver hkp://pool.sks-keyservers.net --refresh-key

There is some setup of caff that needs to be done prior but once you have it setup it’ll be good to go.

Installing caff

Installing caff is pretty easy although there might be a little trick.  In Fedora there isn’t a caff package.  Caff is actually in the pgp-tools package; other distros may have this named differently.

Using caff

Once you have caff installed and setup, you just need to tell caff what key IDs you would like to sign.  “man caff” will give you all the options but basically ‘caff -m no yes -u ‘ will sign all the keys listed after your key.  You will be asked to verify that you do want to sign the key and then caff will sign the key and mail it off.  The user will receive an email, per user id on the key, with instructions on importing the signature.

Signing a key with GnuPG

The other way of signing a PGP key is to use GnuPG.  Signing a key this way will simply add the signature to the key you have locally and then you’ll need to send those keys out to the key server.

Retrieving keys using GnuPG

The first thing that you have to do is pull the keys down from the keyserver.

$ gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys ...

Once you have received all the keys you can then sign them.  If someone’s key is not there you should probably contact them and ask them to add their key to the servers.  If they already have uploaded their key, it might take a couple of hours before it is sync’d everywhere.

Using GnuPG

Signing a key is pretty straightforward:

$ gpg --sign-key 1bb943db
pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC 
 trust: unknown validity: unknown
sub 4096g/672557E6 created: 2010-02-02 expires: never usage: E 
[ unknown] (1). MariaDB Package Signing Key <package-signing-key@mariadb.org>
[ unknown] (2) Daniel Bartholomew (Monty Program signing key) <dbart@askmonty.org>
Really sign all user IDs? (y/N) y
pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC 
 trust: unknown validity: unknown
 Primary key fingerprint: 1993 69E5 404B D5FC 7D2F E43B CBCB 082A 1BB9 43DB
MariaDB Package Signing Key <package-signing-key@mariadb.org>
 Daniel Bartholomew (Monty Program signing key) <dbart@askmonty.org>
Are you sure that you want to sign this key with your
key "Eric Harlan Christensen <eric@christensenplace.us>" (024BB3D1)
Really sign? (y/N) y

In the example I signed the MariaDB key with my key.  Once that is complete a simple:

gpg --keyserver hkp://pool.sks-keyservers.net --send-key 1BB943DB

…will send the new signature to the key servers.

Categories: Integrity, OpenPGP

PGP Keysigning Event and CACert Assertion at SELF2014

2014-06-16 Leave a comment

SouthEast LinuxFest is happening this upcoming weekend.  I offered to host a PGP (I’ll substitute PGP for GPG, GnuPG, and other iterations) keysigning and CACert Assertion event and have been scheduled for 6:30 PM in the Red Hat Ballroom.  Since there is a little bit of planning needed on the part of the participant I’m writing this to help the event run smoothly.

Participating in the PGP Keysigning Event

If you haven’t already, generate your PGP keys.  Setting up your particular mail client (MUA) is more than what I’ll discuss here but there is plenty of resources on the Internet.  Send me (eric@christensenplace.us – signed, preferably encrypted to 0x024BB3D1) the fingerprint of your PGP key no later than 3:00PM on Saturday afternoon.  If you don’t send me your fingerprint by that time you’ll be responsible for providing it to everyone at the keysigning event on paper.  Obtaining your key’s fingerprint can be done as follows:

$ gpg --fingerprint 024bb3d1
pub 4096R/024BB3D1 2011-08-11 [expires: 2015-01-01]
 Key fingerprint = 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
uid Eric Harlan Christensen <eric@christensenplace.us>
uid Eric "Sparks" Christensen <sparks@redhat.com>
uid Eric "Sparks" Christensen <echriste@redhat.com>
uid Eric "Sparks" Christensen <sparks@fedoraproject.org>
uid [jpeg image of size 2103]
uid Eric Harlan Christensen <sparks@gnupg.net>
sub 3072R/DCA167D5 2013-02-03 [expires: 2023-02-01]
sub 3072R/A9D8262F 2013-02-03 [expires: 2023-02-01]
sub 3072R/56EA1030 2013-02-03 [expires: 2023-02-01]

Just send me the “Key fingerprint” portion and your primary UID (name and email address) and I’ll include it on everyone’s handout.  You’ll need to bring your key fingerprint on paper for yourself to verify that what I’ve written on the paper is, indeed, correct.

At the event we’ll quickly do a read of all the key fingerprints and validate them as correct.  Then we’ll line up and do the ID check.  Be sure you bring a photo ID with you so that we can validate who you are with who you claim to be to the authorities.  People are generally okay with a driver’s license; some prefer a passport.  Ultimately it’s up to the individual what they will trust.

CACert Assertion

CACert is a free certificate authority that signs X509 certificates for use in servers, email clients, and code signing.  If you are interested in using CACert you need to go sign up for an account before the event.  Once you have established an account, login and select “US – WoT Form” from the CAP Forms on the right-side of the page.  Print a few of these forms and bring them with you (I hope to have a final count of the number of assurers that will be available but you’ll need one form per assurer).  You’ll need to present your ID to the assurer so they can verify who you are.  They will then award you points in the CACert system.

Questions?

If you have any questions about the event feel free to ask them here (using a comment) or email me at eric@christensenplace.us.

Generating a PGP key using GnuPG

2014-06-16 3 comments

Generating a PGP using GnuPG (GPG) is quite simple.  The following shows my recommendations for generating a PGP key today.

$ gpg --gen-key 
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
 (1) RSA and RSA (default)
 (2) DSA and Elgamal
 (3) DSA (sign only)
 (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 3072
Requested keysize is 3072 bits
Please specify how long the key should be valid.
 0 = key does not expire
  = key expires in n days
 w = key expires in n weeks
 m = key expires in n months
 y = key expires in n years
Key is valid for? (0) 1y
Key expires at Tue 16 Jun 2015 10:32:06 AM EDT
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
 "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Given Surname
Email address: given.surname@example.com
Comment: Example
You selected this USER-ID:
 "Given Surname (Example) <given.surname@example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..........+++++
.....+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
....+++++
gpg: key 2CFA0010 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 49 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 49 signed: 60 trust: 48-, 0q, 0n, 0m, 1f, 0u
gpg: depth: 2 valid: 8 signed: 17 trust: 8-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-09-09
pub 3072R/2CFA0010 2014-06-16 [expires: 2015-06-16]
 Key fingerprint = F81D 16F8 3750 307C D090 4DC1 4D05 E6EF 2CFA 0010
uid Given Surname (Example) <given.surname@example.com>
sub 3072R/48083419 2014-06-16 [expires: 2015-06-16]

The above shows the complete exchange between GPG and myself.  I’ll point out a couple of selections I made and explain why I made those choices.

Key type selection

I selected the default selection of two RSA keys.  The keys used for signing and encryption will both be RSA which is strong right now.  DSA has been proven to be weak in certain instances and should be avoided in this context.  I have no comment on ElGamal as I’ve not done research here.  Ultimately the choice is up to you.

Bit strength

I’ve selected 3072 instead of the default 2048 here.  I recommend this as the minimum bit strength as this provides 128 bits of security as compared to 112 bits of security with 2048.  128 bits of security should be secure beyond 2031 as per NIST SP 800-57, Part 1, Rev 3.

Key expiration

By default, I make my keys expire after a year.  This is a fail-safe and can be later modified before the expiration to extend the expiration another year.  This makes sure the key will self destruct if you ever lose control of it.

Identifying information

You’ll  now be asked to add your name and email address.  This should be self-explanatory.

Key revocation

Once you have completed your key generation now is the time to generate the key revocation file.  If you ever lose control of your key you should immediately upload this file to the public key servers so everyone using your key will know that it has [potentially] been compromised.  Once you’ve generated this revocation just keep it somewhere safe.  You can even print it out and keep it locked up somewhere.  It’s important to do this this ahead of time as you may not be able to do this later.  You’ll obviously want to substitute your own keyid for 2CFA0010.

$ gpg --gen-revoke 2CFA0010
sec 3072R/2CFA0010 2014-06-16 Given Surname (Example) <given.surname@example.com>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
 0 = No reason specified
 1 = Key has been compromised
 2 = Key is superseded
 3 = Key is no longer used
 Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> 
Reason for revocation: Key has been compromised
(No description given)
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "Given Surname (Example) <given.surname@example.com>"
3072-bit RSA key, ID 2CFA0010, created 2014-06-16
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1
Comment: A revocation certificate should follow
iQGfBCABAgAJBQJTnwtaAh0CAAoJEE0F5u8s+gAQHMQMANH1JG5gVDnp5NY4o8ji
3j6GljQ9ieY+u3c5q0c08/uSAqGvL9jmPn1QAnikAkIJGy9kNmBJ/uC6pSMcHeCW
/vYWMD/cToy63tgLOf4A8GgX2k8ttFe+DpFFSt43zbGVowykZ5AHwKImtyFwVO7M
IKQZV21uFcIDl7jb5GkymkpWRZmIrexOyIAQjpyYWQT4BFFnI7kwpYyVbmodkwE/
JaC0d5dMVT9DRLr5FGuGSpzYJEeB14GCjT2EQ1js/Bji2fguFqpzM5z77FdzhS7s
SNGgY8bioyjUN3CsyHMfPpkJi9mBDCV4gTxyLlVOdDiSdqA56mzjvrx3tnltfjyN
kFJfPDWLqXFNpzX516oOo37b3P92bSEPcIgGeTL58nVUn/BWMsoDlIbwNyjxx7Tq
YYXa2T2rbH1JHndOrmAc9X98cNrhs+vppV6SBev2MnvqobT2nqW7hKeNvwIyqunF
79fL9En2p57pQ8vH4EeRhjFSciuZZBpCEv2cMIDQGMFKVQ==
=6ljf
-----END PGP PUBLIC KEY BLOCK-----

Proper key storage

Generally speaking, your private PGP key is stored on your computer encrypted.  It is protected by your normal security measures of your computer and whatever password you set.  There is a better way.  Use a hardware security module (HSM) like a Yubikey Neo, OpenPGP card, or CryptoStick to protect  your private key from disclosure.

Publishing your public key

Now that you have your PGP keys you’ll want to publish your public key to the key servers so others can easily obtain it to validate your signatures.

$ gpg  --keyserver hkps://hkps.pool.sks-keyservers.net --send-keys 2CFA0010

You’ll obviously want to substitute your own keyid for 2CFA0010.  This command will send your key to the SKS public key servers which will then replicate your key around the world in a few hours.

 

SSL/TLS Trends

2014-05-20 1 comment

My friend Hubert has started compiling statistics of Alexa’s top 1 million websites.  Specifically, he’s looking at their SSL/TLS settings and attempting to show trends in the world that is port 443.  He recently released his May numbers showing a slow but mostly improving security environment.  I’m hoping he’ll be able to chart these trends in a way to make it easier for people to consume the data and be able to dynamically look for data that they are interested in.  I guess we’ll have to wait and see what come about.  Until then I believe he’ll continue to post his monthly numbers on the Fedora Security List.

STARTTLS for SMTP

2014-05-15 10 comments

Okay, I don’t really mean to advocate this as a privacy solution because it is and it isn’t.  If you truly want privacy of your email you must use end-to-end encryption like PGP/GnuPG or S/MIME.  That said, I think it’s good to encrypt things, even ciphertext, over the network.  So STARTTLS for SMTP is a good start.

What, exactly, is STARTTLS?  Well, it’s an opportunistic protocol that goes out and asks a server in which I want to talk with if it supports encryption.  If it does then we negotiate the terms (ciphers, keys, certs) and then we establish a circuit and exchange the information.  If it doesn’t support encryption I just skip the setup of the encrypted circuit and transmit the data in the clear.  Yeah, not a great solution and I really hate the thought of STARTTLS as it isn’t a guarantee that the data transferred will be encrypted (unlike, say, HTTPS).

Earlier today Kurt pointed me at a study done by Facebook.  Yeah, everyone knows I hate FB but really they are in a great position to do such a study.  According to their study, “Facebook sends several billion emails to several million domains every day”.  Okay, that’s a lot of email.  And with that amount of exposure to the worlds’ SMTP servers I’m guessing they’ve hit most of the servers out there.  Turns out 76% of those servers support STARTTLS and most actually use a good cipher suite and PFS.  Unfortunately it appears that most mail is routed to providers that aren’t supporting good crypto suites.  The report doesn’t name them so I figured I’d go out and see if I could find some of the deficient setups.

The obvious first choice was Google’s Gmail.  As long as the incoming server connects to port 465 587* they should get an encrypted circuit supporting TLSv1.2 protocol with a cipher of ECDHE-RSA-AES128-GCM-SHA256.  Great, I have no complaints here.  Hmmm, so who is next?  I guess Hotmail is still a biggie and Microsoft does have all those B2B services as well.  It seems TLSv1.2 with a cipher of ECDHE-RSA-AES256-SHA384 is being used on at least some of their SMTP servers.  What’s next?  Ahh, yes, Yahoo! is still in business (although I seriously don’t know how).  Yahoo! just implemented encrypted connections for their webmail users so clearly they should have fixed their backend connections as well, correct?  Well, they are the first to make my bad list by using the TLSv1 protocol with the cipher of RC4-SHA.  Come on guys, get it together!  Let me see what my provider, Bluehost, is doing here.  It appears that, like Google, they support TLSv1.2 and are using the cipher of DHE-RSA-AES256-GCM-SHA384.  Again, a great choice (although the AES256 is a bit much but that’s a different post all together).

I might, one day, setup a scanner to more thoroughly collect this data and make it available in more real-time but for now I think the Facebook data is awesome and quite timely.

 

*As was pointed out in the comments port 587 is a user port and is used for authenticated SMTP access from clients.  Once the SMTP server has the message to be delivered the server will connect over to the distant SMTP server over port 25 unauthenticated.  Port 25 can be just plaintext or can use STARTTLS.  As an aside, why port 25 outbound (and inbound?) is blocked for many residential customers is because it is unauthenticated and a present a good entry point for spam.

Categories: Encryption, Privacy Tags: , , ,

256 Bits of Security

2014-04-17 3 comments

This is an incomplete discussion of SSL/TLS authentication and encryption.  This post only goes into RSA and does not discuss DHE, PFS, elliptical, or other mechanisms.

In a previous post I created an 15,360-bit RSA key and timed how long it took to create the key.  Some may have thought that was some sort of stunt to check processor speed.  I mean, who needs an RSA key of such strength?  Well, it turns out that if you actually need 256 bits of security then you’ll actually need an RSA key of this size.

According to NIST (SP 800-57, Part 1, Rev 3), to achieve 256 bits of security you need an RSA key of at least 15,360 bits to protect the symmetric 256-bit cipher that’s being used to secure the communications (SSL/TLS).  So what does the new industry-standard RSA key size of 2048 bits buy you?  According to the same document that 2048-bit key buys you 112 bits of security.  Increasing the bit strength to 3072 will bring you up to the 128 bits that most people expect to be the minimum protection.  And this is assuming that the certificate and the certificate chain are all signed using a SHA-2 algorithm (SHA-1 only gets you 80 60 bits of security when used for digital signatures and hashes).

So what does this mean for those websites running AES-256 or CAMELLIA-256 ciphers?  They are likely wasting processor cycles and not adding to the overall security of the circuit.  I’ll make two examples of TLS implementations in the wild.

First, we’ll look at wordpress.com.  This website is protected using a 2048-bit RSA certificate, signed using SHA256, and using AES-128 cipher.  This represents 112 bits of security because of the limitation of the 2048-bit key.  The certificate is properly chained back to the GoDaddy CA which has a root and intermediate certificates that are all 2048 bits and signed using SHA-256.  Even though there is a reduced security when using the 2048-bit key, it’s likely more efficient to use the AES-128 cipher than any other due to chip accelerations that are typically found in computers now days.

Next we’ll look at one of my domains: christensenplace.us.  This website is protected using a 2048-bit RSA certifcate, signed using SHA-1, and using CAMELLIA-256 cipher.  This represents 80 60 bits of security due to the limitation of the SHA-1 signature used on the certificate and the CA and intermediate certificates from AddTrust and COMODO CA.  My hosting company uses both the RC4 cipher and the CAMELLIA-256 cipher.  In this case the CAMELLIA-256 cipher is a waste of processor since the certificates used aren’t nearly strong enough to support such encryption.  I block RC4 in my browser as RC4 is no longer recommended to protect anything.  I’m not really sure exactly how much security you’ll get from using RC4 but I suspect it’s less than SHA-1.

So what to do?  Well, if system administrators are concerned with performance then using a 128-bit cipher (like AES-128) is a good idea.  For those that are concerned with security, using a 3072-bit RSA key (at a minimum) will give you 128 bits of security.  If you feel you need more bits of security than 128 then generating a solid, large RSA key is the first step.  Deciding how many bits of security you need all depends on how long you want the information to be secure.  But that’s a post for another day.

Time to generate a 15,360-bit RSA key

2014-04-15 9 comments

$ time openssl genrsa 15360
Generating RSA private key, 15360 bit long modulus

<magic happens>

real    2m39.541s
user    2m39.236s
sys    0m0.006s

Categories: Encryption Tags:
Follow

Get every new post delivered to your Inbox.

Join 223 other followers