I was a bit bored, so I'll go for it.

The basic idea behind crytography is that you want a way to pass around information to only the people who should see it, and the best way of making sure of this is to give those people some sort of secret that will let them, and only them, to easily figure out the information you're passing. You can think of it as basically just a key and a lock, where the secret you're passing is the 'key', and the message you're trying to pass is the 'lock'. Without the key, opening the lock would be nearly impossible, but it would be a simple matter for the person who does have it.

What modern-day algorithms do is basically similar to this, but with a slight twist. The problem with the idea above is that you still need to give the secret to everyone involved, which could be insecure. Over the Internet, you never know who you might be actually sending your secret to. Because of that, it could be easy for some malicious person to pretend to be someone you trust, get the secret, and be able to read any future messages that you send from now on. So how do we get past this?

Using the key and lock analogy again, instead of giving everyone the 'key' (secret) beforehand, each person has their own key that they never tell to anyone else. So now, instead of passing a key around, each person publicly passes around a lock that only opens to their own personal key. If we have two people, Alice and Bob, if Alice wants to send a secured message to Bob, she would take one of Bob's locks and lock her message inside a chest closed by it. Now, since no one else has a key to that lock except for Bob, no one else should be able to open it. It doesn't matter whether or not some malicious hacker gets a hold of one of Bob's locks, since the only thing that they would ever be able to do with it would be to lock a message for Bob, not to open anything already locked.

So what crytography algorithms nowadays do is generate these key and lock pairs for people to use, but there's still one problem we haven't addressed yet. How can we make sure that someone wouldn't be able to reverse-engineer a key if they have the lock? One of the most famous algorithms, the RSA algorithm, prevents this from happening by generating keys and locks using something called a trapdoor function.

For computers, keys, locks, and even messages are basically numbers. So what a trapdoor function basically does is that it converts a few numbers (the keys) into different numbers (the locks) very easily, but makes it very difficult to convert those same locks back into their keys. Think of it like, well, a trapdoor, where it might be very easy to fall into a trap, but very hard to get back out. The RSA algorithm does exactly this, through multiplying together different prime numbers.

If I gave you two prime numbers, like 17 and 53, then you could very easily tell me what their product (901) would be. But if I gave you 901, it would be much harder for you to figure out what those prime numbers were at the very beginning. The RSA algorithm does exactly this, but just a little bit more complex. So how it works:

1. Choose any two prime numbers, 'p' and 'q'.
2. Multiply them together to get their product 'n', the first part of our lock, or whta we call the public key.
3. Find out how many numbers share no factors with that product, except for 1 (this number is called the totient 't')
4. Choose a positive number 'e' that is less than the totient and also shares no factors except for 1 with the totient. This will be the second part of our public key.
5. Find some value 'd', such that d * e % t = 1. The '%' sign here means modulus, and it's basically the remainder when d*e is divided by t. This your own key, or what we call the private key.

So let's try an actual example. We'll choose 17 and 53 again.

1. Our prime numbers are 17 and 53.
2. Multiplying them together gives us 901.
3. The third step seems hard, but there's a shortcut since we're dealing with the product of two primes. You can just use the equation 't = (p - 1)(q - 1)' So in our case, our totient = (17 - 1) * (53 - 1) = 832
4. And for the last step, we can just choose a number we already know is prime since we'll know they won't share any factors unless 832 is divisible by it. We'll pick 3.
5. We can rewrite the formula above as d = (1 + nt) / e for integer solutions of d and n is any positive integer, since we're just basically trying to find out when we will have a remainder of 1. Trying out different values of n: n = 1 -> (1 + 832) / 11 -> Not an integer n = 2 -> (1 + 2*832) / 11 -> 555, so our d = 555

Now we have our public key (832) and our private key (555), so time for the fun part. We give the public key (n = 901, e = 3) to our friends so that they can use it to encode things. How do they do that?

They first have to turn the message they want to encode into a number. To keep it simple, we'll just use a simple alphabet cipher for now (so A = 1, B = 2, ... , Z = 26)

If they want to encode "HI", then we'll turn it into "89", using the simple alphabet cipher. Now to encode each with our public key.

The equation to use is encoded_message = plain_message^e % n. From before, our 'e' and 'n' were 11 and 901, so to encode '89', we can just do:

89³ % 901 = 387, which is our final encrypted string.

To decrypt it, we can now use our private key, which will work for only this public key.

We use a similar equation decoded_message = encoded_message^d % n. From before, our 'd' and 'n' were 555 and 901, so to decode:

387⁵⁵⁵ % 901 = 89, getting back our first number, and translating it back into "HI".

So, yeah, cryptography and RSA in a nutshell. It might be a little beyond the scope of an 11-year-old, but hope this helps out. Your site is pretty cool and I'd definitely be interested in how it turns out.