Secure channel creation in cryptography

In cryptography, there are two ways to create a secure channel between two parties:

Olvid essentially uses the second one in its free version. In any case, Olvid never imposes any trusted third party.

#1. Rely on a trusted third party

The first method for creating a secure channel is to rely on a trusted third party. This method is very frequently used:

  • The TLS protocol, for example, is essentially based on the use of certificates, issued by a certificate authority, which acts as a trusted third party.

  • The S/MIME email encryption standard also relies on certificates issued by certificate authorities.

  • The vast majority of secure (end-to-end encrypted) instant messaging applications use this architecture, each acting as the certificate authority.

This architecture has the advantage of making security completely « transparent » to the end user. On the other hand, security is centralized, exclusively ensured by the certificate authority. According to Wikipedia:

If the CA can be subverted, then the security of the entire system is lost, potentially subverting all the entities that trust the compromised CA.

This the reason why CAs follow good practices, such as Baseline Requirements necessary to be recognized by major browsers such as Firefox or Safari.

The special case of “secure” instant messaging

To our knowledge, no secure instant messaging (end-to-end encrypted) provides any security level guarantee as those required from Certification Authorities, even though they act as trusted third parties for billions of users. In practice, this means that all users of these messaging systems are unknowingly forced to trust a centralized directory operated by that messaging system, which acts as a trusted third party.

Olvid believes that imposing a single trusted third party on nearly three billion users makes absolutely no sense at all and provides only an illusion of security.

In other words, we believe that these messaging systems do not provide the security they claim to guarantee.

“If you build a system where everything comes down to trusting the server, you might as well dispense with all the complexity and forget about end-to-end encryption.”

Matthew Green, cryptography professor at Johns-Hopkins University, Wired

Or #2. Rely on the trust the two parties have in each other

The second method for creating a secure channel is to rely on the trust users already have in each other or, more formally, to rely on a pre-existing authentic channel between users. There are many cases in which this method is used:

  • The PGP encryption standard, mostly used for email encryption, but sometimes for file encryption, falls into this category. Indeed, when using PGP to encrypt email, you must first have received the recipient’s public key (typically via an unsecured channel), and have validated the fingerprint of this key. This last step is critical and involves confirming through an authentic channel (such as a phone) that the received public key fingerprint matches the fingerprint of the sent public key. This, in order to ensure that this public key has not been maliciously modified during its transmission on the non-secure channel. This validation is infamous, as it is optional (the encryption will work even if this validation is not done) and tedious (32 hexadecimal characters must be exchanged). It is very likely that a large part of users do not bother with this. One of the problems here is the important use that is made of the authentic channel: 32 characters to exchange is a lot in practice.

  • Some secure instant messengers (end-to-end encrypted) allow you to validate “by hand” that the public keys distributed by their centralized directory (see above) are authentic (in other words, that they have not been maliciously modified by the directory). Like PGP, a considerable number of characters must be exchanged over an authentic channel, typically 60 digits in base 10. We believe that the number of users performing this validation is marginal, as the operation is so tedious.

One of Olvid’s contact methods works on this principle. Fortunately, we have taken care to limit the use of the authentic channel to its strict minimum. In practice, users only need to exchange 2 × 4 = 8 digits on the authentic channel. This validation is extremely fast, which is why it is a mandatory prerequisite before any message can be exchanged. Olvid’s cryptographic protocols prove that the probability of a successful attack is 1 in 100 million.

Olvid will never allow you to create a secure channel with another user without the guarantee that it is their key that you received.