Search arXiv⌕ Search
Home/Archive/arXiv

arXiv · 2610.16100

HDKEM: Authentication Allocation for Deniable Hybrid Key Exchange

Kazi Hassan Shakib·Muhammad Asfand Hafeez·Arslan Munir
View original source ↗Read source document ↗Export metadata ↓

Abstract

Deniable authenticated key exchange (DAKE) establishes a shared key without leaving transferable evidence that a party participated. We study DAKE protocols that authenticate each fresh session with one ring signature and show that their deniability mechanisms fall into three authentication allocations: sharing an authentication witness, hiding the signing witness under a fixed ring, or varying the verified ring between real and simulated executions. For fixed-ring protocols, witness hiding yields a necessary relation between the ring signature's witness-indistinguishability gap and the protocol's $(μ,δ)$ deniability parameters. We instantiate witness hiding in HDKEM, a three-slot hybrid that combines ML-KEM-768, X25519, and an optional pairwise information-theoretic source through a split-key PRF. HDKEM binds all public session values, including a QKD key identifier when present, into authentication and key derivation. Under the stated component models, it achieves eCK key indistinguishability, forward secrecy, and strong local deniability. We evaluate HDKEM with FalconRS and Gandalf. Across 2,000 primitive operations, median signing/verification times are 9.20/1.02 ms for FalconRS and 18.61/0.97 ms for Gandalf in our reference environment. In source-backed mode, the corresponding TCP-application costs are 8,607 B and 8,555 B per handshake. A separate 500-session server experiment exercises the complete FalconRS source-backed path and reports a median server time of 16.29 ms including local I/O.

Explore related subjects

cs.CR

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Kazi Hassan Shakib, Muhammad Asfand Hafeez, Arslan Munir. 2026-10-12. HDKEM: Authentication Allocation for Deniable Hybrid Key Exchange. https://arxiv.org/abs/2610.16100

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

Simulation-Secure Functional Encryption in the Bounded Storage Model

Functional encryption (FE) is a versatile paradigm that enables fine-grained access control over encrypted data. Despite its potential, achieving the gold standard of simulation-based security for FE is impossible in full generality. Known impossibility results demonstrate that simulation security cannot be attained if an adversary in the security experiment is permitted either an unbounded number of functional key queries or an unbounded number of challenge ciphertexts. In this work, we circumvent these fundamental barriers by considering two distinct memory-restricted settings: the Bounded Quantum Storage Model and the Bounded Classical Storage Model. In these settings, the plain model impossibility results no longer apply, allowing us to obtain new positive results. Specifically, we construct two adaptively simulation-secure FE schemes in the Bounded Quantum Storage Model: 1) Many functional key scheme: A construction supporting many functional key queries and a single challenge ciphertext, assuming only the existence of one-way functions. 2) Many ciphertext scheme: An information-theoretic secure construction supporting a single non-adaptive functional key, many challenge ciphertexts, and many adaptive functional key queries. Furthermore, we demonstrate that both schemes can be ported to the Bounded Classical Storage Model, assuming the existence of disappearing grey-box obfuscation.

cs.CR↗
arXiv2026

Watermarking Continuous Tabular Data Generation

In this paper, we introduce a simple yet effective tabular data watermarking mechanism with statistical guarantees. We show theoretically that the proposed watermark can be effectively detected, while faithfully preserving the data fidelity, and also demonstrates appealing robustness against additive noise attack. The general idea is to achieve the watermarking through a strategic embedding based on simple data binning. Specifically, it divides the feature's value range into finely segmented intervals and embeds watermarks into selected ``green list" intervals. To detect the watermarks, we develop a principled statistical hypothesis-testing framework with minimal assumptions: it remains valid as long as the underlying data distribution has a continuous density function. The watermarking efficacy is demonstrated through rigorous theoretical analysis and empirical validation, highlighting its utility in enhancing the security of synthetic and real-world datasets.

cs.CR↗
arXiv2026

MIRANDA: short signatures from a leakage-free full-domain-hash scheme

We present $\mathsf{Miranda}$, the first family of full-domain-hash signatures based on matrix codes. This signature scheme fulfils the paradigm of Gentry, Peikert and Vaikuntanathan ($\mathsf{GPV}$), which gives strong security guarantees. Our trapdoor is very simple and generic: if we propose it with matrix codes, it can actually be instantiated in many other ways since it only involves a subcode of a decodable code (or lattice) in a unique decoding regime of parameters. Though $\mathsf{Miranda}$ signing algorithm relies on a decoding task where there is exactly one solution, there are many possible signatures given a message to sign and we ensure that signatures are not leaking information on their underlying trapdoor by means of a very simple procedure involving the drawing of a small number of uniform bits. In particular $\mathsf{Miranda}$ does not use a rejection sampling procedure which makes its implementation a very simple task contrary to other $\mathsf{GPV}$-like signatures schemes such as $\mathsf{Falcon}$ or even $\mathsf{Wave}$. We instantiate $\mathsf{Miranda}$ with the famous family of Gabidulin codes represented as spaces of matrices and we study thoroughly its security (in the EUF-CMA security model). For~$128$ bits of classical security, the signature sizes are as low as~$90$ bytes and the public key sizes are in the order of~$2.6$ megabytes.

cs.CR↗