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

Peter Fairbrother peter at tsto.co.uk
Wed Feb 17 10:54:22 EST 2021

On 17/02/2021 06:03, John Gilmore wrote:

> 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.

Yep, but all these are almost trivially solvable, eg the challenge is 
just some length of pad. Get it wrong, the message is ignored - get it 
right, that length is not used for anything else. Also good for sync.

The hard problem is secure deletion.

Reusing a SD card is a no-no, some of the old data will be retained in 
"unused" sectors. A similar problem occurs once the pad is on a device.

Peter Fairbrother

More information about the cryptography mailing list