How can the private key serve as both, the username and password?

It's actually the cryptography behind the private keys and digital signatures that allows us to combine the identity and the proof into one thing (the private key). If you're interested in how it's done, read this:

Yes there is public key and address but the core thing is still just the private key (it holds both the identity and the proof). Public key and address are just deriviations from the private key

Authentication in web3 acutally also consists of 2 things: address (identity) and private key (proof that you own this identity). What seed phrase allows us to do is to combine these 2 into 1 thing. How? Find out in the next section. Disclaimed: it's not the seed phrase that allows us to combine. It's the cryptography. Seed phrase just allows us to turn the private key into a human readable form

You've probably come across terms such as

Hash functions

Proof of work and nonce

Public/private keys, signatures, and cryptography

during your blockchain explorations. In this article, we will explain all of these terms. Here is all math you need to know to understand the inner workings of blockchains.

This is part 3 of 3. For other parts see below.

Hash functions →

The math and intuition behind hash functions

Blockchain math. Part 2 →

Proof of work and nonces

Digital signatures and a crash course on Cryptography

Now, onto the last section - the digital signatures.

In the blockchain world, transactions are signed with signatures by the initiators of the transaction. Those signatures resemble the traditional signatures that we know of - the pen and paper signatures.

In this section, we will explain how it's possible to implement the concept of signatures in the digital world.

The purpose of signatures is to prove that you're the one that signed a document and no one else can impersonate you. But you might wonder how such a thing is possible in the digital world where you can copy-paste anything, including signatures. The answer is cryptography.

Cryptography allows us to implement digital signatures that are unforgeable. Only the owner of the signature can sign a particular document and no one else can fake it.

Cryptography is actually more commonly used for secure communication, but the concepts from secure communication have been extended to implement digital signatures.

Let's first talk about the applications of cryptography in communications because it's a simpler and more familiar concept to understand.

Secure communication using cryptography

Imagine that two generals want to communicate during a war. But they are afraid that their communication might be intercepted by the enemy.

How can they make sure that their communication line is secure even if it's intercepted by the enemy?

Well, if they use some kind of a cipher that only they understand, the enemy won't be able to tell what they are talking about. Their communication will look like gibberish to him.

How do we implement a cipher digitally in computers?

One way is via what's called Caesar's cipher (This was a method by which Caesar was able to secretly communicate with his generals without anyone being able to read the messages. Even if the message carriers were intercepted).

The way it works is that you encrypt and decrypt your messages using a key. If both generals have this key, they will be able to encrypt their messages before sending and decrypt the messages after receiving them.

What is this key? Well, it's just a random number from 0 to 25:

$key=random [0, ..., 25]$

Let's say our key is equal to 3. And the message we want to encrypt is.

$I\ love\ treason\ but\ hate\ a\ traitor$

Now the way you encrypt is by looking at each letter in the message, and shifting the letter by 3 according to the alphabet. For example, the first letter "I" will be converted to "L"

The second letter, "l", will be converted to "o"

and the third letter, "o", will be converted to "r".

and etc. The whole message will be turned to

$L\ oryh\ wuhdvrq\ exw\ kdwh\ d\ wudlwru$

This is the encrypted message. As you can see, it looks like gibberish. This is what the enemy would see if they were to intercept the messages.

To decrypt the message, the general on the end would do the reverse: look at each letter and shift it by 3 but in the opposite direction.

Key exchange

This works fine - the generals can communicate safely knowing that their communication is secure. But the problem is how do they exchange the keys? If one of the generals generates the key, how can he send it to the other general?

Well, he can't send the key through the communication line because he would have to send it unencrypted but he doesn't want that because the enemy might intercept the key and be able to decrypt all the following messages.

So they will have to exchange the keys via other means. Maybe send a trusted soldier to deliver the keys.

As you can see, this simple method works. Even if the enemy intercepts the messages, he will only see gibberish. But the generals have no problem understanding each other by decrypting the messages using their keys.

This way of encryption is called symmetric key cryptography. (symmetric because the keys on both ends are the same). There is another way - asymmetric cryptography where keys are different.

Asymmetric cryptography is also used for secure communication and it has certain advantages over symmetric cryptography. Let's learn about asymmetric cryptography

Asymmetric cryptography

Asymmetric cryptography differs from the symmetric one in that it uses different keys for encryption and decryption. Let's look at an example.

