[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