I had a question about my research that I could not solve.
Let's look at an end-to-end form that uses RSA, Alice needs one hour to send her public key to Bob and vice versa to communicate, but if someone runs an MITM, security will be null, so Is the public key received from the sender really Bob / Alice? In case you do not ignore the message.
There is no easy way to do this, which is why in practice you use certificates and not simple key pairs. A certificate is:
Let's say Alice and Bob know each other, but they have never exchanged cryptographic keys with each other. At some point, someone claiming to be Bob tries to initiate a communication by showing a public key that he says is Bob's. Alice has no way of knowing if this key is Bob's unless she uses an alternate channel to confirm this fact (eg, calling Bob and asking him to say "fingerprint" - fingerprint - assuming of course that nobody can staple the phone and imitate Bob's voice ...).
Fortunately, both Alice and Bob meet Charlie, and both have already exchanged keys with Charlie. A way for Bob to prove to Alice that he and Bob are asking Charlie to confirm this to Alice. For example, sending a secure message to Alice where Bob's key is attached. This even works , but it's very impractical. A better option is to put Bob's key with the name "Bob" and ask Charlie to sign it, using his private key *. Charlie knows Bob's key, and he knows she belongs to Bob, so he can sign without problems. Bob can then send this to Alice, and Alice - knowing Charlie's public key - checks the signature and confirms that the key received from Bob actually belongs to him.
In this case, Charlie would be acting as a trusted third party: if Charlie lies to Alice by signing a certificate that does not belong to Bob ( ie the name "Bob" associated with Mallory's public key), does not have at first Alice's knowledge, and she would be vulnerable to a MitM. That's why it's important that Alice relies on Charlie not only for his integrity but for his ability to correctly identify someone before signing his key, and also to store those keys safely.
This is difficult to guarantee on a large scale, as it would require that each one be quite careful about all these aspects. For this reason, in most practical uses one chooses not to let anyone sign third party certificates ( Web of Trust ), but rather focus this task on a few organizations, called Authorities Certifiers ( Certificate Authority - CA). Measures are taken so that everyone knows the public keys of these CAs (for example, by distributing them in the Operating System itself), and everyone who wants a certificate is required to hire one of them to verify their identity and sign their key. / p>
This system is not perfect (just a CA having your private key compromised so someone can act on behalf of anybody else) but it's the one most used today (see # - Public-key infrastructure - PKI), for example when using browser to visit a site that has never been visited before - the certificate contains the domain name, a public key, and both signed by a recognized CA. In the context of an end-to-end, it may be undesirable to have to rely on a third party to verify the identity of the participants, but the only viable alternative would be to exchange those keys in person and / or use a communications channel alternative to assist in validation. Both very impractical, unfortunately ...
* Note: I said "key" to simplify, but in practice you should not use the same RSA key for both signing and encrypting - you need two key pairs per participant to perform secure communication using this algorithm.
