Background knowledge of cryptography

Confidentiality is ensured by encryption and decryption. A secret key (a very large number) controls an algorithm, the so-called cipher, which is not normally secret but should be widely researched and analysed for weaknesses (cryptanalysis).

The security of an encryption method depends primarily on two factors:

• The encrypted data must not have any structural characteristics of the original data. They must not be distinguishable from purely random numbers.
• The key length (measured in bits) must be so large that it is impossible to try it out. In addition, there is a surcharge in the event that the previous factor is only partially fulfilled due to advances in cryptanalysis.

The Caesar cipher is a good illustration of this. We limit ourselves to the 26 letters A to Z. When encrypting, each letter is replaced by the letter that is n places further to the right in the alphabet, starting again with A after Z and so on. With n = 4, an A becomes an E, a B becomes an F and so on. Finally, a Z becomes a D. The number n is the key here. An example:

Plain text: A LITTLE DUCK SWIMMING ON THE LAKE

Encrypted: E PMXXPI HYGO WAMQQMRK SR XLI PEOI

This method has two problems according to the factors mentioned above:

• The encrypted text reflects the different occurrence of the letters in the plain text. Whoever calculates which letter occurs most frequently in the encrypted text immediately knows the key.
• There are only 25 different keys (key length 4.6 bits), which is easy to try out.

In cryptographic terms, keys are simply large numbers. The minimum length that keys should have today depends on the method used. The spectrum ranges from 256 to 2048 bits (a number with 617 digits).

To ensure that nobody can guess the key, it must be chosen completely at random. Since a computer does not throw dice, factors are used that outsiders cannot know: Time of day (but which can be guessed approximately), duration of hard drive accesses and much more. Generating random numbers from this without a recognisable pattern is anything but easy and has already failed spectacularly several times.

Of course, once a key has been generated, it cannot be memorised and typed in as required. It is stored in a protected (on the web server) or encrypted file (on the PC), depending on the protection requirements and application. In special cases, special hardware security modules are used for this purpose.

Asymmetric procedure

If you want to encrypt data not for your own use (for example, to store on your hard drive) but for transmission to someone else (e.g. by e-mail), there is a problem: How is the recipient supposed to find out the secret key?

One answer to this is provided by so-called asymmetric methods or public key cryptosystems. The keys for encryption and decryption are different and cannot be calculated from each other. The implementation looks like this:

1. The recipient publicly discloses the encryption key (public key).
2. The sender encrypts with the public key.
3. The message is transported.
4. The recipient decrypts with the other, private key.

This approach leads to a new problem: how do you determine whether a particular public key actually belongs to the person for whom the message is intended and not to a spy? Digital signatures are the solution to this problem.

A central security question is: Who is the message from (who is the data from) and has it been altered in any way? If you can answer both questions, you have a digital signature. This is achieved in three steps:

1. The hash

First of all, you need a way to recognise the message (or the data) beyond doubt using a number of a manageable size (about 256 bits). To do this, a hash value is calculated. This is a check number that is used like a fingerprint of the message.

The hash procedure is designed in such a way that even the smallest changes lead to different values. It may also not be possible to construct a second message that leads to the same hash value.

Let’s take a short poem and its hash calculated using the SHA256 method as an example:

SHA256: 63ed19d10c3d8bde2ecd7b3ab0e3d04d6b5eaa20fdd934537209fefe50a83fb5

2. The signature

To turn the hash into a signature, you need asymmetric encryption again – only in reverse.

1. The sender encrypts the hash with the private key.
2. The result is transmitted with or alongside the message.
3. The recipient calculates the hash of the message themselves.
4. The recipient decrypts the signature with the public key of the claimed sender.

If the results match, the data is unaltered and, based on the public key, authentic. However, it is not yet certain who the key (actually the key pair) belongs to.

3. The identity

The signature of a message assigns it to a key (or key pair), but not yet to its owner. In fact, cryptographic keys contain other information in addition to the pure numerical data, in particular the name, e-mail address, etc. of the owner.

However, this does not prove anything. Anyone can create a key pair at will. Therefore, the key and thus the assignment to the person is confirmed by a digital signature.

Technical-organisational solutions whose task is to generate trust in the assignment of a key pair to a person (or organisation, unit, etc.) are called Public Key Infrastructures (PKI). There are two types of PKI:

• Central certification authorities whose main keys are built into the software or operating system (x.509 for web certificates, S/MIME works like this)
• A web of trust that is formed through personal contacts (PGP/GnuPG)

Both approaches have advantages and disadvantages and have already experienced serious failures.

While the centralised model is relatively easy to use, you have to trust government and/or commercial certification authorities that you don’t know.

The web-of-trust model, on the other hand, places control and full responsibility in the hands of the parties involved, which makes things complex but easy to track.