Editing Deniable encryption (section)

==Forms of deniable encryption==
Normally, ciphertexts decrypt to a single plaintext that is intended to be kept secret. However, one form of deniable encryption allows its users to decrypt the ciphertext to produce a different (innocuous but plausible) plaintext and plausibly claim that it is what they encrypted. The holder of the ciphertext will not be able to differentiate between the true plaintext, and the bogus-claim plaintext. In general, one [[ciphertext]] cannot be decrypted to all possible [[plaintext]]s unless the key is as large as the [[plaintext]], so it is not practical in most cases for a ciphertext to reveal no information whatsoever about its plaintext.<ref>{{cite journal| last=Shannon| first=Claude| title=Communication Theory of Secrecy Systems| journal=Bell System Technical Journal| volume=28| issue=4| pages=659–664| year=1949| doi=10.1002/j.1538-7305.1949.tb00928.x| url=https://www.cs.virginia.edu/~evans/greatworks/shannon1949.pdf| access-date=2022-01-14| archive-date=2022-01-14| archive-url=https://web.archive.org/web/20220114040422/https://www.cs.virginia.edu/~evans/greatworks/shannon1949.pdf| url-status=live}}</ref> However, some schemes allow decryption to decoy plaintexts that are close to the original in some metric (such as [[edit distance]]).<ref>{{cite conference
| url=https://www.blackhat.com/docs/asia-14/materials/Trachtenberg/WP-Asia-14-Trachtenberg-Say-It-Ain%27t-So-An-Implementation-Of-Deniable-Encryption.pdf
| title=Say it Ain't So - An Implementation of Deniable Encryption
| first=Ari
| last=Trachtenberg
| date=March 2014
| conference=Blackhat Asia
| conference-url=https://www.blackhat.com/asia-14/
| location=Singapore
| access-date=2015-03-06
| archive-date=2015-04-21
| archive-url=https://web.archive.org/web/20150421042044/https://www.blackhat.com/docs/asia-14/materials/Trachtenberg/WP-Asia-14-Trachtenberg-Say-It-Ain%27t-So-An-Implementation-Of-Deniable-Encryption.pdf
| url-status=live
}}</ref>

Modern deniable encryption techniques exploit the fact that without the key, it is infeasible to distinguish between ciphertext from [[block cipher]]s and data generated by a [[cryptographically secure pseudorandom number generator]] (the cipher's [[pseudorandom permutation]] properties).<ref>{{cite book
| title=Cryptographic Engineering
| first1=Debrup
| last1=Chakraborty
| first2=Francisco
| last2=Rodríguez-Henríquez.
| editor=Çetin Kaya Koç
| url=https://books.google.com/books?id=nErZY4vYHIoC&q=%22she+should+be+unable+to+distinguish+those+plaintexts%22&pg=PA340
| year=2008
| page=340
| publisher=Springer
| isbn=9780387718170
| access-date=2020-11-18
| archive-date=2024-04-02
| archive-url=https://web.archive.org/web/20240402041852/https://books.google.com/books?id=nErZY4vYHIoC&q=%22she+should+be+unable+to+distinguish+those+plaintexts%22&pg=PA340#v=snippet&q=%22she%20should%20be%20unable%20to%20distinguish%20those%20plaintexts%22&f=false
| url-status=live
}}</ref>

This is used in combination with some [[decoy]] data that the user would plausibly want to keep confidential that will be revealed to the attacker, claiming that this is all there is. This is a form of [[steganography]].{{Cn|date=March 2024}}

If the user does not supply the correct key for the truly secret data, decrypting it will result in apparently random data, indistinguishable from not having stored any particular data there.{{Cn|date=March 2024}}

=== Examples ===

==== Layers ====
One example of deniable encryption is a [[cryptographic filesystem]] that employs a concept of abstract "layers", where each layer can be decrypted with a different encryption key.{{Cn|date=March 2024}} Additionally, special "[[chaff (radar countermeasure)|chaff]] layers" are filled with random data in order to have [[plausible deniability]] of the existence of real layers and their encryption keys.{{Cn|date=March 2024}} The user can store decoy files on one or more layers while denying the existence of others, claiming that the rest of space is taken up by chaff layers.{{Cn|date=March 2024}} Physically, these types of filesystems are typically stored in a single directory consisting of equal-length files with filenames that are either [[randomness|random]]ized (in case they belong to chaff layers), or [[cryptographic hash function|cryptographic hash]]es of strings identifying the blocks.{{Cn|date=March 2024}} The [[timestamp]]s of these files are always randomized.{{Cn|date=March 2024}} Examples of this approach include Rubberhose filesystem. 

