Olvid secure channels

---

Olvid will never allow you to create a secure channel with another user without the guarantee that it is in fact his or her key that you received

All messages, photos, videos, attachments, etc. sent by Olvid are sent via secure channels that guarantee everything you transmit via Olvid is absolutely authentic and confidential.

• You know who is writing to you. (Authenticity).
• You know what they wrote to you and that it could not have been tampered during the transfer. (Authenticity).
• And no one else knows what they are writing to you. (Confidentiality).

Secure channels used in Olvid are designed so that data & metadata are never transmitted unencrypted:

• Noone can ever know who you are discussing with. (Anonymity).

So you are also guaranteed of anonymity, on top of authenticity & confidentiality.

What is a secure channel?

In information theory, any information (or data) that is transmitted is transmitted via a communication channel. Cryptography is particularly interested in the security properties that a communication channel is able to guarantee for the information it allows to be transmitted. Several types of channels can be distinguished:

• Unsecure channels do not guarantee anything: neither authenticity nor confidentiality. This is for example the case of messages received by SMS and emails.

• Authentic channels (but not confidential) only guarantee the authenticity of transmitted information, but not its confidentiality. This is the case with the classic telephone channel: “everyone” can listen to you, but you know who is talking to you, and you have the guarantee that what you hear is what your contact said.

• Secure channels guarantee both the authenticity and confidentiality of information. On such channel, only the sender and the receiver can access the information (confidentiality), and the receiver has the guarantee that the data that arrives is strictly as it was sent by the sender (authenticity). This is a must. In other words, if you use a channel like this, you and the person you are talking to both know who you are talking to, and you know that no one but the two of you have access to what you are saying to each other. An example of this is a private discussion behind closed doors.

Beyond these basic properties, cryptography also defines more advanced notions, such as forward secrecy, which guarantees that the confidentiality property will always remain valid, even if a hacker manages (in the future) to steal your cryptographic keys. But we won’t go into details here!

Secure channel creation in cryptography

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

• The first one is to rely on a trusted third party.
• The second one is to rely on the trust the two parties have in each other.

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.