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

[Dennis E. Hamilton]

-----Original Message-----
From: cryptography
<cryptography-bounces+dennis.hamilton=acm.org at metzdowd.com> On Behalf Of
Jerry Leichter
Sent: Wednesday, February 17, 2021 06:38
To: John Gilmore <gnu at toad.com>
Cc: Bill Stewart <billstewart at pobox.com>; Phillip Hallam-Baker
<phill at hallambaker.com>; Cryptography Mailing List
<cryptography at metzdowd.com>
Subject: Re: [Cryptography] One-time pads in modern crypto software?

[orcmid] [ ... ]

There's room here for some new thinking, as we're changing underlying
assumptions.  Here's a trial balloon for a way to use a one time pad for
authentication:  Expand each bit of the plaintext into two bits.  The first
it the actual plaintext bit; the second is the plaintext bit XOR'ed with the
next bit of the one-time pad.  Encrypt afterwards with another one-time-pad
stream.  Or do the authentication on the ciphertext - in this case, order
shouldn't matter.

An attacker's chance of generating n bits that have the right pattern is
1/2^n unless he knows both plaintext and one time pad.

[ ... ]
[orcmid] This reminds me a little of "Perpetual Encryption," especially in
the fact that it makes the message longer.  I made some naïve observations
about this in the thread at
<https://www.metzdowd.com/pipermail/cryptography/2017-April/032044.html>.

Here is what I think the essence is.

The sender and receiver agree on a pseudo-random number generator, PRNG1.
It is known in advance and of course subject to analysis.

The first secret is a key that is conveyed between the sender and the
receiver.  This is from a *different* source.  The key is used to seed
PRNG1.  PRNG1 is then used to generate a bit count N and N bits of  a stream
cipher.  Having decrypted that much of the incoming stream, the value R is
also determined and the next R bits of the ciphertext are taken for use in
reseeding PRNG1.  Note that those bits are from a *different* source and the
recipient has no knowledge of how they are determined.  Rinse.  Repeat.

The R-bit reseed block might also be encrypted.  Might as well be.  Note
that N and R are determined from PRNG1 after each reseeding.  There also
needs to be a way to determine the end of a message and any authentication
that goes with that.

Bottom line, it is only the initial key that matters in some cryptographic
sense.  Dropped/altered bits in the ciphertext can be disastrous of course,
just as for any stream cipher.  And known-plaintext attacks still work, if
only to shrink search space on the initial key.  (Many persistent text forms
have predictable initial bits, whether an XML file or a ZIP package, etc.
That can be disrupted though, and the complexification may be important for
ciphertexts at rest.)
[/orcmid]