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

[Kent Borg]

On 2/14/21 1:28 AM, John Gilmore wrote:
>
> 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.

One-time pads have a really nice simplicity about their security. Simple 
is good.

But OTP key management is still hard. Something tells me back in the 
days of one-keys being on a "pad" of paper the hard part wasn't compact 
storage, but all the other issues surrounding it:

- Generating random key material.

- Transporting it in secrecy.

- Maintaining secrecy at it's destination.

- Securely destroying used key material.

- Not accidentally reusing key material.

The OTP core might be simple, but the whole system surrounding it in any 
real deployment is *not* and in that complexity will lie security holes. 
All of that complicated stuff has to be done right or the simple 
provable security of OTP is out the window

Move to now, and the availability of dense flash storage…doesn't solve 
those problems. Automating the solution to some of those problems by 
doing something called "programming" it might help, assuming the 
programming is done correctly. Can we assume that? No. Which means the 
simple provable security is out the window.


Moving OTP into the modern world seems to be trying to solve one of the 
smaller problems out there. We see security holes all the time, I worry 
about information security a lot, but I don't worry that AES-256 is 
weak. Who has the time? There are too many other holes in our systems to 
worry about first, well before we should get around to worrying about 
the security of a well chosen, well designed cipher. Modern ciphers are 
good, there are real options to choose from. Even old DES, which has 
been long known to be something to avoid, has held up well: slap it in 
in a triple mode and we still get over a hundred bits of symmetric 
strength, don't we? Current block ciphers learned from DES' design, it 
seems the least of our worries.

I'm sure swapping in a one-time-pad could be done, but I don't see that 
it would be worth it, nor would be a net security win. I would advise 
"financial traders, diplomats, spooks or black marketeers" to avoid such 
an innovation and stick with more tested systems and implementations.


-kb


P.S. If I were a crook seriously worried about cipher strength I would 
do something manual, disciplined, and unorthodox. Maybe superencrypt 
with an unrelated key, through an unrelated cipher, from an independent 
implementation. (Do respected stream ciphers still exist?) Even if my 
concatenation offered no theoretical benefit (simple concatenating of 
DES doesn't, that's why triple DES is so strange), it couldn't hurt, and 
it might have a practical advantage: Some imagined NSA bulk, class break 
of AES-256 wouldn't work against this without a tailored effort.

But the real benefit of the extra manual encryption would be to protect 
against some security hole in the first program that has nothing to do 
with whether AES-256 has any flaws.

Crucial is:
1. manual concatenation, of
2. an unrelated implementation, of
3. a different cipher, with
4. an unrelated key.