[Cryptography] One-time pads in modern crypto software?

Kristian Gjøsteen kristian.gjosteen at ntnu.no
Sat Feb 20 08:00:09 EST 2021

14. feb. 2021 kl. 10:28 skrev John Gilmore <gnu at toad.com>:
> I continue to be surprised that nobody has put support for one-time pads
> into TLS.  For the small subset of people who want higher reliability
> security, it would be straightforward to run standard protocols for web
> and email and DNS and such, but with OTP keying rather than depending on
> possibly breakable mathematics or quantum theory.

It is in general straight-forward to build a version of TLS that uses OTP for confidentiality and a one-time MAC for integrity. There are a lot of details, but it is not theoretically challenging. If you do it right, denial-of-service attacks will not exhaust your key material.

Should anyone do so? I can’t see why.

First, there’s no point. There has never been an attack on any system that has amounted to a cryptographic attack on AES (as far as we know). We’ve seen cryptanalytic attacks against other ciphers, but these have in general been known to be weak well before the attacks were developed. We have seen attacks against parameter sets that were known to be weak, but no attacks against reasonably current parameters sets (with respect to cryptologic consensus, not standards). There isn’t much reason to worry about the computational security of AES, at least if you use the 256 bit version. Quantum computers may happen this century, but wide-spread quantum-safe cryptography seems plausible this decade. (Yeah, reasonable people could argue that information theoretic security is anyway better than computational security, so feel free to ignore this.)

Second, information-theoretic cryptography exacerbates the engineering problems we already have. The attacks on GCM-AES and similar constructions that we have seen discussed here lately, almost always reduce to either key management or nonce management. While these problems are theoretically simple to solve, it turns out that this is not easy to solve for engineers, even engineers allowed to develop security-critical code such as TLS code. The key and nonce management problem for information theoretic security, especially in a TLS context, is much more difficult theoretically. Is it reasonable to expect the engineers working on specifications and implementations of an information-theoretically secure TLS to succeed here?

Third, computational cryptography provides security that we want, and that information-theoretical cryptography cannot provide. There are, in some sense, roughly speaking, two sorts of key compromise: one where the adversary is interested in what you did, and one where the adversary is interested in what you will be doing. Theoretically, it is fairly easy to defend against the former in an information-theoretic setting, simply by erasing your key. Theoretically, it is also easy to defend against the latter compromise under computational assumptions. This is not possible information-theoretically, I believe. Practically, reliably erasing large amounts of key material is difficult with modern computer hardware (without using a good blender). Practically, modern key exchange schemes are designed to defend against both forms of key compromise, up to impersonation, and my (vague, uncertain) impression is that engineers are capable of using key exchange schemes correctly. Theoretically, evolving keys can be used to defend against some impersonation attacks (it is theoretically impossible to defend against some attacks, but such attacks can to a certain extent be detected). Practically, I would worry about your average implementation of evolving keys, in particular in a TLS setting.

In other words:
* We don’t need information-theoretic security.
* We can’t implement information-theoretic cryptography correctly.
* We want security that information-theoretic cryptography cannot provide.

PS. There may be highly specialised applications where information-theoretic security may be appropriate. But I suspect these applications can make do with simpler protocols than TLS, and I would certainly not involve standard e-mail software in such applications.

Kristian Gjøsteen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210220/d8add6f5/attachment.htm>

More information about the cryptography mailing list