Practically Goddamn Public
 
Support Ukraine

Practically Goddamn Public

Cryptography has fascinated me for a while. The promise of safely exchanging messages without anyone being able to listen in on the exchange has a bit of "secret society" over it, I guess. I'm no strager to cryptography - I've implemented a number of systems based on cryptographic hashes and protocols based on encryption. I'm also a regular user of the SSH protocol and assorted tools. I have, however, let my relationship with email cryptography remain at the level of distant admiration - until now. I worked up the courage required and downloaded Enigmail[a] and GnuPG[b]. I soon had both up and running, and had created a keypair for my email address. Sending an encrypted and signed email to myself via Gmail was no problem. Still, I don't think I'll be using this.

The Problems with Encryption Software

There are some downsides to the deployment of cryptographic software - mostly these are related to user frustration. Most technicians know about these:

  • ...just after a new password system that demands secure password of at least eight symbols, mixed case and numbers, is rolled out, users start to write their passwords on post-it notes that are fixed to their monitors.

  • ...the system administrator demands IPsec for certain connections. after three weeks of trying to set up an IPsec connection, the whole project is dropped and replaced with an unencrypted line.

Due to my being a lazy bastard the problems I had with Enigmail and GPG are basically the same ones. Let's take them in the order encountered...

My Keypair

Public-key crypto is dependent on each user having a private/public keypair. GPG will generate such a pair for you with a:

gpg --gen-key

So far so good, but the questions I have now are:

  1. Where did it put the newly-generated key? I find it quite annoying that I've just had this program spit out the single token that the security of the system revolves around and I don't even know where it went.

  2. What should I do with it now? Now that I've found the secring.gpg and pubring.gpg files (I hope that's all of them and that I'm no missing anything here) - what security permissions should I set for them? Absolutely nobody but me may access them, I suppose. But then, why didn't GPG put them in my home directory?

  3. What do I do if I lose it? Obviously I'm not supposed to run around giving my secret key to everyone, but suppose I get some trojan on my system, or my computer is stolen, or... What do I do now? Can anybody give me a checklist of things to do? I know that I'm supposed to call Visa if I lose my card, but who do I call when I lose my private key?

  4. What are the consequences of losing it? Suppose I've lost my secret key. I can maybe retrieve my public key from a keyserver, but what about data that people have encrypted with that key and sent to me? I would need the private key to decrypt that.

  5. How do I store it? There an inherent problem with the secret key. On one hand, I need it to decrypt everything I have encrypted with my private key, so I should really make sure that I don't lose the secret key. Making sure I don't lose a couple of thousand bytes that I will never be able to remember involves making several copies of those bytes - I should replicate the key as much as possible. But on the other hand I'm supposed to keep this key secret, so replicating it is a bad idea.

Other People's Keys

How do I manage my keyring? Keypairs, public keys, subkeys, revocation certificates, web of trust... I can't help but think that the time I spend trying to keep all these things straight far in excess outweigh any loss I would suffer if an attacker just eavesdropped on an unencrypted version of my email.

Peter Gutmann makes a case for PKI bringing much more cost than benefits to any organization in his presentation Everything you Never Wanted to Know about PKI but were Forced to Find Out[c], but I think he misses a very crucial point - namely that PKI tries to solve a problem that is in effect unsolvable.

The Need for Cryptography

When deploying any kind of tool one should ensure that the benefits derived from deploying it are greater than the cost in time and effort of deploying and using it: There's no point in deploying a $100 cryptosystem to secure a $10 transaction.