You’ve probably heard of public-key cryptography, because it’s the basis of HTTPS, the system that puts the padlock in your browser.
The mathematical detail behind public-key crypto is a little abstruse, but you don’t need to be a mathematician to understand the principles that make it work.
Here’s the story.
Traditional encryption (before 1970, at any rate) relies on the digital equivalent of a padlock. Turn the key clockwise to lock; turn the key anticlockwise to unlock.
If you want to share data securely with someone else, you have to make a duplicate of the key and send it to them. So you have to find a secure way of sharing the key first, typically with a face-to-face meeting, or through a trusted courier.
This is known as symmetric encryption, because you use the same key to encrypt and decrypt.
It doesn’t scale very well, and it doesn’t lend itself to online security, where you want a secure way of communicating with someone you’ve never met, and probably never will.
Public-key encryption (invented in the 1970s) relies on a funkier sort of padlock. You have two keys, either of which can be used for locking. But once the padlock is locked, only the other key can unlock it.
Choose one of the keys to be a public key, and let anyone who wants make a copy of it. Publish it online if you like.
Keep the other key private.
Now, anyone who wants to send you data securely simply locks it with their copy of your public key. Once it’s locked, no-one (not even the person who locked it) can open it, since the private key is needed for that purpose.
Originally, public-key cryptography was called non-secret encryption. That name was meant to denote that the public key didn’t need to be kept secret, so face-to-face meetings or trusted couriers were no longer needed for key exchange. But it’s not a very good name because it implies an overall lack of security.
It is now universally known as public-key encryption, or asymmetric encryption. It’s asymmetric because different keys are used to encrypt and decrypt.
You’ve probably realised that the key to public-key encryption, so to speak, is that only your public key is ever made public.
The secrecy of the system depends entirely on the secrecy of your private key, which is why it’s called a private key.
A surprising number of people, including many who should know better, don’t seem to realise that, which is why fellow Naked Security writer Julian Bhardwaj emailed me this morning with a mixture of amusement and alarm when he saw this tweet from Stackoverflow co-founder Jeff Atwood, better known as @codinghorror:
(Stackoverflow is a question-and answer-site for professional and enthusiast programmers; Github is a popular online source code repository for that same community.)
The link in the tweet, by the way, expands to a search URI something like this:
The search reveals cases where coders have generated a public/private key pair for secure communication with Github, and then uploaded the wrong key.
Whilst this search now returns no results (kudos to Github for a fast response), just over an hour ago it was returning 80 pages of people's private keys...perhaps time for a quick reminder about keeping private keys private?
If you are determined to produce your own key pairs, do yourself a favour and be watchful which one you give out and which one you keep. (The names public key and private key are supposed to make it easy to remember!)
Most key generation programs try to help you get it right by annotating the key files to make their content really obvious.
With SSH, for example, you use the ssh-keygen program, like this:
Your private key looks like this:
Or like this if you used a passphrase (you ought to, unless you plan use the key in an automated process when you won’t be around to type in the passphrase):
Your public key, which is the one you’re supposed to upload to Github, looks like this:
Things are much the same with SSL keys. Private keys are clearly labelled like this:
Or like this if they are passphrase-protected:
Public keys are similarly annotated. You don’t get passphrase-protected public keys (they’re supposed to be public, after all) so they all look something like this:
Not too tricky, is it?
For all the software you’re likely to use, such as OpenSSH, OpenSSL and GPG, private keys are labelled with the text PRIVATE KEY.
And that’s the one you’re supposed to keep private!
4 comments on “Do programmers understand the meaning of PRIVATE?”
Does this really surprise you? Right on the heels of the article about Kim DotCom's new site and how they published the private key right there in the source code (not to mention it was a ridiculously simple private key). Just more examples of security being an after thought rather than being baked into the system as a whole.
The Mega issue was that the coders were careless in their design. (They chose the wrong algorithm. They didn't actually need to use a keyed hash at all.)
The Github issue was that coders were careless about what they uploaded.
In the Github case, most or all of those who uploaded their private keys didn't do so instead of uploading their public keys. (They would have had to upload their public keys to get SSH to work in the first place.)
They probably just uploaded the entire directory tree of the account under which they'd been doing their coding, including directories that are usually hidden, like ~/.ssh, which is the default location for ssh-keygen to put your private key.
Goodness knows what other nuggets of oops-that-wasn't-supposed-to-be-included files you might find if you cared to look…on Github as well as many other cloudy repositories of stuff!!
This is the brave new world of the social web, remember:
“Privacy is dead; get over it.”
Add to the above quote: "Better to live off the grid."