[Cryptography] New White Paper: GhostLine - Information-Theoretically Secure Multi-Party Chat

[Ray Dillinger]

On 1/5/26 7:58 AM, Patrick Chkoreff wrote:
>
> That led me to consider other possible ways of generating a _static_ 
> large OTP deterministically up front, but safely so that the knowledge 
> of one block of key material does not allow you to infer the 
> subsequent blocks.  Clearly a hash chain is the worst possible scheme 
> in this regard.
>
Okay, first thing.... I'm going to quit using the phrase "one time pad" 
here, because what you're proposing is actually a stream cipher.  Any 
stream you can generate deterministically is the key stream of a stream 
cipher, not a one-time pad.

Cryptographic hashes are easy to run but hard to reverse. If I'm looking 
at a block and I know that the next block is SHA256 hash of it, it takes 
a blink to calculate that.  But if I'm looking at a block and I know 
that it's the SHA256 hash of the next block, I have no simple or easy 
way to calculate that next block.

You might think this means that you can generate your secure keystream 
by running SHA256 to get the previous block, rather than running SHA256 
to get the next block.  Unfortunately this is false. It just reverses 
the direction that someone can read from when they get a known-plaintext 
block. Because even if reversing the direction gives him no way to 
figure out the next block, it's just as destructive to your security if 
he can figure out the previous block. He is then able to decipher all 
the enciphered material previously transmitted.

There is a way to get a more secure keystream using a hash function, but 
it has to have a state size that's several times the size of your 
blocks.  Have a 512-bit state. Run SHA512 to get the next state. Then 
use 128 bits of each state as a keystream block, and now your opponent 
has not enough information to easily verify or falsify their guesses.

> But you could devise a scheme where you would have to know the 
> original 256 bit true random key/seed itself to derive any block of 
> key material, including tricks like encrypting a counter and such. 
> Clearly this is just reinventing stream ciphers, which often (always?) 
> rely crucially on a nonce to avoid this kind of fragility.

If you're talking about deterministically generating a key stream, you 
ARE talking about a stream cipher. The "nonce" is just the initial value 
of your state.

> My question originally arose in response to the GhostLine scheme of 
> actually *using* an OTP.  I was considering ways of generating an OTP 
> deterministically from a single 256 bit "truly random" seed. Clearly 
> using a hash chain is disastrously frail.

There are frailties we haven't even got into yet, which are why I 
suggested quadrupling rather than doubling the state size relative to 
the block size. Here's the next "weakness" of a hash chain: Different 
blocks can have the same hash.  That means when you go hashing a 256-bit 
state, sooner or later you hit a block that has the same hash as one of 
your previous blocks, and then you are on a repeating loop. That loop 
will be nowhere near 2^256 states long.  You can expect it to be about 
2^128 bits long or less, which means your opponent has 2^128 times more 
opportunities to get a sequence encoded by the same keystream blocks. 
This is why most stream ciphers handle their state by adding one to the 
state (or something that equally obviously cycles through all possible 
states).

> Again, I'm just thinking of ways to generate a strong OTP from "only" 
> 256 bits of entropy, which should really be more than strong enough 
> for any purpose -- as opposed to having to tap directly into quantum 
> turbulence or whatever to generate each of a billion blocks of key 
> material.

You can in fact generate a strong keystream (NOT a one-time pad) with 
256 bits of entropy.  That is in fact exactly what good stream ciphers 
with 256-bit keys do.

Even so, the classic XOR construction, whether for stream cipher or 
one-time pad, is ridiculously frail in many ways.  The central problems 
with both are that each bit of ciphertext corresponds to exactly one bit 
of plaintext, and your opponent knows which bit in the block each 
ciphertext bit stands for.  There are all kinds of protocol extensions 
and modes with checksums etc to try to compensate for that and prevent 
manipulations, but those are the central problems.

It takes 16384 bits to express a unique permutation of 256 bits, and 
that would solve the problem that the opponent knows which ciphertext 
bit stands for which plaintext bit.  Add 256 XOR bits to mask it, and 
now you're drawing 1940 bits of keystream for every 256-bit block. And 
you still have the problem that each ciphertext bit stands for exactly 
one plaintext bit.

Bear