The One-Time-Pad or OTP is the one and only true mathematical unbreakable encryption scheme because it provides entropic security. The question is if OTP will provide protection when a quantum computer is used to do cryptanalysis.
Absolutely. Claude Shannon rigorously proved in his 1949 ditty “Communication Theory of Secrecy Systems” available here, that a kosher OTP is secure even against infinite adversarial computing power. But we don’t need that rigour as it’s quite intuitive. If the random key is as long as the plain text, all possible decryptions are equally likely. Therefore a quantum computer (or any other) will still not be able to determine which is the correct message.
AES256 is still considered to be unbroken.
We don’t know it’s unbroken with complete certainty. US NOBUS policy and the incessant drive towards a dangerous cryptographic mono-culture suggests that there is a non minimal probability that it is already breakable, perhaps even in real time.
Although there are attacks against AES, like the biclique attack, it is still considered hard enough. Biclique does not immediately melt away AES. The problem with AES is more in usage. For instance, creating a key and never change it for years or use a key generating protocol that makes keys predictable. If someone would generate a key from a time string, this would result in a dreadful situation where theoretical security is very high but practical security is broken. In normal life, this happens all the time. So not the algorithm it self is broken but the circumstances where it was used in. OTP could protect against these cases because it is using a new unique cipher stream for each message.
The key cannot leak because there is simply no key.
Well there is the OTP key material that has to be safely stored.
The structure cannot be broken because there is simply no structure.
But only if the key is truly random and the raw entropy is generated by physical processes. Quantum indeterminacy proves that.
Now let’s look into the properties and conditions of OTP. I will split some obvious conditions to deal with them separately. Let’s call them the Ox-Conditions for short:
Condition 1: The key stream must be truly random. Condition 2: The random key stream should be free of anomalies Condition 3: The random key stream must be unpredictable. Condition 4: The key distribution must be proven secure Condition 5: If any deterministic algorithm is used, it should not be possible to influence the output.
Condition 1 means you must have a True Number Generator (TRNG). That sounds more difficult than it is in fact.
Yes; REALLYREALLYRANDOM.com is testament to that fact.
You could build one using light, heath, or a semiconductor that will produce certified noise but it will never be NIST certified. (But that is obviously not what you want) If it is truly random, or not, can be measured and certified.
Why would you want NIST certification, other than for commercial sales into the US market? Britain’s ERNIE is not NIST certified. German/Swiss devices aren’t. Our Zenerglass isn’t. We’re pretty certain that China’s domestic encryption devices aren’t. Entropy generation is a physical and mathematical process that continues daily without any US involvement. America First doctrine does not apply to entropy. It is easily categorised and analysed on a small laptop using well know techniques. They are documented on this site. NIST is not the bringer or arbiter of probability. Indeed there is a mountain of evidence that it actively opposes, impedes and undermines the creation of TRNGs. See conspiracies.
If you have certified noise you are still not done. It’s random, anything can happen. On a very bad day, you could have a cipher stream like ”00 00 00 00 00 FF FF FF FF FF” just by sheer coincidence.
This sequence occurs naturally with a probability of 827 x 10-27. Or every four million years from a 10 Gbit/s commercial TRNG.
That could ruin your secrecy, your day and even your life if you are a spy depending on it. Condition 2 states that you must monitor anomalies and if that happens and handle it.
“00 00 00 00 00 FF FF FF FF FF” is not an anomaly. It’s the face of randomness. It shouldn’t be handled other than to perform statistical checks that the entropy source has not frozen, which is pretty much unlikely in simple DIY constructs. ‘Handling it’ results in randomness degradation and before you know it, you’re only selecting the sequences that feel best to you.
Condition 3 is even more important than condition 1 and 2. You could have perfect random noise certified and with a golden label on it but if it is still predictable it will blast your security into oblivion. This happens for instance when “perfect noise” is looped. Gambling machines in Casino’s use this trick. Some gambling machines have been cracked because a smart guy found out about the loop in the random pattern. You should always generate your own random keystream. No one should give it to you. The Google number generator or ERNIE may be producing certified random noise for sure, but who gets which random noise? If random noise is known by a second party, it is predictable and this leads to a full security compromise. Remember that it is always your noise and your noise only.
Sounds like ‘Secure entropy? Your entropy.’ A perfect reason to build your own devices.
Condition 4 is where the real trouble begins. Large quantities of keystream data must securely be distributed to the client who than deciphers the message. It is possible to build an application with 1Gb of pre-shared keystream data but it is highly impractical. We have the holy grail of quantum resistance but it is not used because of this very unpractical condition. This is the major disadvantage the perfect OTP has.
Our DIY Null Gamma Device which is based around a Raspberry Pi can generate 1 GB of key material in ~14 minutes. A SanDisk Cruzer Glide 16 GB USB Flash Drive costs £5 and can hold 100 million Tweet sized keys. You can post the key material if you don’t deliver it personally. They don’t check the post if you’re at the start of your activities and off the radar. Please do not make the all too common mistake that OPTs are used for encrypting 4K UHD movies. They should only be used for strategic communications as they always have been. That is their raison d’être and why they’re still in use.
Now we are talking about the real problem.
Because condition 4 is so impractical, software developers use something that is called: “scaled entropy”. And that is where all trouble starts. If I have a function f(x) that has a very chaotic behavior like elliptic curves, I could turn the chaotic result into a hash and use that hash as a keystream. The value x is then producing a large bunch of “noise”. The key value of x must be shared with the client and he gets the same noise and can decrypt the message. Of course, this is far from any real random generator and violating condition 1. The value x could be 256-bit key. It will produce a matrix of noise in a deterministic way and cryptanalysis might not even be able to detect any flaws in it. But besides condition 1 it also fails condition 3, it is predictable because an attacker might have a clue on what input values are used and when. FinalCrypt likely does something similar. I have no clue how they generate random noise but it is probably a function.
Yes it is. See our cryptographic assessment of FinalCrypt here.
If new noise for OTP keystream data is sent by quantum entanglement to both participants, it would pass condition 4. This is not a very practical nor very cost-effective way at all since equipment to generate entangled particles requires Lithium niobate and highly sophisticated equipment.
Whilst currently out of reach for DIYers, you can simply buy a quantum key distribution network off the shelf like these.
But I can assure you that OTP will be used in exactly this way in the near future when this will be commercially available because the power of OTP is irreplaceable.
Now we come to condition 5. If 2 participants want to use OTP and need to have the same keystream, they need to have something deterministic that produces the same keystream. Two synchronized real number of generators would be best.
This is exactly what a QKDN does.
But since God alone plays with entropy, this is not something we could easily establish….. A function is the next best thing most people can come up with. NSA’s elliptic curve based “random” generator cheerfully fails condition 5 like all other pseudo number generators. Luckily crypto community understands this and won’t tolerate this again.
The availability of OTP is of great importance for our future. Because without OTP we are back at AES. There is nothing wrong with AES itself, but there is something wrong with keeping an AES key for some time.
You don’t need to. You can replicate the principle of a QKDN encryptor unit. By sharing an extant store of OTP key material, you can rotate your AES keys every few minutes. This allows you to effectively increase the OTP material by orders of magnitude. Assuming you trust AES.
Hardware could leak parts of this key by use of a side channel. Then the strong AES encryption becomes weak to be cracked. Please understand that these side channels are undetectable and that is exactly why people fear using the Huawei equipment. Think of a very well hidden side channel by swapping IP packets in a specific order or by introducing transmission errors that will be corrected anyway by CRC mechanisms. This is the power of OTP. Hardware side channels become futile.
Side channel insecurity is a red herring most of the time for DIY TRNGs. People forget context. The attack surface for a Dangerous Box is nothing like that for a nation wide deployment of smart cards, or the open source
/dev/random living alongside myriad closed source programs and PornHub feeds. It is comparatively tiny and much narrower in scope. Especially if your operations are off the radar. This is a crucial argument that non enlightened theoretical cryptographers seize upon as it’s a soft target. Don’t let people who have never built anything frighten you!