Qrypt offers solutions to make One-Time Pads, the only known information theoretically secure symmetric encryption algorithm, finally practical in industry.
A cryptographic algorithm is considered secure, when the algorithm has been around for several years, and there is still no known method to “break” the algorithm with a classical computer.
For example, the widely used RSA algorithm has been around since 1977 with no significant progress made on a method to break it with a classical computer.
With the age of quantum computers being on the horizon, researchers have also explored methods to break cryptography using a quantum computer. Post-quantum cryptography means that after years of research, there is still no known method to “break” the cryptography, even given a quantum computer.
For example, RSA, would not satisfy post-quantum security because Shor’s algorithm, an attack using a quantum computer, was discovered to break RSA in 1994. On the other hand, AES-256 is considered post-quantum because no quantum attacks have been discovered since its publication in 1998.
A One-Time Pad cipher is when a randomly chosen key, the same length of the plaintext, is XORed with the plaintext to produce the ciphertext. If the key is truly chosen randomly, all plaintexts of the given size are equally likely to have produced the ciphertext.
One-Time Pads have been mathematically proven to be information theoretically secure, meaning there is a mathematical proof that there exist no attacks (even with a computationally unbounded adversary) that can break a One-Time Pad. On the other hand, it is possible for a “post-quantum” algorithm to be broken, if in the future, someone were to discover a quantum attack on the algorithm.
One-Time Pads are only secure if the key is truly random, and only recent quantum technology has made truly random keys possible.
In addition, One-Time Pads are only secure if the keys are never reused. This means we need to share a newly randomly generated key, which is the same size of the plaintext, every time we want to send a new plaintext message. This reduces the security of the One-Time Pad down to the security of the key exchange algorithm.
To encrypt data at rest, we don’t need to worry about key exchange. There will either be a single party encrypting data on their device, or multiple parties who have physically distributed a truly random string X. The use case for the QDARA client is described in Section 5.1 of the whitepaper.
The Bounded Linearly Accessible String (BLAST) extractor (Yevgeniy Dodis and Kevin Yeo, 2021) is a cryptographic primitive that offers a stateless solution for multiple parties to extract a One-Time Pad given a truly random string X.
Given a pool of truly random numbers X, BLAST takes a seed S as input, and outputs a One-Time Pad R. The extracted R is indistinguishable from a randomly generated R.
See the whitepaper for more details about BLAST and a proof of its indistinguishability from random. Note that the whitepaper refers to BLAST as a doubly affine extractor.
Each encryption has three inputs: a plaintext, a key, and either an initialization vector (IV) or a seed. Decryption requires a ciphertext, the same key, and the same IV or seed to decrypt. The procedures are described in more detail in the Init, Encrypt, and Decrypt methods below.
Init (Encryptor):
Init (Decryptor)
Note: The user is responsible for storing the qrand and qcache files securely.
Encrypt
Decrypt
Having a stateless method of determining the One-Time pad from X makes it much easier for parties of 3 or more to communicate using the same random pool X. Instead of requiring all parties to keep track of an index which can easily get out of sync, it is much simpler to use a new seed for each encryption. Using BLAST also ensures that the One-Time Pad is never stored in the clear and offers additional security in case chunks of X are stolen.
We keep track of the percentage of X we have used in the cache file. Once the usage exceeds a user-configurable percentage (default set to 50%) of X, the user can no longer encrypt with X unless they use the –force flag. The percentage corresponds to 1-β in the whitepaper.
Although it is possible that BLAST uses the same bit twice in different encryptions, the whitepaper proves that the extracted One-Time Pad is indistinguishable from a purely random One-Time Pad as long as the total length of the One-Time Pads used is bounded by (1-β)|X|.
The seeds are encrypted with AES-256, and the encrypted seed is appended to the ciphertext. The AES key and IV are stored in the cache file.
Our QDARA client offers post-quantum security. An adversary can only gain secret information if they have access to both the full random string X (by breaking TLS when the user downloads X) and the seed S (by breaking AES). Since AES is a post-quantum algorithm, the client achieves post-quantum security.
Yes, after the ciphertext is encrypted with the One-Time Pad, we use AES-256 OCB mode to provide authentication with the seed as associated data. If the ciphertext is tampered with, the AEAD authentication will fail.
This depends on the user-configurable percentage α (default set to 50%), which is the maximum amount of random you can use from a cache. There are three constraints you must fulfill to encrypt a file of size m:
For example, to encrypt a file of 5 KB = 5120 bytes, with our depletion parameter set to α=0.5, we must:
Here is a table of minimum cache sizes for reference.
Plaintext Size | Minimum Cache Size |
---|---|
1 KB | 5 KB |
10 KB | 27 KB |
100 KB | 218 KB |
1 MB | 2103 KB (> 2 MB) |
2 MB | 4173 KB (> 4 MB) |
4 MB | 8301 KB (> 8 MB) |
For a random pool size of 10 MB, we have the following performance numbers which were collected on a MacBook (15-inch Mid 2015).
Plaintext Size | Time (seconds) |
---|---|
1 KB | 0.06 |
10 KB | 0.25 |
100 KB | 5.80 |
1 MB | 203.12 |
2 MB | 600.56 |
4 MB | 1673.12 |
Qrypt offers a novel key exchange solution, (Section 5.2 of the whitepaper) which offers everlasting security.
Algorithms | Level of Security | Drawbacks |
---|---|---|
RSA, Diffie Hellman, ECDH | Classical security |
|
Classic McEliece, CRYSTALS-KYBER, FrodoKEM | Post-quantum security |
|
Quantum Key Distribution (QKD): BB84, E91, B92 | Information theoretically secure (dependent on accuracy of hardware) |
|
Qrypt solution | Everlasting security (explained below) |
|
A protocol which achieves everlasting security guarantees that an encryption is information theoretically secure, given that the initial key exchange of the seed S is not broken within a time T which we can choose (i.e. a week). This means that a week after the two parties exchange an initial seed S, even a computationally unbounded adversary (with access to both classical and quantum computers) cannot break the encryption.
Classical security that is vulnerable to quantum computers (i.e. RSA, ECDH)
Post quantum security that has no known algorithm that quantum computers could run to break (i.e. FrodoKEM, Crystals-Kyber)
For levels 1 and 2, to break the encryption, an adversary would need to:
3a) Everlasting security which is provably secure against an unbounded adversary after phase 1 (while the server is still accepting decryption requests), where:
3b) Everlasting security which is provably secure against an unbounded adversary after phase 1 (while the server is still accepting decryption requests), where:
3c) Everlasting security which is provably secure against an unbounded adversary after phase 1 (while the server is still accepting decryption requests), where:
For levels 3a, 3b, and 3c, to break the encryption, an adversary would need to:
Our SDK offers:
Level | Qrypt offering | Data Harvesting | Key exchange for seeds/symmetric keys | Protocol for downloading random |
---|---|---|---|---|
Level 1 (classical) | QDEA classical SKU | Adversary needs to harvest data from only one network transmission | ECDH (classical) | N/A |
Level 2 (post-quantum) | QDARA, QDEA post-quantum sku | Adversary needs to harvest data from only one network transmission | Lattice crypto (PQC) | N/A |
Level 3a (everlasting security) | Digital QKD with user-supplied channel | Adversary needs to harvest data from:
|
ECDH (classical) | Classical TLS |
Level 3b (everlasting security) | Digital QKD sample | Adversary needs to harvest data from:
|
Lattice crypto (PQC) | Classical TLS |
Level 3c (everlasting security) | -- | Adversary needs to harvest data from:
|
Lattice crypto (PQC) | Post-quantum TLS |
Level 4 (information theoretic security) | -- | Adversary needs to steal physical devices | Physical transfer | N/A |