Ten key truths

In the spirit of "ten unavoidable security truths", and numerous other top-ten lists, here’s a list of ten key truths that apply to public / private key pairs:

  1. Your private key has to be private to you. It cannot be created by anyone else.
  2. Anyone who has your private key is you, for the purposes to which that key is applied.
  3. If you have a private key that was generated by your employer, then that key identifies you as a part of the employer. It cannot be used to uniquely identify you, because the key was generated under your employer’s control.
  4. Keys associated with expired or revoked certificates are not always useless – you can use them to decrypt a file that they encrypted a long time ago; you can also verify the time-stamped signature of a document, if the certificate was valid at the time of the signature.
  5. A key is a number – it cannot expire, it is the associated certificate that expires. Similarly, the certificate, not the key, is what is revoked after exposure.
  6. A key is not a certificate. A certificate is a statement (usually of ownership) about a key pair, and contains the public key.
  7. Too short of a key is no key at all, and an exposed private key is no key at all.
  8. Protecting a password or key by encrypting it may do nothing more than extend the problem by a level – now you have to protect the key used to encrypt the password / key.
  9. Revocation of a certificate applies only to trusting parties who actually bother to check for revocation.
  10. A key derived from a password has the same strength as the password, no matter how long the key.

Note that this list describes what happens when cryptography is working perfectly. There are other key facts that apply to broken cryptography and broken process:

  1. You cannot increase entropy by repeating bits, or by padding with constant or predictable values.
  2. If someone creates a private key for you, they can become you using that key.
  3. Protecting anything by using a password or key to feed a yes/no gate requires the attacker to only fool the yes/no gate. Encrypted USB drive manufacturers found this out recently to their embarrassment.
  4. Inventing your own crypto – or the processes around it – is always a bad idea. Research others’ ideas and use them, particularly published standards.
  5. Even the longest strongest key in the world can be defeated by a big enough bribe to the key-holder.
    1. If the price of a card number on the black market is $1, then access to a million card numbers is equivalent to a million dollars. Who do you pay well enough that they can ignore that value?
  6. A key or password that is never updated as it passes through many hands is vulnerable to abuse by each of those hands.
  7. Broken cryptographic algorithms cannot be made better by increasing the length of the key or by applying the algorithm more times.
  8. All cryptographic algorithms become broken in time. The trick is to choose one that lasts longer than your need to protect your data.
  9. When you lose the private key through insufficient key management, you have lost the data it protected.
  10. Even a good cryptographic algorithm can be destroyed by a poor key-generation algorithm.

Note that these lists are rather arbitrarily scoped to ten – there may be more important truths I’ve forgotten, or items I’ve included that aren’t really so important.

2 thoughts on “Ten key truths”

  1. A nuance you’re leaving out of the password strength == key strength equation is the work factor involved in testing the password. The whole point of cryptography is to hold off the attacker for long enough that the information loses value. A password that will do this when it can be attacked with 1000 cracks/sec can be substantially weaker than a password that has to hold up to 1M cracks/sec. This is why it is always advisable to use a good KDF and a high spin count. I’m sure you don’t mean to imply that someone should just feed the password in as the key, but someone might take this last item that way, which would be a mistake.

    Another nuance is that there’s a difference between a broken algorithm and what’s currently an acceptable key length – for example a 2048 bit RSA key is just fine, 768 bit, not so much…

  2. You’re right – there’s a number of subtle nuances missed out here. Second list, item 9, for instance, needs to be fleshed out with “and that is a good thing”.
    That should, of course, be a lesson to the reader – any “top ten list” or check-list is only a guide. There’s more to security in particular, or life in general, than simply applying by rote a sequence of actions.
    Knowing the rules, and understanding their cause, is essential to knowing when the rules should be broken, and how to do so most effectively.
    One of my favourite “when to break the rules” is “when you should say ‘these keys don’t need to be managed” – there are many cases in which it’s cheaper to re-create the data under protection than it is to maintain key management.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>