“Someone should invent a machine to do that”

Lately, I find myself saying this a whole lot.

The conversations in which I’m saying this follow the pattern of these examples:

Me: “Let me understand your problem – tell me why you don’t want to have expiring passwords on this service account?”

Other guy: “Because when we change passwords, we’d have to change the password at the domain controller, then log on to each machine that runs the service, change the passwords, and stop and restart the service on those machines. Then we’d have to take note of which machines had issues with the process, so that we could work on troubleshooting those.”

Me: “Someone should invent a machine to do that … they could call it something like … a komputor. I’m sure they’d sell millions.”

Yes, it’s a little sarcastic when I put it that way, and for the most part that last piece is in my head. It usually comes out as “that could be done by a simple script”, or “can we justify the cost of buying one of the many programs out there that manages that entire process automatically?”

When you take a boring and mundane manual process and turn it into an automated process, whether through scripting or purpose-built applications, you significantly reduce the likelihood of error, and you can take your staff and turn them to other tasks that require human thought and are interesting.

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.