Security Improvements
Right now the encryption system is based on asymmetric key encryption using RSA 4096. Since this is good for several reasons (highly audited, no public records of being broken, etc.) it has some drawbacks:
- MITM or Man in the middle attack where a bad actor may be able to intercept our communications and therefore intercept our public/private key pair and generate their own. This way while we think we are encrypting the messages using the public key of the destination address in reality we are using the public key of the bad actor and he is re-encrypting all the messages to the destination.
- Forward Secrecy: All the encryption relies on the same private key, so if someone is eavesdropping our communications and somehow is able to get our private key it will be able to decrypt all the messages sent from the beginning since all of them are encrypted with the same key.
- Deniable Encryption: The current system doesn't offer the possibility of plausible deniability, in this case would be the possibility to deny the content of a given message.
Due to the asynchronous type of communication we're dealing with here, there are no easy solutions for any of these problems. However, we'll try to minimize them as much as possible.
Avoiding a MITM attack is practically impossible. Since we don't have a trustworthy communication channel we can't be completely sure that the public key we get for encryption is real or not. The only way to be sure of it is by using an out-of-band channel to compare the keys.
However, in order to minimize this problem, we could not trust only one keyserver but at least 2 of them. So when asking for the public key of our destination address we need to ask at least 2 different keyserver nodes and trust the key if it's the same in both of them. If it's not the same we should query another keyserver and expect at least 2 of them to have the same key.
This could minimize the problem if one keyserver has been compromised but it will not fix the problem if our network link is compromised. So, in addition, we should add a way to compare the key side by side in a meeting or by phone call.
As explained above, using the same key to encrypt all the messages is not good. If the private key gets leaked or obtained all our communications will be exposed.
...to be continued
This one is tricky. In this context may not be possible to deny having received a message since there could be some traces left on the mailserver that could expose it. In order to do that there should be a system where a different content would be revealed if you are forced to give your keys.
...to be continued
