Tutorial on public keys

Public key technology is the basis of modern protected communication. This short tutorial explains briefly without technical details the most important things to know about public keys. We also explain briefly some of our protection mechanims against the known attack points of public key based systems.

We use public keys for these reasons

Main attack types:

Public keys enable the formation of a shared secret.

When two persons exchange public keys which they have created they can calculate a value that only they know. A third person that sees the public keys exchanged cannot calculate this value. The calculated value is called a shared secret. It is typically used later as an encryption key to encrypt the communication between the parties. This method is called Diffie-Hellman key exchange according to its inventors Whitfield Diffie and Martin Hellman.

Public keys solve a very important problem: how to communicate securely an encryption key to the other person? By sending and receiving a public key.

Each public key has a corresponding private key. The creator of the public key automatically knows this private key. The shared secret is calculated by the help of this private key and the other person’s public key.

Post Quantum public keys use a construction called Key Encapsulation Mechanism (KEM). In it a person A uses a public key of person B and encapsulates a shared secret into ciphertext. This ciphertext is sent to the person B who decapsulates (decrypts) it using the private key of the public key in question. The decapsulation produces the same shared secret.

Public keys enable the recovery from attack.

Now the third person that watches the exchange of public keys cannot calculate the shared secret that the creators of the public keys can calculate. However, if he successfully sends a spy program and steals a private key from one of the parties then the shared secret becomes known to him and he can decrypt messages created after this public key exchange.

We have now a new problem: how to recover from the stealing of a private key?  EndCryptor solves this by creating new public keys and sending them.

The attacker must again be able to steal a private key – if he cannot do this he cannot anymore decrypt new messages.

Some public key based systems use a same public key for years. If its private key becomes available to an adversary e.g. via hacking all communication under shared secrets calculated from this key become known to the adversary. Computer viruses that search for private keys are known to exist.

EndCryptor creates new public keys every 2 weeks. These keys are contact specific - each contact will receive different new public keys when they exchange emails. When a person whose private key has been stolen sends a new message which has the new public keys and when it is received by the other party then a new shared secret can be calculated – the attacker has lost his ability to decrypt messages sent to the victim.

Man-in-the-middle attack

This attack can happen if a person sends a public key to another person at the beginning of the communication. In cryptography this attack is traditionally explained using three persons: Alice, Bob and Mallory. Suppose now that Alice and Bob want to communicate securely and that there is a third person Mallory who wants to decrypt the exchanged messages.

Alice sends her public key to Bob but Mallory intercepts it and creates his own public key and sends it to Bob. Bob creates his reply that has his public key and sends it to Alice but again Mallory intercepts the message and the public key and creates another public key and sends it to Alice. Now Mallory can impersonate both parties.

Man-in-the-middle attack: Alice  ↔  Mallory ↔  Bob.

Alice and Bob do not know that there is Mallory between their communication who replaced their public keys with the public keys created by Mallory. Mallory decrypts and re-encrypts every message exchanged between Alice and Bob.

Traditionally this attack is prevented either by using certificates or using some communication between Alice and Bob to check that the first messages were not altered (i.e. to compare checksums of exchanged messages). The certification solution is used in online communication to websites (https which means TLS/SSL) – it has some risks, see ‘the risks of SSL’ chapter of this document. Email encryption solutions use either certificates (S/MIME or application specific) or comparison of checksums.

In this release of EndCryptor users can compare checksums to detect the attack.

When Alice and Bob start communicating with EndCryptor they both send their own public key packets to the other person. This can be done e.g. as an attachment in normal email. After this they can exchange encrypted emails. Note that the sender must have receiver's packet and the receiver must have sender's packet. The packet contains e.g. signature verification public keys by which a receiver can verify that an encrypted email is from the claimed sender.

If Mallory can modify the public key packets during their transmittal then he can start the man-in-the-middle hadling and thus decrypt the messages. This can be detected via Contacts->Advanced->Test for MITM after some encrypted emails have been exchanged.

Now when at the beginning the public key packets are exchanged this must be done only with reliable other party. After all senstive information is going to be exchanged in encrypted messages. One must be sure that the other party is whom he/she claims to be and e.g. that the email address is the same as before and clearly belongs to the person and the organization in question. When a contact has been created its email address cannot be changed until some encrypted emails have been exchanged.

Note that if there is some group of people who need to use EndCryptor their public key packets can be zipped into one archive and this can be distributed securely (via protected website/file transfer) to members of the group. When a member receives the zip file it is dropped into EndCryptor and new contacts are automatically inserted.