sundialsvcs gave a very good description, but I think was on a different wavelength. I know a little about RSA encryption and digital certification is an extention of this. If you're really interested, I suggest rummaging around a university websites for course notes on "Computer Security and Cryptography" - I did a whole module on it fairly recently (I've graduated now \o/ ) and it was quite well explained. I suspect I can fish out some of my lecture notes if you wanted to have a read through, although it's skimmed through pretty fast.
Because it's so fundamental, I want to make clear now that both keys (public and private) are one-way. You cannot use the same key in a pair to decrypt a message that has been encrypted by that same key. This is why giving out a public key is so secure, it can't be used to decrypt a message encrypted with itself.
I don't want to go into detail about the maths behind it all (it gives me a headache), but for simplicity, I will be "combining" things like this: XY = Z. To reiterate: it is not a mathematical computation, it merely says: "do somethingt to X based on Y to obtain an output of Z".
To show the trap-door nature of the public/private key pair:
Public key = Kpublic
Private key = Kprivate
Message = M
Encrypted message = Mencrypt
Two valid examples:
1. Kpublic M = Mencrypt ---> Kprivate Mencrypt = M
2. Kprivate M = Mencrypt ---> Kpublic Mencrypt = M
NOT VALID!:
Kpublic M = Mencrypt --->Kpublic Mencrypt = M <--- you cannot do this if Kpublic was used to encrypt M!
So, with some specific examples, first of all let's get our people sorted out:
User A (maginotjr) has 2 keys: Apublic and Aprivate (public and private keys, respectively)
User B (sundialsvcs) has 2 keys: Bpublic and Bprivate (public and private keys, respectively)
maginotjr (user A) wants to send a secret message to sundialsvcs (user B). Let us assume they do not know each other; so the first step is to exchange public keys.
Public keys are so-called because they can be left in the public domain without fear of people cracking your messages.
Now that user A has given user B his public key (and vice versa, for simplicity), maginotjr (user A) can send sundialsvcs (user B) an encrypted message.
So User A takes our message M, and encrypts it using B's public key: Bpublic M = Mencrypted
Mencrypted is then sent in plain text to user B.
Since user B has the private key, he can decrypt Mencrypted like this: Mencrypted Bprivate = M
Sundialsvcs reads the message and is overjoyed that maginotjr can make it to his party =D
But wait! It could be a trap! Sundialsvcs doesn't know who that message is from - only that it has maginotjr's name at the end of it. It could be from anybody, since sundialsvcs has published his public key (Bpublic) on his website, so people can contact him securely.
So how can you be sure who a message is from *and* have it sent securely?
You sign the message using a digital signature!
So, User A writes a message M and takes a digest of it. A message digest is basically a sophisticated hash function.
Now the digest (Mdigest) is encrypted using User A's PRIVATE key to generate a message signature:
Aprivate Mdigest-sent = Asignature
The signature can now be sent along with the original message to prove who it came from. How? Well, the receiver (User B) gets an email that has 2 parts: the message and the signature.
He decodes the signature like this: Apublic Asignature = Mdigest-sent
And also recreates the message digest himself: Mdigest-check
He then compares the two digests. If they differ, the message has been tampered with and cannot be trusted. Sundialsvcs now knows that maginotjr must have sent that message, because only maginotjr's public key would be able to decrypt a message encrpyted by maginotjr's private key.
What if you don't want people reading the message? Well, then you wrap the whole thing up in the sender's public key!
So the steps are now as follows:
1. User A writes message M, creates message digest Mdigest-sent
2. User A "signs" the message by encrypting Mdigest-sent: Aprivate Mdigest-sent = Asignature
3. User A puts the message M next to the signature Asignature and encrypts the WHOLE lot with User B's public key: (M + Asignature) Bpublic = Mencrypted
4. User A sends Mencrypted to User B.
5. User B first decrypts the message: Mencrypted Bprivate = (M + Asignature)
6. User B then reads the signature with who he suspects sent the message (User A in this case): Asignature Apublic = Mdigest-sent
7. User B recreates the message digest from message M: Mdigest-check
8. User B checks the two digests for discrepancies: Mdigest-check = Mdigest-sent
9. If the two digests are identical, then the message hasn't been tampered with and is definitly from maginotjr (User A)!
10. maginotjr enjoys sundialsvcs's party =)
~~~~~~~~~~~~~~~~~~~
To answer maginotjr's questions directly:
Quote:
|
So to me send you a secure email you first have to give me a public key and them I will encrypt my message using your public key and you will decrypt it with your private key that only you have?
|
Yes!
Quote:
|
And what happens when you public key expire, I will not be abble to decrypt my file neve more?
|
If you get a message that you can read with his expired public key, it is not from him.
Quote:
|
so this isnt the best way to encrypt files in my disk
|
The public key system is good for (relatively) secure communication, but it is not what you want to encrypt your disk, I think.
~~~~~~~~~~~~~~~~~~~
I hope that's clearly shown how public/private key encryption works, but I strongly advise reading up on it some more if you're looking for more detail! Many thanks to sundialsvcs for throwing a party for us all!
- Piete.
~~~~~~~~~~~~~~~~~~~
Disclaimer: If I've got something wrong, please please please correct me - I've done most of this from memory and my exams were a while ago!
thanks for you pascience...
and Bob 
." And of course to "Eve," 
... the eve-il eve-sdropper.
This signature was prepared thusly:
