[Cryptography] New White Paper: GhostLine - Information-Theoretically Secure Multi-Party Chat
Pierre Abbat
phma at bezitopo.org
Mon Sep 8 04:45:53 EDT 2025
On Sunday, September 7, 2025 6:42:56 PM EDT Ferecides de Siros wrote:
> Salut Pierre,
>
> Excellent questions! Merci for taking the time to examine the implementation
> so thoroughly.
>
> Here are the precise technical details:
>
> True Randomness:
> OTPs are generated from multiple cryptographically secure entropy sources:
> /dev/urandom on Unix-like systems (including Linux and BSD)
> Hardware TRNGs (True Random Number Generators) when available
> Entropy pooling from multiple hardware sources (RDRAND, noise-based RNGs)
> The initial OTP generation occurs during setup phase using CSPRNGs meeting
> NIST SP 800-90A standards
Shannon's proof of perfect security does not apply if you use /dev/urandom
(which continues returning numbers when it runs out of entropy) or a CSPRNG.
If you use a CSPRNG with a kilobyte of state, and you get a megabyte of pad
from it, there are no more than 256^1024 possible pads, not 256^1048576, and
if someone sends a message longer than a kilobyte, there are some plaintexts
that are impossible given the ciphertext. The proof does apply if you use a
TRNG, as long as randomness is properly extracted.
> OTP Distribution:
> As specified in section 3.1, OTP material is distributed via secure
> out-of-band channels (physical exchange, trusted couriers,
> quantum-resistant protocols, etc.) before any communication begins.
Sounds good.
> Message Collisions & Synchronization: This is precisely why I implemented
> two key features:
>
> Presence Server (port 8081): All participants must be online and
> synchronized before communication begins. This prevents late-joining
> participants from causing state desynchronization.
>
>
> Gentleman Protocol: Users cannot speak simultaneously. The system requires
> turn-taking enforced at the protocol level, not just the UI layer. This
> ensures atomic OTP consumption and perfect state synchronization across all
> participants.
I just moved. The old house has a Hughes satellite connection which often goes
down when there's a thunderstorm near there or near the ground station. (The
connection is still up, but nothing's using it.) Latency varies, usually being
around 600 ms. My connection here is Starlink; I haven't watched it long
enough to know what it does with thunderstorms. How well does the gentleman
protocol work with long, variable latency and participants dropping out
because of storms?
Pierre
--
ve ka'a ro klaji la .romas. se jmaji
More information about the cryptography
mailing list