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

- To form a shared secret
- To recover from attack
- To form a digital signature

Main attack types:

- Stealing of a private key
- Man-in-the-middle during key exchange

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.

This
solves 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.

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 a lot
of public
keys. Each encrypted
email after the first emails that use the long
term public keys contain new short term public keys of the sender.
These public keys are specific to the receiver in question.
When a
person whose private key has been stolen sends a new message 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.

There
is still
another problem: *how to protect old messages received prior
to the attack*?

Please note
that a person may have received several messages without sending new
messages and then the stealing of the private key happens. How to
protect these messages received between a Diffie-Hellman key exchange
and an attack? *The answer is a bit complicated and we give
here only the result:*

Using our patented solution those encrypted messages that the attacker has captured and the proper receiver decrypted prior to the attack cannot be decrypted by the attacker.

*More information about our solution can be found
on cryptographic technical details
page.*

Public
keys enable the formation of a **digital signature**.

Each message
has a digital signature as the last part of the message. The signature
is formed by first calculating the cryptographic hash value (checksum
or digest) of the actual message and then with the help of a *private
key* the digital signature is calculated and appended to the
end of the message.

The person who receives the message and the signature then verifies the signature with a public key and by calculating the cryptographic hash value of the message.

If the message or the signature itself has been modified by an attacker during traversal in the net then the signature will not verify – only the person who has the private key can create proper signatures which will verify correctly only by the corresponding public key.

This
solves the
problem: *how to prevent the modification of messages and the
falsification of the sender’s identity*?

**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.

To protect against this attack EndCryptor’s Web Directory stores user’s long term public key and email address. When the email address verification has been done the public key and the email address are signed by a public key which has a signature chain to public key that EndCryptor knows. When a user’s long term public key is fetched from the Web Directory or an encrypted email contains sender’s long term public key this signature is checked by EndCryptor. A user can check that the values in the Web Directory correspond to his/her email address and public key.

EndCryptor provides a method to reveal a man-in-the-middle attack after some messages have been exchanged: e.g. telephone conversation can be done to compare checksums. Also checksums at the start of the email exchange are stored into the database on user's computer and can be viewed any time later.