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

[John Gilmore]

Phillip Hallam-Baker <phill at hallambaker.com> wrote:
> TLS would seem like a poor choice, a messaging layer approach like S/MIME
> would be a better fit.

My guess is that about 10,000 times as many emails get encrypted via
TLS, as via S/MIME.  Just counting the mail flowing between Gmail and
Outlook!  And TLS secures many more things besides email -- not just the
web, not just email, but DNS, WebRTC audio and video, etc.

Once it is debugged and working in TLS, then sure, add it to WireGuard
and SSH and S/MIME.  Or do one of those first.  The hard part won't be
the protocol work.  It'll be the user interface automation that makes it
easy and somewhat secure, on both client and server machines, despite
the unavoidable vulnerability of having past and future one-time-pad
keying material lying around in an insecure OS's file system.  In your
Android phone.  In your cloud server provided by a third party.  Etc.

All of those services (TLS, WireGuard, SSH, etc) should use compatible
and interoperable local storage for the keying material, probably
through a common library.  (Partly so that they can be upgraded to using
better-secured hardware storage if and when that's available.  And so
they won't reuse each others' random bits!)

> And who knows if it hasn't happened already.

It's certainly not standardized in draft or issued RFCs.  Want to help?

> The big problem technically would be conserving your supply of one time
> material. You have to exchange that out of band if there is going to be
> security.

Let's not be stuck in 1990s thinking.  Moving terabits from one place to
another is not as big a problem as it used to be.  A courier can fit
many dozens of terabits in their socks on microSD cards without getting
a limp.  A single tiny card holds 8 terabits for $200, reusable hundreds
of times.  On less dense cards it's cheaper, about $120.  However,
you're right that one simple method of attack would be Denial of Service
by flooding the participants with traffic that purports to come from the
other end, causing them to eat up their reservoir of one-time bits in
decoding bogus gibberish.  What protocol and UI work would make that
harder to do?  Should we design it so that purported traffic must
contain a random challenge that will cause the recipient to NOT consume
any of their local pad if it doesn't match?  How is THAT challenge
secured without using vulnerable algorithms?  How do we manage to keep
the pads on both sides of a long-term (months) intermittent connection
in sync?  How do we absolutely prevent any portion of the pad from being
re-used ever (c.f. Venona)?  Etc.

> For most of us, 'one time pad' is a sure fire sign of
> crypto snakeoil.

Y'mean we would actually have to examine products to see if they were
secure?  Rather than come to a snap judgment based on their name?  ;-/

	John