Dual key exchange
In order to safely share data (like a secret key), we need some way to do this without an evesdropper being able to find out the key as well.
One way is to use asymmetrical cryptography, where a user has a private and public key part. What you encrypt with the public part, can only be decrypted by the private part. So for instance, Alice can get Bob's public key, encrypt a secret with it, send it over. Everybody can read this message, but Bob and ONLY Bob can decrypt the message, as only Bob's private key is capable of doing so.
Another way is to use Diffie-Hellman key exchange. Again with the help of a public/private keypair, we can share a secret. Normally, this secret is static, as the keypair for Alice and the keypair of Bob always result in the same secret. A benefit of this key exchange is that it's very fast, and uses less bits even though security is the same (or better) than with the current RSA key lengths used.
In order to combat this static key, we use a dual key exchange. This is an algorithm adapter from the one used in Monero crypto currency to generate stealth wallets (which in a sense are public keys as well).
Instead of creating a secret with Alice and Bob's keys, we create a secret based on a random key and Bob's key. The random key is a key that is generated by Alice. Bob can use this random key and its own private key to come to the same secret as Alice.
Now, we come to a problem: how do we send over the random key?
We do this, by a dual key exchange:
- First, we generate a random key r (r is the private part, capital R is the public part)
- Then, we do a key exchange with Bob's public key. This gives us a secret, we call D.
- Then, we hash this secret and generate another keypair with it. We call this keypair f (and capital F for the public part of it)
- Then, we send the following information to Bob: F and R.
Bob will do the following:
- First, Bob does a key exchange with the Bob's private key and the R. This gives us the secret D' (d-prime). Basically, this is the only thing we need, but we cannot be sure this is correct (since R is plain-text, it could be tampered with, for instance)
- Next, Bob hashes the D' to compute f' (and thus also capital F', the public part).
- Finally, Bob does a test to see if F matches its F'. If this is true, the R has not been tampered with, and the D' is the actual secret.
Since nobody can generate D, except Bob, we are sure that the key is exchanged safely. By checking F against our own calculated F', we are certain that nobody has tampered with the R, giving you a false key.
In BitMaelum, the F and the R are two 32byte numbers which are concatted together to from a 64byte number in hexadecimal representation. We call this number the "transaction ID" (as this changes on each mail transaction).
What we have achieved now, is a relatively simply setup where we share non-deterministic secrets between 2 static keypairs.
With PFS, it is not possible to decrypt PREVIOUS messages even when the private key is exposed. However, NEW messages can be decrypted but we assume that after a key expose, a key rotation will follow and the old key is not used anymore. However, this system relies on the fact that communication between 2 parties work with a temporary key that is removed as soon as the session/transfer is completed.
It's important to understand that Perfect Forward Secrecy (PFS) is something that cannot really be achieved within the current infrastructure. One of the reasons for this is that there need to be a direct communication between the sender and the reciever. In BitMaelum, everything is relayed between 2 (or more) message servers. Futhermore, messages will rest in encrypted form on the recipient mailserver, where it can be downloaded to a client (or multiple clients), and even at later stages (for instance, on a new computer or phone). In order to decrypt these messages, the private key is needed, so when this private key is exposed, we can decrypt ALL messages.