The setup is the same: we have two generals trying to communicate and they are worried the enemy might intercept their messages.

They will again use keys but this time, each one will have a different key and there is no exchange of keys required. So, no need to use a soldier to share the keys.

First, each general generates two keys: public and private keys according to the function described below:

Choose 4 random numbers: $x, y, z, q$

Compute the following $M=xy-1$ $e=zM+x$ $d=qM+y$ $n=(ed-1)/M$

The public key is: $e$ and $n$ (letter $e$ denotes encryption) The private key is: $d$ (letter $d$ denotes decryption)

For example, the first general generates his public and private keys like this:

And the second general generates the keys like this:

Intuition

The idea is that the private key is meant to be kept private but the public key can be shared by anyone - even the enemy.

So generals can exchange their public keys over the unsecured communication line. The enemy won't be able to decrypt the messages using just the public keys.

Example

Assume, the generals exchange their public keys over the unsecured line (there is no harm in sharing them with anyone).

Now, let's say the first general wants to send this message to the other general:

$Noon$

To encrypt it he will do the following:

Convert the message into a number $m$ . How? By looking at each letter and substituting it with a number according to the table below. So "N" will be substituted with 78, "o" will be substituted with 111, etc. But to make things nice and even, we will make each number have 3 digits. So instead of 78, we will actually use 078. Let's say the resulting number is $m$ (for message)

Encrypt the resulting number into ciphertext $c$ : $c=em\ \%\ n$ ( $\%$ here denotes the remainder operation. In other words, $c$ is the remainder when $em$ is divided by $n$ ). $e$ and $n$ , here are the public keys of the other general.

Then the general would send the ciphertext $c$ .

Visually

To summarize, if I want to send someone a message,

I first convert this message to a number,

I then use the public keys of my recipient and encrypt my message with the public keys of the recipient.

Here is how it would work:

Decryption

And the other generals will decrypt the message using her private key according to the function below:

Decrypt by multiplying the ciphertext by private key to get $m$ : $m=dc\ \%\ n$ . Note that the original number $m$ is recovered here because $m=dc\ \%\ n=d(em\ \%\ n)\ \%\ n=dem\ \%\ n=(Mn+1)m\ \%\ n=(Mnm+m)\ \%\ n=m\ \%\ n$ . And as long as $m\leq n$ , we will recover the original $m$ .

Convert the number $m$ back to the message: By looking at 3 digits at a time, and using the table above to convert the code into letters.

The full flow is like this:

Intuition

The intuition here is that you encrypt a message to someone using their public key and they decrypt it using their private key.

Notice that your keys don't play any part in this exchange. Only the keys of the recipient are used.

The private keys are kept private (you use them to decrypt a message sent to you), but the public keys are exposed to the world (people encrypt a message to you using your public key, and only you can decrypt it because only you have access to the private keys).

Is this magic? 🔮

How can someone encrypt a message to me using just my public key so that it's decryptable by only me (only using my private key)?

This method works because the public and private keys have a dependency on each other - they are not just two random keys.

Remember, the public and private keys were generated from the common seed numbers. Each private key will have just one specific public key that will make everything work.

You can't just make up any public key - it won't make the algorithm work. So, because of this mathematical relationship/dependency between the public and private keys, the math checks out and the whole algorithm works.

It’s also impossible to infer the private key from the public key alone. That’s because the function that generates the public and the private key is one-way, similar to hash functions.

In a way, two operations of encryption and decryption cancel out. Similar to canceling out common factors in fractions. If you have a number $m$ and multiply it by $e$ (encrypt it), then multiply it by $d$ (decrypt it), you get back $m$ (the encryption and decryption cancel each other out): $dem\ \%\ n=m$ . That's because $de\ \%\ n=(Mn+1)\ \%\ n=1$

$x * \frac{1}{x}*m=m\ \ because\ \ x * \frac{1}{x}=1$

$d * e*m\ \%\ n=m\ \ because\ \ de\ \%\ n=1$

This was the overview of asymmetric cryptography. It's also sometimes called public-key cryptography.

The algorithm used for key generation, encryption, and decryption in this section, is actually called Kid-RSA and it's the simplified version of the well-known cryptography algorithm RSA. The actual algorithm is more complex but the high-level concepts are no different from Kid-RSA.

Symmetric vs asymmetric cryptography

In asymmetric, you don't need to exchange keys privately beforehand. Can just share the public key with anyone in the world. It's safe to do so.

