Cryptography Concepts

In this section you'll learn details about the basic cryptography concepts which Virgil products are based on.

In cryptography, encryption is the process of encoding a message or information in such a way that only authorized parties can access it and those who are not authorized cannot. Encryption does not itself prevent interference, but denies the intelligible content to a would-be interceptor.

In an encryption scheme, the intended information or message, referred to as plaintext, is encrypted using an encryption algorithm – a cipher – generating ciphertext that can be read only if decrypted. An encryption scheme usually uses a pseudo-random encryption key generated by an algorithm. It is in principle possible to decrypt the message without possessing the key, but, for a well-designed encryption scheme, considerable computational resources and skills are required.

An authorized recipient can easily decrypt the message with the key provided by the originator to recipients but not to unauthorized users.^[1]

Symmetric-key encryption^[a] is when the same cryptographic key is used for both encryption of plaintext and decryption of ciphertext. The endpoints will either have duplicates of the key, or they will pass the key back and forth.^[1] The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link.^[2] This requirement that both parties have access to the secret key is one of the main drawbacks of symmetric key encryption, in comparison to public-key encryption (also known as asymmetric key encryption), because the key must somehow be shared secretly.^[3][4]

Public-key cryptography, or asymmetric cryptography, is a cryptographic system that uses pairs of two distinct keys: a public key which may be disseminated widely, and a private key which is known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions.

Effective security requires keeping the private key private, but the public key can be openly distributed without compromising security.^[1] In such a system, any person can encrypt a message using the receiver's public key, but that encrypted message can only be decrypted with the receiver's private key.

In an asymmetric encryption system, public keys can be widely and openly disseminated within a network of users. A public key is like a mailing address in that each user’s address can be seen publicly and senders will look up a user’s address to direct a message to a certain recipient. After looking up the public key,the sender scrambles the plaintext into ciphertext (or “encrypts” the message) in such a way that only the recipient’s corresponding private key can unscramble the ciphertext back into plaintext (or “decrypt” the message).

In a chat application, when Alice wants to send 'Hello' to Bob, she encrypts her plaintext message with Bob's public key and sends it to him.

To make asymmetric encryption system work, there has to be a central organizing party or system to make the public keys available to all participants, and ensure that the public keys and private keys work together, like a PKI.

With Virgil Security, the Cards Service is this central organizing system that to securely stores, catalogues and distributes the public keys of end users.

In an asymmetric encryption system, private keys, unlike public keys, need to be kept secret in the user's device. They are used to unscramble ciphertext generated by the corresponding public key into plaintext.

In a chat application, when Bob receives a message from Alice, he decrypts the ciphertext message with his private key and reads it.

Because anyone with the private key can decrypt a message encrypted with that private key's public key, the strength of an asymmetric encryption system depends on how well the private key is protected from unauthorized access. Only the end user should have access the private key, and not the system developer or any other party. It should be generated on the user’s device and plaintext private keys should not be stored within any system or database that also contains any data that was encrypted for that private key. There can be no proverbial “backdoor.” access to the private key for anyone. With Virgil Security’s zero knowledge system, the end user’s private key is generated locally by the Virgil SDK on the user’s device upon sign-up or sign-in, and will remain stored locally on that device. This allows a user to decrypt encrypted data on this device where the private key is stored.

End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from seeing the plaintext data because they do not have access to the private key needed to decrypt the conversation.^[1]

In many messaging systems, including email and many chat networks, messages pass through intermediaries and are stored by a third party, from which they are retrieved by the recipient. Even if the messages are encrypted, they are typically only encrypted 'in transit', and then either stored in decrypted form by the third party or if they are encrypted, the key is stored in the same database, making unauthorized access possible. Even with a strong combination of at rest and in transit encryption, there are always gaps along the way which leave the message data exposed in plaintext.

Storage providers justify this weak security in order to provide search and other features, or to scan for illegal and unacceptable content, but it also means they can be read and misused by anyone who has access to the stored messages on the third party system, whether this is by design or via a backdoor. This can be seen as a concern in many cases where privacy is very important, such industries with strict regulatory compliance obligations, users living under repressive governments, whistleblowing, mass surveillance, businesses whose reputation depends on its ability to protect third party data, negotiations and communications that are important enough to have a risk of targeted 'hacking', and where sensitive subjects such as health information about minors are involved.

End-to-end encryption is intended to prevent data being read or secretly modified by anyone other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipient retrieves the encrypted data and decrypts it themselves.

End-to-end encryption is the base feature of all of E3Kit's encryption methods except Temporary Encryption. Learn more about end-to-end encryption with E3Kit in this article.

A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), that the sender cannot deny having sent the message (non-repudiation), and that the message was not altered in transit (integrity).^[1]

Digital signatures are a standard element of most cryptographic protocol suites, and are commonly used for software distribution, financial transactions, contract management software, and in other cases where it is important to detect forgery or tampering.

With Virgil Security, in addition to encrypting and decrypting data, it's possible to sign data digitally before sending in a way that recipients can verify it, thereby adding an additional layer of strong security to your application.

Digital signature is supported by all of E3Kit's encryption methods except Stream Encryption and Temporary Encryption.

Adding Perfect Forward Secrecy (PFS) to your encrypted communication prevents a possibly compromised long-term secret key from affecting the confidentiality of past and future communications. This is only supported by E3Kit's Double Ratchet Encryption method.

Multi-device support allows you to share private keys between multiple user devices (both smartphone and browser) in order to allow users to access their encrypted messages and data. This functionality is present in all of E3Kit's encryption methods, except Double Ratchet Encryption, due to its increased security measures.

Multi-recipient support allows you to encrypt a piece of data once and define multiple users that can decrypt that data instead of encrypting for each recipient individually. This functionality is present in all of E3Kit's encryption methods, except Double Ratchet Encryption and Temporary Encryption.

Access to History allows users to be added to an encryption group and have access to data that was encrypted before they joined. This is only supported by E3Kit's Group Encryption method.

Unregistered Recipient Support allows encryption of data for recipients that have not yet registered with E3Kit, and therefore do not own a cryptographic key pair. This may be useful during a transition period where some users of your App have not yet downloaded its end-to-end encrypted version, or you want to allow encryption for users who haven't registered with your App at all. This is only supported by E3Kit's Temporary Encryption method.

Data stream support allows for encryption and decryption of data streams. This is useful when the size of data is too large to be encrypted or decrypted all at once. This is only supported by E3Kit's Stream Encryption method.