Well, it's a somewhat broad topic that can range from implementation details to mathematical proofs in number theory. How about I give you an overview, and then you can ask for the details that interest you?

One thing I will warn you: Do not implement your own cryptographic software or algorithms for production use! You'll regret it, unless your working with a team of mathematitions and computer scientists who understand how to prevent side channel attacks, and are willing to regurously inspect the code.

First I'll assume that you know how a symmetric cypher kind-of works. You give it plaintext and a password, and out pops the cyphertext. Then the other person can combine the password and the cyphertext to give back the plaintext. A little commic about AES can be found here.

End-to-end encryption is exactly what it sounds like; it's when one person encrypts a message, and it is not decrypted until it reaches it's destination (no matter the actual medium used).

A simple form would be that Alice and Bob pick a secret password, and all messages are encrypted before Alice sends a message and after Bob recieves it. An attacker Eve would not be able to see what Alice and Bob are talking about, even if she can see the cyphertext because she is still missing the password.

There is a small problem with this system. What if Alice and Bob haven't actually met in person to share a password (and all they have is an unsecure connection that is being tapped by Eve)? If Alice and Bob were to share the password over a public channel where Eve is listening in, then Eve will be able to decrypt the messages with the password!

That's where asymetric encryption come's in. There are various ways to do this, but one of the more famous examples would be RSA. The basic idea is that Alice generates a private and public key (and Bob does the same). Then then openly share their public keys (even if Eve see's the public keys). If Alice wanted to send a message to Bob, she would use Bob's public key to encrypt the message. The trick is that only Bob's private key can decrypt the message. Thus Eve (she has two public keys) does not have enough information to decrypt messages going either way.

(aside: RSA would generally be used to find a shared key, then AES would be used for the rest of the message. The reason is that it's hard to calculate RSA for large messages)

This is great... Except this system introduces a new flaw. Eve can pretend to be Alice and send a message using Bob's private key. Bob has no way of knowing that the message actually came from Alice (and Eve can set up a trap like "leave the goods in the forrest at midnight").

That's where signing comes in. In RSA, encryption and decryption are inverses of each other. So, Alice can compute a secure hash of the message and "decrypts" it using her private key, and send that with the message. Then Bob "encrypts" the hash with Alices public key giving the original hash and compairs it with the hash of the message sent. If the hash's match, then the person who sent the message must be Alice.

This is a lot better... Except there is still a problem. What if Eve is able to swap messages out with her own? Then when Alice and Bob trade public keys, she switches them with her public keys. Now when Alice think's she's talking to Bob she's really talking to Eve. And when Bob think's he's talking to Alice, he's really talking to Eve. This is called a "man-in-the-middle" attack (or MiTM).

This is where certificate authorities come in. When Alice and Bob install their operating system (which came on a physical disk that was not tampered with), the operating system comes with a list of public keys for some certificate authorities. Thus when Alice and Bob generate their keys, the submit the public keys to a certificate authority. If Alice want's to confirm that Bob's public key is not a forgery, she computes the hash of Bob's public key, and asks the certificate authority if it's legitimate. Eve is unable to make a forged public key, and is unable to MiTM the CA since the public keys were predefined on the operating system.

This is why when you send information to a website, you should be sure that the certificate is valid, and all information is being transferred through that connection (generally you can see it by clicking on the left of the address bar).