But asymmetric is much slower than symmetric.

So symmetric is used much more in practice.

The way secure communication works in practice is the hybrid approach: First, use asymmetric cryptography to exchange private keys of symmetric cryptography. From then on, use symmetric cryptography because it's much faster.

RSA algorithm which is used for asymmetric cryptography is a very slow algorithm. It's mainly used to exchange symmetric keys.

Now that we have some background on cryptography, we can finally get to what we originally wanted to learn about - digital signatures.

Digital signatures

We already talked about one application of cryptography - secure communication. Using both, symmetric and asymmetric cryptography.

The second application - digital signatures, can only be implemented using asymmetric cryptography. Let's look at how.

The process is very similar to the asymmetric cryptography example.

Let's say you have a piece of content like a message m=Hello. And you want to attach your signature to it acknowledging that you have read it and agree with it. The way you do this digitally is by

Generating public and private keys for yourself. We use the same procedure to generate private and public keys: The public key is: $e$ and $n$ The private key is: $d$

"Signing" the message. To "sign" the message you calculate: $s = d * hash(m)\ \%\ n$ . $s$ serves as your signature. ( $hash(m)$ is the hash value of $m$ using any pre-agreed upon hash function). And you send your encrypted message along with the signature.

Signature verification. Now, anyone can verify that you signed the message by calculating $h=es \ \%\ n$ . If $h$ matches $hash(m)$ , that means that you indeed signed the message. Why? because $h=es\ \%\ n=ed * hash(m)\ \%\ n=hash(m)$ . No one, other than you, has access to $d$ (your private key) so no one could have made the math work out such that $h=hash(m)$ (keys cancel out) except you.

Note that you are still keeping your private keys privately, only the public key is exposed.

This is again the simplified version of the RSA algorithm for signing. The actual algorithm is much more involved but the high-level ideas remain the same.

Beauty of math

This is the beauty of math in cryptography: you can sign a message using your private key and anyone can verify it using just your public key. You don't have to reveal your private key.

This again works because of the relationship between the public and private keys. They are not just two random numbers.

They actually have a mathematical relationship between them. The public key is derived from the private key. There is only one public key that will work for a particular private key.

Signature depends on the content it's signing

Notice that signature actually depends on the content it's signing.

This is because s contains hash(m) in it. If we change even the tiniest part of the content (m), the signature is no longer valid and we have to create a new signature for this new content.

So, as you can see, in the digital realm it's possible to have a signature that depends on the content it's signing. Which means, every new content will require a new signature (you can't reuse the same one). This is not possible in the real world with and pen and paper signatures.

Purpose of digital signatures

The purpose of a signature in the digital realm is twofold:

One is to prove the identity of the person who is signing a message.

And the second is to prove that the message itself has not been tampered with during delivery. (If the message has been changed from the original sender, the signature would no longer be valid because signatures also "lock" the content via the hash function)

Usage of public/private keys in communications vs signatures

The usage of the keys is slightly different for both cases:

Communication

I use the public key of the recipient to encrypt my message and send it. The recipient uses their private key to decrypt.

Signatures I use my private key to sign a message. Everyone uses my public key to verify that it was signed by me.

In both cases, private keys remain private and public keys are exposed to the world

Forging digital signatures

It's actually possible to forge digital signatures.

You might think that the way to do it is just to copy the signature for one transaction and use it for another transaction. But remember we previously said that signatures depend on the content they are signing.

So each new transaction will require a new signature. No one can reuse a signature from a different transaction.

But what if someone reuses the same transaction with the same signature. For example, you send Bob $10 and sign the transaction.

Your signature will be in public so Bob can just copy this signature. But he can't reuse this signature for a different transaction like [You sending $15].

But he can reuse your signature for the same transaction. He can essentially replay your $10 transaction and send another $10 to himself from you. The signature will be valid because the content of the signature (i.e. the transaction) is still the same.

This is called a Replay Attack. The way it's solved is by using counters. You can learn more about it in my Blockchain course.

Blockchain Course

You might be interested in these

Kid RSA

Elliptic Curve Cryptography

Homomorphic encryption

Indistinguishability obfuscation

Ring signature

Elliptic curve pairing

Commitment scheme

And that is it, ladies and gentlemen. This concludes our 3 part series on "Math behind blockchains". This should be enough math to understand the internals of blockchains. Sign up to hear more updates or contact me if you have any questions.