Private & Public Keys: The Two-Key Trick

It Started with a Packet

I was asked to work on a project, and that project involved sending packets to the server. As a programmer who doesn't know much about how different systems work, I thought that if our system has authentication, no one can get into that pipeline. We log in, and everything is secured. But little did I know — if you have access to the server, you can get in and mess with it.

So to tackle that, you need some kind of system that makes sure no one can mess with the packets. And here, the two-keys formula comes into play.

The Secret Note Problem

Let's understand it with a story. Imagine you need to send a secret note to a friend. You cannot just send it directly — anyone can be able to open it along the way. So you lock it with a key. But how can your friend open it? You have to send the key too — but the key can be stolen, and the note can be easily opened.

So someone smart found a way out: use two keys instead of one — a key for locking and a different key for opening.

Now you give one key to your friend, which we can call the public key, and the friend gives their public key to you. You lock the secret note with your friend's public key, and it can be opened only by their private key. Now your secret note is safe — no one can open it.

One to Share, One to Keep

The public key is the one you share. Make copies, hand them to friends, post it on the internet — no problem. It's meant to be seen.

The private key is the one you keep. There's only one, it stays on your device, and you never show it to anyone. Not your best friend. Not tech support. Nobody.

How This Helped Us

To understand what we did, you need to understand locking and signing:

Locking: it's the same as I explained above — locking the secret with the public key, and only the matching private key can open it.

Signing: it means you sign the secret with your private key, and when the other person opens your secret, they will know that you sent it and nobody messed with it on its way.

In our system, we use the signing method. We sign packets with the private key, which never leaves the user's device, and the server checks the packet with the public key. This makes sure of two things:

1. The packet really came from the right person.

2. Nobody messed with the packet on its way.

To change what's inside a packet, you need to sign it again with the right key — because the server checks it with the user's public key, and you don't have the user's private key to sign. So the packet is safe.

What's in the packet, you ask? That's our secret. 🤫

Thank you for reading. This is my first article, so if anything felt unclear, I'd genuinely love your feedback — it'll make the next one better.