Skip to main content

Keys and encryption

By 7 March 2019 December 23rd, 2020 Blog

In the previous blogs of this series, we discussed the hash and the checksum. In this blog, we will continue with the next underlying technology for the block-chain: encryption. Encryption means encoding data with the objective of third parties not being able to shoulder surf.

The hash is a good method to determine whether the data that you have just received are ethical, or that you have the correct authentication token (password, pin code, etc.). However, in many instances you want to be able to view your data without strangers being able to look at them as well. In that case, we arrive at the mathematical cousin of hashing, namely encryption.

Encryption is a reversible processing of the data, with the result that the data cannot properly be read after the said processing. In case of a good encryption algorithm, encryption is easy and fast and the encrypted data are very difficult to trace back.

In addition, it is a good idea to base the said processing on a general standard. This is particularly handy when information needs to be communicated. Namely, the recipient must be aware of how the encryption works and must also have processed this in its software.

Hence, we do not want this:


But this:


An arrangement was agreed on with the recipient as to how to use the encryption machines. This arrangement is also referred to as the key.


A calculation example:
We are going to encrypt data with the following (standard) algorithm:
encrypted = unencrypted * key(1) + key(2)

And the opposite:
unencrypted = (encrypted – key(2) ) / key(1)

With the recipient we agreed on the arrangement that key(1) equals 5 and key(2) equals 2.

In the chapter about hashing, we had already converted the word “Nederland” into a series of numbers.

n=14 → 14 * 5 + 2 = 72

The number 72 is, therefore, the encrypted value of “n”. This way we can do the entire word:


And the recipient can convert this word back with:

( 72 – 2 ) / 5 = 14 → 14 = n

This encryption algorithm is, for that matter, really bad. A mathematician will not require very long to retrieve the keys (after all, the algorithm was not a secret). The time that he will need for this can be extended slightly by using very large numbers for the keys.

In a layout where the sender and the recipient use the same key, we refer to the encryption as symmetrical. This way of working has a disadvantage, also for high-quality algorithms. I need to schedule an appointment with the recipient about the keys. They cannot be sent in the same manner as the rest of the data because the key may then be intercepted.
The most secure way would be to go to the recipient and whisper the keys in his ear. That is quite a bit of work the first time. And this needs to be done every time a key is changed.


Assume that we could find an algorithm where you have a key for the encryption of the data and where you would need to use a different key for the decryption. Then you could send the one key to the party who needs to send you secret information. The key that is used for the encryption of the data cannot be used for the decryption. Hence, it does not need to remain secret, it can, for instance, be sent regularly by mail. That is why we also refer to it as the “Public Key”. The key that you retain is the “Private Key”.

In a layout where the sender and the recipient use different keys, we refer to the encryption as asymmetrical.


An example of this and one of the oldest algorithms in this area, is the RSA (Rivest–Shamir–Adleman) algorithm. The following part relies heavily on an article by Burt Kaliski.

In case of RSA, the Public and the Private Key both consist of a set of two numbers.

Example: in all calculations we only work with integers (no decimals):


  1. We start with two large prime numbers p and q. For our example we use two small numbers: p = 5 and q = 11.
  2. Via these numbers we determine the numbers w, v, and x (see article). In our case:
    1. x = 55
    1. w= 7
    1. v=3.
  3. My public key is now (x,v) = (55,3) and my private key is now (x,w) = (55,7)

I will now encrypt “Nederland” with my public key and the RSA algorithm: encrypted = unencrypted v mod x

For the letter n, which was represented by the value 14:
143 mod 55 = 2744 mod 55 = 49

49 is therefore the encrypted value of the letter n in our example. To decrypt it: unencrypted = encrypted w mod x

497 mod 55 = 678223072849 mod 55 = 14

If I now want to communicate back and forth with another party, then we both determine our personal private key, which we use to calculate our public keys that we subsequently exchange.

We then obtain this:



Try this:

147 mod 55 = 9 en 93 mod 55 = 14

At first glance, the encryption with the private key has no use, because everybody can decrypt it with the public key, which is publicly available.

But remember that the combination of private and public key is unique and that the public key is calculated from the private key. The fact that the message can be decrypted shows that it was sent by the holder of the private key (assuming that the private key was not stolen).

The encryption of data with the private key is therefore referred to differently. You encrypt something with the public key, and you sign something with your private key. So, in fact they are the same algorithms, just applied differently.

For that matter, not all encryption algorithms that are being used are suitable for signing. RSA is, but Diffie-Hellman, for example, is not.

If we agree to meet each other physically to exchange the keys, then afterwards we can not only communicate securely, but we are also certain that we are speaking with each other.
Given the number of parties that we want to communicate securely with and of which we want to be certain that we are speaking with the right person, it is not very convenient to visit all those parties first.

That is why there are businesses that offer themselves as trusted third parties (Trusted Third Party; TTP). They verify on request of, for instance, your bank that a public key is actually of that bank. After verification, they sign the public key, including the information about the party, with their private key. We refer to the result as a certificate. Certificates are used for, inter alia, https websites.

You can always confirm the signature of the certificate and check the validity of the certificate with the TTP. To this end, you first pick up the signed certificate at the bank. You encrypt the relevant signature with the public key of the trusted third party (by default part of your internet browser). This demonstrates that the certificate was indeed signed by the third party and that the said third party verified that the public key is actually of the bank. You now dispose of the public key and data of the bank and can now encrypt your transactions with the public key of the bank and send it (and only the bank can then decrypt it with its private key).



  • Asymmetrical Encryption: Encryption where the encryption takes place with one key and the decryption with another, which is related to the key that was used for the encryption. Examples are RSA and DSA.
  • Certificate: Public key in combination with data that refer to the identity of the holder of the public key, plus a hash of the key and identity details, signed by the TTP.
  • Encryption: The conversion of a block of data into something that cannot be traced back without knowledge of the key or the algorithm.
  • Involution: For instance, 43 equals 4x4x4.
  • Key: Number or block of data that, in combination with the encryption algorithm, can be used to encrypt something.
  • Modulo: Divide by rest. The Modulo is the rest of the division.
  • Private Key: Encryption key that is used in asymmetrical encryption and that must be kept secret by the owner.
  • Public Key: Encryption key that is used in asymmetrical encryption and that is public.
  • Signing: Encrypting with the private key.
  • Symmetrical Encryption: Encryption where both parties use the same secret key. Examples are: Triple-DES (3DES; is no longer secure), Blowfish, Two-fish and AES.
  • Trusted Third Party (TTP): Party you trust to check the identity of other parties.
  • Verifying: Decrypting with the public key.