Tutorial on public keys

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. 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 this spying attack? We solve 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.

EndCryptor creates a lot of public keys. Each encrypted message contains new public keys of the sender. 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 solution those encrypted messages that the attacker has captured and the proper receiver decrypted prior to the attack cannot be decrypted by the attacker.

Please note that the attacker may have collected the exchanged messages and naturally after successful stealing of private keys tries to decrypt all of them. 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 by also calculating the cryptographic hash value and then using the corresponding public key the verification is done.

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

When two persons, Alice and Bob, exchange their first public keys they are very vulnerable. A third person, an attacker Eve can do the following:

Alice sends a key to Bob but Eve intercepts it and creates her own public key and sends it to Bob. Bob creates his public key and sends it to Alice but again Eve intercepts the key and creates another public key and sends it to Alice. Now Eve has done the public key exchange between Alice and Bob but they both think that they have only communicated with each other. When Alice encrypts a message to Bob then Eve intercepts it and decrypts it and then Eve encrypts it again for Bob. Bob receives the message and does not realize that it has been decrypted and encrypted by Eve. In this way Eve can see all the communication between Alice and Bob in decrypted form. Eve can also modify the communication.

This attack can be revealed if e.g. Bob calculates the hash value (checksum) of the public key (or a message) he received and compares it to the Eve’s public key’s (or message’s) hash value when it was created in Eve’s computer.

The attack can be avoided if there is a trusted third party that proves that a public key is a true public key of the person or entity in question. The certification authority infrastructure has been created to prove identities of persons, web sites and persons’ email addresses. When a certificate has been obtained from a Certificate Authority an attacker cannot pretend to be another person or a web site. Users have as preinstalled on their computers the public key of a Certificate authority and use it to check that the certificate which certifies a person’s or web site’s public key is a valid certificate.

The problem is that the certification infrastructure has weaknesses. It has been revealed that the man-in-the-middle attack is widely used by surveillance companies against users accessing web sites using https (SSL or TLS). The attack succeeds because a web browser has no way of recognizing a fake certificate from a true one. See The risks of SLL to get more information.

In EndCryptor the man-in-the-middle attack can be started when initialization files are exchanged.

In EndCryptor there are two methods to reveal the attack: one that uses the calculation of hash values and another one that uses the exchange of messages whose contents a man-in-the-middle machine cannot understand.

The initialization files can also be signed using user’s certificate. This makes the attack more difficult (but not impossible).

All received certificates are stored. The certification paths of certificates can be compared, allowed or denied – typically an organization’s certificates have only a limited number of different certification paths. A fake certificate used in an attack has a different certification path than previously seen paths in true certificates.

There is no documented case of man-in-the-middle capable machine/software against EndCryptor.

To compare EndCryptor to its competitors read the EndCryptor, S/MIME and PGP under attack page.

Last updated on May 11, 2012.

Home