Rubberhose (also known by its development codename Marutukku)<ref name="dreyfus">{{cite web |title=Rubberhose cryptographically deniable transparent disk encryption system |url=http://marutukku.org/ |url-status=dead |archive-url=https://web.archive.org/web/20120716034441/http://marutukku.org/ |archive-date=16 July 2012 |access-date=12 January 2022 |website=marutukku.org}}</ref> is a deniable encryption program which encrypts data on a storage device and hides the encrypted data. The existence of the encrypted data can only be verified using the appropriate cryptographic key. 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.<ref name="dreyfus" /> 

The name Rubberhose is a joking reference to the [[cypherpunks]] term rubber-hose cryptanalysis, in which encryption keys are obtained by means of violence.{{Cn|date=March 2024}} 

It was written for [[Linux kernel]] 2.2, [[NetBSD]] and [[FreeBSD]] in 1997–2000 by [[Julian Assange]], [[Suelette Dreyfus]], and Ralf Weinmann. The latest version available, still in alpha stage, is v0.8.3.<ref name="marutukku">{{cite web |title=Rubberhose cryptographically deniable transparent disk encryption system |url=http://marutukku.org/ |url-status=dead |archive-url=https://web.archive.org/web/20120716034441/http://marutukku.org/ |archive-date=16 July 2012 |access-date=12 January 2022 |website=marutukku.org}}</ref>

==== Container volumes ====
Another approach used by some conventional [[disk encryption software]] suites is creating a second encrypted [[volume (computing)|volume]] within a container volume. The container volume is first formatted by filling it with encrypted random data,<ref name="LibreCrypt">{{Cite web| url=https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md| title=LibreCrypt: Transparent on-the-fly disk encryption for Windows. LUKS compatible.: T-d-k/LibreCrypt| website=[[GitHub]]| date=2019-02-09| access-date=2015-07-03| archive-date=2019-12-15| archive-url=https://web.archive.org/web/20191215031303/https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md| url-status=live}}</ref> and then initializing a filesystem on it. The user then fills some of the filesystem with legitimate, but plausible-looking decoy files that the user would seem to have an incentive to hide. Next, a new encrypted volume (the hidden volume) is allocated within the free space of the container filesystem which will be used for data the user actually wants to hide. Since an adversary cannot differentiate between encrypted data and the random data used to initialize the outer volume, this inner volume is now undetectable. [[LibreCrypt]]<ref name=LibreCrypt-plausible-deniability>{{cite web |title=LibreCrypt documentation on Plausible Deniability |website=[[GitHub]] |url=https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md |date=2019-02-09 |access-date=2015-07-03 |archive-date=2019-12-15 |archive-url=https://web.archive.org/web/20191215031303/https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md |url-status=live }}</ref> and [[BestCrypt]] can have many hidden volumes in a container; [[TrueCrypt]] is limited to one hidden volume.<ref name="truecrypt.org">{{Cite web | url=http://www.truecrypt.org/hiddenvolume | title=TrueCrypt | access-date=2006-02-16 | archive-date=2012-09-14 | archive-url=https://archive.today/20120914151319/http://www.truecrypt.org/hiddenvolume | url-status=live }}</ref>

==== Other software ====
*[[Cryptee]], an [[open-source]], [[Client-Side Encryption|client-side encrypted]], [[Cross-platform software|cross-platform]] [[Productivity software|productivity suite]] and [[File-hosting service|cloud storage service]] which offers its users the ability to hide (''ghost'') folders and photo albums for [[plausible deniability#Use_in_cryptography|plausible deniability]].

*[[LibreCrypt]], [[open-source]] [[Disk encryption|transparent disk encryption]] for MS Windows and PocketPC PDAs that provides both deniable encryption and [[plausible deniability]].<ref name="LibreCrypt" /><ref>See its [https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md documentation section on "Plausible Deniability"] {{Webarchive|url=https://web.archive.org/web/20191215031303/https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausible_deniability.md |date=2019-12-15 }})</ref> Offers an extensive range of encryption options, and doesn't need to be installed before use as long as the user has administrator rights.

*[[Off-the-Record Messaging]], a cryptographic technique providing true deniability for [[instant messaging]].

*[[OpenPuff]], freeware semi-open-source steganography for MS Windows.

*[[StegFS]], the current successor to the ideas embodied by the Rubberhose and PhoneBookFS filesystems.

*[[Vanish (computer science)|Vanish]], a research prototype implementation of self-destructing data storage.

*[[VeraCrypt]] (a successor to a discontinued [[TrueCrypt]]), an [[OTFE|on-the-fly disk encryption]] software for [[Windows]], [[MacOS|Mac]] and [[Linux]] providing limited deniable encryption<ref>{{Cite web |url=http://www.truecrypt.org/hiddenvolume.php |title=TrueCrypt - Free Open-Source On-The-Fly Disk Encryption Software for Windows Vista/XP, Mac OS X, and Linux - Hidden Volume<!-- Bot generated title --> |access-date=2006-02-16 |archive-date=2013-10-15 |archive-url=https://archive.today/20131015034241/http://www.truecrypt.org/hiddenvolume.php |url-status=live }}</ref> and to some extent (due to limitations on the number of hidden volumes which can be created<ref name="truecrypt.org" />) [[plausible deniability]], without needing to be installed before use as long as the user has full administrator rights.

===Detection===
The existence of hidden encrypted data may be revealed by flaws in the implementation.<ref>{{cite journal |author=Adal Chiriliuc |title=BestCrypt IV generation flaw |date=2003-10-23 |url=http://adal.chiriliuc.com/bc_iv_flaw.php |accessdate=2006-08-23 |archive-url=https://web.archive.org/web/20060721044156/http://adal.chiriliuc.com/bc_iv_flaw.php |archive-date=2006-07-21 |url-status=dead }}</ref>{{Self-published inline|date=March 2024|certain=y}} It may also be revealed by a so-called [[watermarking attack]] if an inappropriate cipher mode is used.<ref>[title=https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg04229.html {{Webarchive|url=https://web.archive.org/web/20160702002846/https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg04229.html |date=2016-07-02 }} [Qemu-devel] QCOW2 cryptography and secure key handling]</ref>
The existence of the data may be revealed by it 'leaking' into non-encrypted disk space<ref>{{Cite web |url=http://news.techworld.com/security/102171/encrypted-hard-drives-may-not-be-safe/ |title=Encrypted hard drives may not be safe: Researchers find that encryption is not all it claims to be. |access-date=2011-10-08 |archive-date=2013-03-30 |archive-url=https://web.archive.org/web/20130330154644/http://news.techworld.com/security/102171/encrypted-hard-drives-may-not-be-safe/ |url-status=dead }}</ref> where it can be detected by [[Computer forensics|forensic]] tools.<ref>http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3970 {{Webarchive|url=https://web.archive.org/web/20140905190638/http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3970 |date=2014-09-05 }} Is there any way to tell in Encase if there is a hidden truecrypt volume? If so how?</ref>{{Self-published inline|date=March 2024|certain=y}}

Doubts have been raised about the level of plausible deniability in 'hidden volumes'<ref>{{Cite web |url=https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#c17 |title=Plausible deniability support for LUKS |access-date=2015-07-03 |archive-date=2019-10-21 |archive-url=https://web.archive.org/web/20191021003129/https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#c17 |url-status=live }}</ref>{{Self-published inline|date=March 2024|certain=y}} &ndash; 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. This problem can be eliminated by instructing the system not to protect the hidden volume, although this could result in lost data.{{Cn|date=March 2024}}

===Drawbacks===
Possession of deniable encryption tools could lead attackers to continue torturing a user even after the user has revealed all their keys, because the attackers could not know whether the user had revealed their last key or not. However, knowledge of this fact can disincentivize users from revealing any keys to begin with, since they will never be able to prove to the attacker that they have revealed their last key.<ref>{{Cite web |url=http://embeddedsw.net/doc/physical_coercion.txt |title=Julian Assange: Physical Coercion |access-date=2011-10-08 |archive-date=2013-07-23 |archive-url=https://web.archive.org/web/20130723100802/http://embeddedsw.net/doc/physical_coercion.txt |url-status=live }}</ref>