Security notes / public key encryption notes
| Security related stuff.
What you can do
Public key encryption is named for its asymmetric key scheme: you have two keys, a public one and a private one. Everyone should be able to get hold of anyone's public keys, while no one but you should ever have your private key. Implied in cryptosystems of this sort is that it is nearly impossible to derive the private key from the public key. (...but be careful when storing private keys on public/networked systems. It is technically better to carry it around on a usb stick or the likes)
You can generally do two things:
- Sign documents so that other people can verify it came from you. (When you encrypt something with a public key, only someeone with the according private key can decrypt it)
- Encrypt documents so that only the single person you send it to can decrypt them. (When you sign something with a private key, (only) someone with the according public key can verify it was signed with that private key)
Using the other side's public key, you encode the message to something unreadable without their private key. This is used for secure communication, in mail as well as secure channels such as SSL / TLS.
An analogy (for encrypting only) is that a person hands out open padlocks (their public key) that anyone can close on a box with a message, but that only the person with the padlock's key (the private key) can open.
Using your own private key, signing adds signature data to message that the other side can verify comes from you, using the public key they have for you:
'Using your public key, other people can decode and thereby verify a message was signed by you/your private key. (...by the same identity: each identity has an inseperable private key and public key).
In the end, the largest weakness is probably making sure keys actually belong to the someone you think you're talking to. Since there may be a man in the middle attack going on -- a person talking to both of you, pretending to be the other and essentially securing channels from both to this middle -- you need to compare keys before you can safely use them (though, arguably, only if you suspect someone would bother man-in-the-middling you). For personal use where you just use encryption so that your messages aren't easily snooped from the physical network, this isn't so pressing.
Key fingerprints help here. They are a hash of the key, meaning a smaller set of characters, which you should be able to compare within a minute or so by looking it up on a website or calling the owner. Technically, the more such media you use the better, as a man in the middle will be hard pressed to consistently fool them all.
Secure shell (SSH) uses this system and warns when the server's key (fingerprint) has changed. Whenever SSH is newly installed, it warns, which I've so far mostly blindly clicked past.
Side note: Asymmetric v.s. symmetric keys
Earlier, simpler systems had symmetric keys, meaning that the encoding and decoding key was the same. This only allows encrypting between mutually trustable parties that you assume will not accidentally or purposefully leak the key, because that key means all possible abilities, most importantly reading encrypted data and imitating the other side data.
Additionally, sending predictable data over these encrypted channels made it easy to deduct the key when encryption was very simplistic. (eg. XOR-ing a n-byte key with every n-sized block of data. Because most files start with very predictable data, this can give much of the key away without much trouble at all)
The public-private key system's additional security is based on the fact that given the public key of someone's (public,private) keypair it is nearly impossible to calculate the private one, which is why it isn't a problem to hand the public ones out.