[Cryptography] One-time pads in modern crypto software?
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.
More information about the cryptography