Papers for

secure messaging developers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Private postquantum blockchain minimizes onchain data for payments

Compact Shielded CSV: Post-Quantum, Private, Lightweight Client-Side Validation Blockchain

Abstract: We propose Compact Shielded CSV, a private client-side validation blockchain for peer-to-peer payments designed for the postquantum era. Upgrading existing blockchains to quantum-resistant cryptography substantially increases on-chain overhead. By keeping all large cryptographic artifacts off-chain, Compact Shielded CSV keeps a minimal on-chain footprint independent of the size of the underlying cryptographic proofs and signatures. For a single input transaction, the onchain footprint is just 3 hashes (3x32 bytes): a nullifier, a degriefer, and a commitment to the transaction. We introduce the degriefer - a novel mechanism that enforces ownership and prevents double-spending using only hash commitments, eliminating the need for on-chain signatures entirely. These properties make Compact Shielded CSV a promising foundation for private, scalable, post-quantum digital payments.

Fri 25 SeptCryptography and Security
The gist
Current blockchains that protect against quantum computing attacks become bulky and slow because they store a lot of cryptographic data directly on the blockchain. The authors propose Compact Shielded CSV, a way to keep the blockchain data very small by moving heavy cryptographic proofs off the chain. They introduce a new tool called the degriefer that lets the system control ownership and prevent double spending just by using hashes, so no on-chain signatures are needed. This makes digital payments more private, efficient, and ready for future quantum threats.
Open → 2609.32015v1

Bidirectional encrypted channels prevent detection attacks in two-way communication

Closing the Loop: Bidirectional Fully Encrypted Protocols

Abstract: Fully encrypted protocols (FEPs) provide encrypted channels that make all protocol-generated bytes computationally indistinguishable from uniform random strings. Several previous works have explored security definitions and constructions of unidirectional FEPs: protocols in which one party acts only as a sender, and the other acts only as a receiver. However, most applications require two-way information exchange, and a network adversary can observe communication in both directions and their shared lifetime. Because the semantics of bidirectional channels involve more complex shared state, it is possible that the ``naïve'' composition of two unidirectional channels can result in a two-way protocol that can be detected based on dependencies between the two directions, such as traffic imbalance, channel closure, failures, or connection tear-down. To address this issue, we introduce new formal security definitions for bidirectional FEPs that capture exact shaping, delivery, protocol-state integrity, private half-close, and cross-direction isolation, while revealing a public ``sending schedule'' and ``closing epoch'' that may be randomized. We show that the trivial composition fails to meet these definitions, leading to practical detection attacks. We then construct provably secure bidirectional FEPs (BiFEPs) for both the datastream and datagram settings. For datastream, we combine two direction-separated FEPs with a ``wrapper'' layer that prevents detection based on the mismatch between uni- and bi-directional connection states. For datagram, we add encrypted DATA/FIN/ACK with replay protection and loss-tolerant close. We validate the design through a Rust implementation and show that none of the surveyed deployed protocols provides the full set of BiFEP security properties.

Tue 15 SeptCryptography and Security
The gist
Sending information secretly over the internet usually hides the message but might reveal patterns when messages go back and forth. The authors show that simply joining two one-way secret channels can leak clues exposing the conversation. They introduce a better way to build secret two-way channels that hide these clues and keep messages safe in both directions. They prove their method works and built it in Rust, showing current tools don’t meet these stronger safety rules.
Open → 2609.17397v1