This is a short introduction into cryptology that does not approach cryptological details or mathematical foundation of cryptology. If you are interested in this topic more fundamentally you can choose between several popular or scientific publications.

As email is an asynchronous technique, it will be secured by the so called public key cryptology:

What are constituents of a key used within public key cryptology?

To be precise the key is a key pair. It consists of a public key that is not secret and one or more private keys that are secret and password-protected. The public key contains information about the owner of the key. It is used to encrypt digital contents like files, texts, emails or phone calls. Anyone who knows it can use it. The public key will be published on websites and keyservers or it will be sent as an email attachment. The public key should be public and it is not protected in any manner. Additionally the public key is needed to validate digital signatures.

The secret (or private) key is needed to decrypt an encrypted content and to sign a message digitally. This key must not be shared to make sure that your communication remains secured.


The public key is public and published, accessable to anyone. It is used to encrypt contents and needed to validate digitally signed contents.

The private key has to be kept a secret. It is used to decrypt contents encrypted by the correponding public key and to sign contents digitally.

It is important that a private key must not be issued by third parties like email- or security providers. It should be created on your own computer.

PKI (Public Key Infrastructure)

You may ask why these things are so very complicated? In principle it is a matter of confidential communication between actors that are not knowing each other. Friends may share their keys (not on the internet) and open a communication that is as safe as the public key technique. But how should persons communicate their keys to strange persons on a safe way? Secured communication (outside public key technique) is not possible until the communication partners have exchanged their keys.

Substantiated by mathematics the public key technique enables one-way-cryptology. Now it is possible to encrypt a message using a public key that is decryptable only by the owner of the private key belonging to the public key the message has been encrypted with. Even the person who has encrypted such a message is not able to decrypt it. Just the person who has access to the private key can decrypt such a message. This is secure!

The confidentiality of a message, that means that the message's recipent only may decrypt and read it, is just one side of the coin but not necessarily the most important one. Most of us will never become spied on as we are not very interesting to secret services and never communicate suspicious things. But just now we are receiving emails with fraudulent purposes. Criminals are trying to get access to banking logins or credit card data. Other criminals are trying to place malicious software that may encrypt your data out of your control to get ransom money. Other trojans are tracking your keyboard entries to send them to criminal actors. Today most of these attacks are still in their infancy but it can be anticipated that they will be developed. Protection against such attacks on private individuals is almost very poor. The best way to avoid such nuisance will be the validation of the identity of email senders. In section "Email" above I explain that analysis of an email header is useless: Any parts of the header might be fake. And especially criminal actors will fake their email headers. That's the reason to establish digital signing.

In my view the validation of authenticity of the sender is as important as the confidentiality of the message. Because you have published your public key (to get encrypted messages) anybody who gets it may send you an encrypted message e.g. the criminal who suggests that he is your banking institution. An encrypted message is not more trustworthy than other messages.

To ensure that a message has been sent by the one who he seems to be and to ensure that the message has not been manipulated on its digital transmission the digital signature was created.

The digital signature provides information about the signer and ensures that the message is unaltered since it has been digitally signed. The digital signature is based on mathematical algorithms that I will try to explain shortly.

Here comes a tricky component into the game. This is the hash-based message authentication code (hash sum). Simply explained the hash sum is a mathematical nexus of information. One of them can be your message, the other one is a (fixed) hash key, you may see it as a number built on an encryption table that is anchored within the secret key you are using. I'm not able to provide a sample but there is much literature about it. Imagine this proceeding: A very big number (2128 or 2256) will be proceeded by a mathematical function (algorithm). The result is a very big checksum (finger print) which has been built from your message and your private key. A hash proceeding is considered as unsecure if someone succeeds in creating a message that fits with a given hash sum. The sha-256 algorithm is considered as secure. But if computers' abilities may increase it might be necessary to use other algorithms using bigger numbers. These hash sums (finger prints) are used to identify cryptologic keys. You can build a hash sum on any digital information. So you can hash a cryptological key too. Any key has a finger print which is published by many PKI users. If the published finger print matches the finger print your cryptology program has computed from the key it is proven that the sender really is the owner of the key. Should you trust this key now? If it is a published key you can do this. Otherwise you should contact the sender to ask for the finger print of his key.

Validation at this stage shows the validity of a key - the key belongs to the sender. A key may be valid but do you trust it?

Identities of senders cannot be verified mathematically and therefore a PKI (Public Key Infrastructure) becomes important. PKI is an infrastructure of trusting one another. The methods that PKCS#7 (X.509 Certificates) and openPGP use are considerably different.

PKCS#7 resp. X.509

To verify an identity certificates are used. Within the pkcs#7 (sMIME) technique the certificates are built on the policy X.509, so the certificates are called X.509 certificates. A certificate digitally confirms the identity of an owner of a public key within this. X.509 is organized hierarchically. There are certificate authorities (CA) that confirm identity of key owners. To get a X.509 certificate you normally have to proceed as follows:

1. You create a key pair (a public and a private key). An open source program you may use to do this is openSSL.
2. Afterwards you will send the public key as a request, and documents to verify your identity to a CA.
3. The CA will return your public key after its certification.

In most cases you have to pay for certification but some CA offer certifying for free. These free certificates are limited to certification of an email address as it is sufficient to prove the accessibility of this address which may happen automatically. Almost always in case of free certification the CA will create the private key belonging to the certified public key and install it within your browser. Under security aspects such proceeding is not persuasive.

Another way to get certificates for free is offered by CACert, you may get information under

Certificates of big players in this business are often built in by main browsers or email clients.

X.509 CAs maintain revocation lists (CRLs) to avoid usage of invalid or corrupted certificates.


OpenPGP takes a different path.

As in PKCS #7 you have to create a key pair at first. The public key is self-signed initially (signed which the key you have just created). To achieve trust in the key (public key) the owner of the key is called to convince as many peers as possible to certify (sign) his key. This is the original idea of PGP and it works fine if it is used in manageable groups. Most authors have criticized this concept and discarded it as impracticable. The size of the key increases the more certificates are placed in it, on the other hand the key is still untrusted outside the own circle of acquaintances.

Many years ago the German ct‘ magazine initiated a crypto campaign in which interested users can identify themselves and get a certification on their keys. CACert offers a similar project. CACert certificates an openPGP key based on an existing X.509 certificate issued by CACert. There are ways to get out of the peer myth! 

You may certify single openPGP keys e.g. by signing (certifying) the key of John Doe. The program will recognize that you trust John Doe's public key. Another possibility is to trust the key of an introducer (this is a PGP term that means a user whose reliability in correct certifying is trusted). If you have certificated an introducer's key using the entry "depth of trust = 2" you (resp. your program) will trust any keys that are certified by this introducer's key. If John Doe's key is certified by this introducer's key you will trust John Doe's key automatically. To trust an introducer only means that you trust in his methods concerning the verification of identities. ReSecCo provides the keys of these three instances I know about which are willing to certify openPGP keys. To bring the system in motion you should trust them as introducers.

It might be a good idea to build your own openPGP CA. If you are a company, a school or a university you can certify the keys of employees, teachers or students to create a communication area that is secured. There are not only no arguments against a security area of one's own, it is an ideal solution. You will master the perils that the upcoming digital age may hold and a PKI is inexpensive, reliable, absolutely secure and not very difficult to understand. Only bigger organizations may build a CA based on PKCS #7 (X.509).

This text is part of the ReSecCo documentation but there is no need to use ReSecCo to secure your communication. I think that ReSecCo makes digital security more convenient, that's all.