Deniable encryption

In their pivotal 1996 paper, Ran Canetti, Cynthia Dwork, Moni Naor, and Rafail Ostrovsky introduced the concept of deniable encryption, a cryptographic breakthrough that ensures privacy even under coercion.

This concept allows encrypted communication participants to plausibly deny the true content of their messages.

Their work lays the foundational principles of deniable encryption, illustrating its critical role in protecting privacy against forced disclosures.

This research has become a cornerstone for future advancements in cryptography, emphasizing the importance of deniable encryption in maintaining communication security.

[4][2] Deniable encryption makes it impossible to prove the origin or existence of the plaintext message without the proper decryption key.

An early use of the term was on the sci.crypt newsgroup, in a message posted 16 October 1990 by Marcus J. Ranum, alluding to corporal punishment:...the rubber-hose technique of cryptanalysis.

(in which a rubber hose is applied forcefully and frequently to the soles of the feet until the key to the cryptosystem is discovered, a process that can take a surprisingly short time and is quite computationally inexpensive).

[citation needed] Physically, these types of filesystems are typically stored in a single directory consisting of equal-length files with filenames that are either randomized (in case they belong to chaff layers), or cryptographic hashes of strings identifying the blocks.

It was created by Julian Assange as a tool for human rights workers who needed to protect sensitive data in the field and was initially released in 1997.

[12] The name Rubberhose is a joking reference to the cypherpunks term rubber-hose cryptanalysis, in which encryption keys are obtained by means of violence.

[citation needed] It was written for Linux kernel 2.2, NetBSD and FreeBSD in 1997–2000 by Julian Assange, Suelette Dreyfus, and Ralf Weinmann.

[22][self-published source] Doubts have been raised about the level of plausible deniability in 'hidden volumes'[23][self-published source] – the contents of the "outer" container filesystem have to be 'frozen' in its initial state to prevent the user from corrupting the hidden volume (this can be detected from the access and modification timestamps), which could raise suspicion.