Talk:Deniable encryption

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Cryptography / Computer science  (Rated Start-class, High-importance)
WikiProject iconThis article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the quality scale.
 High  This article has been rated as High-importance on the importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as High-importance).

Can we please craft a 'scenario' where encryption is not used for illicit activities?[edit]

I find it somewhat objectionable that the "Scenario" entails someone committing adultery and using deniable encryption to support her activities. Deniable encryption has all sorts of uses for the good. Can we please craft a scenario in which the character is using deniable encryption for a good cause? Thanks. (talk) 13:38, 10 October 2013 (UTC)

Bruce Schener's 'Deniable File System' link[edit]

Recently a link "Deniable File System" was recently added to the 'see also' section, but I believe it's rather loosely related to the topic and not very informative and reverted it for now. In any case, if anyone wants to re-add it, make sure you add it under the 'External links' section. -- intgr 13:10, 9 June 2006 (UTC)

Deniability not feasible[edit]

"In practice, deniable encryption is very difficult to execute. ... It is nearly impossible to construct keys and ciphertexts for modern block ciphers such that one ciphertext will decrypt to two comprehensible plaintexts."

That's not true. The idea is not to take an existing encryption scheme and make it deniable, but to use new algorithms that incorporate deniablility. In this sense deniable encryption is decidedly possible and practially feasible. [1] Arvindn 02:34, 11 Oct 2004 (UTC)
OK, I'm removing that last paragraph until I get a chance to rework it. Decrypt3 15:29, Oct 11, 2004 (UTC)
Given that non-deniable encryption systems are the norm, the only reason one would use a deniable encryption system is so that he is able to deny it. Completely useless (at least in its original formulation). Steganography, on the other hand, would work better (i.e. an image is an image, it may contain a hidden message, or not). NabilStendardo (talk) 20:28, 20 December 2011 (UTC)


The notion of "deniable encryption" was introduced by Julian Assange & Ralf Weinmann in the Rubberhose filesystem[1] and explored in detail in a paper by Ran Canetti, Cynthia Dwork, Moni Naor, and Rafail Ostrovsky[2] in 1996.

The Rubberhose stuff seems to be from 2000, about 4 years later than the CDNO paper. The Rubberhose reference doesn't point to a precise document, so the claim that deniable encryption originates with them is a bit hard to verify. Stevo2001 (talk) 20:12, 9 February 2009 (UTC)


Hello, could someone add some other (than one-time pad) simple example of construction of such cipher? Also, I also don't understand, can this also be used as protection from brute-force cryptanalysis, because you don't know which message is the right one? Samohyl Jan 07:35, 28 Feb 2005 (UTC)

CDMA as deniable encryption?[edit]

CDMA mobile phones essentially combine several different messages (from the tower to the handsets or vice versa) in the air, and the decoding process allows each phone to use its unique code to pick out a message intended for it, or to detect that it isn't being addressed, from a shared bitstream. Could this be considered a form of deniable encryption (since the same bitstream can be decoded to produce different messages), and if so, perhaps it should be referenced in this article? Mr2001 3 July 2005 06:44 (UTC)

Doesn't sound like it's a particularly good example, IMHO... H8gaR 17:34, 26 July 2007 (UTC)


Do we have to use negative examples of why someone would want deniable encryption? Why can't we use positive examples like free-speech advocates in China instead? —The preceding unsigned comment was added by (talkcontribs) 19:18, 18 May 2006 (UTC)

I don't know about a better example, but it would be problematic, from the NPOV, to use a specific political example (And I do abhor China's free-speech problems, by the way!) — Matt Crypto 21:02, 18 May 2006 (UTC)
I'm not a wikipedian, but from a layman's perspective, the current example seems VERY point-of-view. Probably a military example would be the best NPOV, without identifying the military organization. -Bluenail
Utterly inappropriate example for an encyclopedia. "Being bold" and commenting it out in the hopes someone will fix the content. I'm not a fan of leaving garbage in the wikipedia until someone decides to fix it. Have an objection? Then fix it, don't merely reinstate it. -kid in study hall —Preceding unsigned comment added by (talk) 14:44, 16 October 2008 (UTC)

"Significance" and "essence" sections[edit]

The recently added "significance" and "essence" sections, in my opinion, read too much like an essay. Besides that, they also widen the already problematic gap between traditional "one ciphertext decrypts into multiple plaintexts" kind of deniability, and deniability offered by upper layers (as in TrueCrypt, PhoneBookFS or StegFS; or OTR where it has an entirely different meaning). Notice how earlier sections seem to imply that OTP-kind of deniability is the only kind of deniability.

Another problem I have with this is the apparent promotion of and a new patent, calling it a "novel technique." I am not implying that this edit was made in a bad faith, but I believe it's not appropriate for Wikipedia without significant media coverage (WP:V, WP:RS).

I am therefore reverting these edits for now. Does anyone else have a second opinion on this? -- intgr [talk] 15:56, 27 May 2008 (UTC)

The deleted contribution eliminates the clarity they added to a description that otherwise reads very thick and mysterious. It must be stressed that One-Time Pad provides total deniability, owing to its key size, and therefore any ciphersystem that allows for keys as large as desired may provide classical deniability. It's not intellectually honest to remove this point from the discussion. For reference see the quoted patent as well as: "Encryption on Demand"

Samid, G. 2001 "Re-Dividing Complexity Between Algorithms and Keys (Key Scripts)" The Second International Conference on Cryptology in India, Indian Institute of Technology, Madras, Chennai, India. December 2001. "

Samid, G. 2002 " At-Will Intractability Up to Plaintext Equivocation Achieved via a Cryptographic Key Made As Small, or As Large As Desired - Without Computational Penalty " 2002 International Workshop on CRYPTOLOGY AND NETWORK SECURITY San Francisco, California, USA September 26 -- 28, 2002

Samid, G. 2001 "Anonymity Management: A Blue Print For Newfound Privacy" The Second International Workshop on Information Security Applications (WISA 2001), Seoul, Korea, September 13-14, 2001 (Best Paper Award).

Samid, G. 2005 "The Myth of Invincible Encryption" Digital Transactions May-June 2005 —Preceding unsigned comment added by Ignorexxia (talkcontribs) 20:26, 27 May 2008 (UTC)

No, the added contribution adds to the confusion because it suggests that the "long key encryption" approach is the only way to achieve deniability; yet some practical end-user applications that offer a level of deniability (listed above), do not use this method. There is a very good reason for this: if your data is encrypted with a long secret key, then managing this key itself becomes a problem, as it cannot be memorized. What do you do with a long secret key -- do you encrypt it?
I do agree that the article is unclear, but I believe this addition is a step backwards. Not only because it misrepresents the practical approaches of deniable encryption; phrases like "Freedom without privacy is not. Privacy without deniability is not." might belong to an essay or a sales brochure, but it's not something that an encyclopedia would say.
I'm not particularly impressed by your excessive citing of Gideon Samid, either, because it is naturally in his interests to promote his product and patent. It doesn't add to his integrity that his papers never cite other authors' research, and that reputable cryptography researchers like Bruce Schneier [2] and Peter Gutmann [3] have publicly criticized the claims of "AGS Encryptions Ltd.", which is the company that sells Gideon Samid's product. -- intgr [talk] 13:55, 28 May 2008 (UTC)

This topic, like so many others is clouded with needless complications. It boils down to simple statistics: if the key is much shorter than the message, then it's statistically impossible to find a second plausible plaintext for a given ciphertext. And this holds true regardless of the algorithm that is being used. That is why all the mainstay ciphersystems don't offer deniability. They all use very small keys. By contrast any ciphersystem that can handle a large as desired key (without choking on the computation load) will be able to use a sufficiently large key to enable deniability. The above article by Gideon Samid, and the corresponding patent (US Patent 6,823,068) do allow a key of any size, and hence this ciphersystem offers deniability. Any other ciphersystem that can handle large keys will also offer deniability. Small keys systems -- not. Now that is solid mathematics. You can't intimidate this truth by citing crypto-theologians. And since nobody today remembers keys (like yesterday's spies had to), it's all in memory anyway, there is no real reason not to use large keys. And yes, deniability is the only weapon against coercive invastion of privacy. —Preceding unsigned comment added by Ignorexxia (talkcontribs) 22:13, 21 September 2008 (UTC)

I understand where you're getting at, and I believe I already addressed that above. This article isn't just about deniable ciphers, but also applications that provide deniability using classical (non-deniable) cryptography primitives; take for example the TrueCrypt hidden container technique that only uses a symmetric cipher. It doesn't encode two messages in the same ciphertext, but instead hides the hidden volume in the free space of the outer volume. I don't think there can be any doubt about which approach is more popular: it's AGS Encryptions alone versus TrueCrypt, BestCrypt, FreeOTFE, Rubberhose FS, PhonebookFS, StegFS, Magikfs etc etc. Whereas you're trying to claim that using a large key cipher is the only way to achieve deniability — it's not.
I'm not even convinced that long key deniability is practical; in a classical cryptosystem, you normally pick one or more memorable passphrases, which are the only secrets in the system. It works because this secret can be kept in a relatively secure place — your mind. In the long key approach however, you're stuck with the cryptosystem telling you what the key is. Even worse, if you want to deniably encrypt significant amounts of data, the key can be megabytes or gigabytes long. You can't memorize it, so you most likely store it on a computer.
Q1: How do you deny the existence of a key that's accessible for the attacker?
Q2: If you do have a good place where to hide the key so the attacker doesn't find it — why not store your data there in the first place? If the attacker never finds your data, then there is no need to deny it.
Third, the entire world of cryptography depends on peer review, and I can't find any evidence of thorough reviews of his approach. Having Wikipedia suggest that this is secure at all is, I think, optimistic. -- intgr [talk] 03:40, 22 September 2008 (UTC)

True crypt deniability[edit]

Following up a minor change I put in, Truecrypt only supports a single hidden container per host container, the others systems mentioned allow numerous hidden containers. This means "the guy with the rubber hose" only need beat the person with the container file until they spill the details of that single hidden container (or a dummy hidden container) - at which point the person with the container file can prove there are no more hidden volumes and the beating will stop - so a beating would act as an active incentive to give up any hidden volume. OTOH, anyone with a freeotfe or bestcrypt container knows there's no point in giving up the details of any hidden volume as any beating won't stop. This means the hidden data they stores is more likely to remain secure (there's no incentive to give up the hidden volume's details). This isn't an anti-truecrypt comment, but when protecting data against someone with no respect for human rights, this is a big concern. Cralar (talk) 17:00, 19 June 2010 (UTC)

Then don't beat around the bush. Claiming that TrueCrypt is worse than everything else without any substantiation is clearly a bad edit. Just state the facts in the article and cite your sources. -- intgr [talk] 20:28, 19 June 2010 (UTC)
I can see your point that wasn't what I was looking to do. i'll elaborate more to make it clearer Cralar (talk) 21:03, 19 June 2010 (UTC)

Can you quote the exact part of your provided sources that suggests that either FreeOTFE or BestCrypt support multiple hidden containers per volume? I skimmed through all of those sources, but did not find supporting evidence. As far as I can see, this is also problematic given the design of the hidden containers approach, to prevent different hidden containers from overwriting each other and not leaking their neighbors' existence.

Also you cannot claim that TrueCrypt provides "less" deniability because of it, because that is clearly not present in the sources, it's synthesis. -- intgr [talk] 14:25, 22 June 2010 (UTC)

BestCrypt allows multiple hidden volumes; each "normal" volume has some number of keys associated with it which may or may not be in use, and may or may not be a key to a hidden volume. It's in the API documentation - I'll try and pull out a better reference (the one I put up previously maybe wasn't too clear about this). The FreeOTFE WWW site certainly states that it allows arbitary numbers of hidden volumes. OTOH, Truecrypt certainly can't support more than one hidden volume - it's inherent in its design, so that reference is OK. Whether truecrypt is "less deniable" depends on your security model, but the limitation to a single hidden volume per normal volume can certainly have security implications that don't apply to the other two.
I'll have a stab at phrasing it better - it really needs making clearer (I'm certainly not trying to claim "Truecrypt is worse than everything else!" - a lot of disk encryption systems don't have any support for hidden volumes). Please could you help me out trying to phrase this to get it across? Cralar (talk) 20:46, 22 June 2010 (UTC)
You're right, the FreeOTFE documentation does say it and I missed it on my first read. How about phrasing it like this? -- intgr [talk] 23:01, 22 June 2010 (UTC)
Yup - thanks for rephrasing, that's a bit better. I've also found a better reference to what I was trying to get at above; the Rubberhose project has details on why limiting the number of hidden volumes can be a serious problem; see: - limiting a system to just one or two hidden containers increases the risk of the data secured being revealed Cralar (talk) 18:34, 23 June 2010 (UTC)
There are always limits, even if they're just soft limits on human memory and the usability of the system you created. An attacker might drug you and beat you virtually indefinitely. Regardless of all the rationalisations, I think even a moderately skilled torturer could draw all passwords out of anyone in a relatively short time-frame. — Preceding unsigned comment added by (talk) 11:38, 6 March 2015 (UTC)

obey government requirements[edit]

BestCrypt, commercial on-the-fly disk encryption for MS Windows "respect" stringent governmental requirements[1].

Whatever it mean it something was coded in. Why you cover up this? —Preceding unsigned comment added by (talk) 23:05, 19 August 2010 (UTC)

My apologies, that was a good addition, sorry about that. I will fix it now. LegoKontribsTalkM 23:08, 19 August 2010 (UTC)
Including that in this article is just irrelevant. Surely if it contains a government backdoor, they wouldn't be boasting about it. If you read that page, it just seems a continuation of the thought that governments have high standards for crypto products — usual meaningless marketing drivel. By taking it out of context and adding your quotes around "respect", you're introducing bias that doesn't exist in the source. -- intgr [talk] 23:28, 19 August 2010 (UTC)
Quotes removed now word "respect" is not highlighted by any means. Are any sources to hypothesize above if-thesis? (talk) 00:07, 20 August 2010 (UTC)
It's irrelevant to the article — whether or not it has been approved for government use does not affect its deniability. Unless you're alleging that it's a backdoor, in which case it is your bias, not what the source is saying (because you took it out of context). And it's quoted from marketing blurb that shouldn't be used as a source on Wikipedia anyway. -- intgr [talk] 00:29, 20 August 2010 (UTC)


Phrase is insulting to many readers (or redundant)[edit]

In the section titled "Modern forms of deniable encryption" the reader is addressed: "Needless to say, insecure block ciphers or pseudorandom number generators can..."

Some will be less familiar with encryption (or the technical details of its implementation) than others, and do in fact need the explanation.

Alternately: if we can somehow assume it's truly "needless to say," then why say it?drone5 (talk) 06:59, 4 October 2010 (UTC)

Wikipedia is a wiki. You're welcome to change it. -- intgr [talk] 12:53, 4 October 2010 (UTC)

File:Crypto-Nerd.png Nominated for speedy Deletion[edit]

Image-x-generic.svg An image used in this article, File:Crypto-Nerd.png, has been nominated for speedy deletion at Wikimedia Commons for the following reason: Other speedy deletions
What should I do?

Don't panic; deletions can take a little longer at Commons than they do on Wikipedia. This gives you an opportunity to contest the deletion (although please review Commons guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to upload it to Wikipedia (Commons does not allow fair use)
  • If the image isn't freely licensed and there is no fair use rationale then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Commons Undeletion Request

This notification is provided by a Bot --CommonsNotificationBot (talk) 23:09, 2 November 2011 (UTC)


Can someone please update this article to add a reference to DoxBox ( ) which is a relaunch of FreeOTFE. I am the maintainer of DoxBox. — Preceding unsigned comment added by Squte (talkcontribs) 23:57, 30 August 2014 (UTC)


This article confuses 3 different types of 'deniable encryption' (only one of which is normally called that), viz:

  1. Decrypting the same cypher text to different plain texts depending on the key. This is implied to be the only form that exists in the 2nd para and the 'scenario', but there are no practical programs that do this (afaik)
  2. Steganography. This is not normally called 'deniable encryption'
  3. Hiding encrypted data in pseudo-random data. Which is the most common approach, but is an afterthought

The section on Malleable encryption also isn't much to do with 'malleable encryption' as defined in that article. It would be better to call it 'deniable authentication' and remove the link to 'malleable encryption'.

There should also be a section on practical problems with deniable encryption (as in the Schneier paper ref'd)

If no one has any objections, I'll update the article accordingly. Tdk at squte (talk) 10:17, 4 September 2014 (UTC)

I've removed the sentence claiming enc'd data is generally detectable using a chi^2 test. The reference given has just a blank statement to that effect, and is biased. OTOH this reference is more credible and gives evidence that it's indistinguishable from random data (as you'd expect). Tdk at squte (talk) 10:51, 4 September 2014 (UTC)

In general, agreed.
Wrt #1, I think it should be clarified that that's the ideal end-goal of deniable encryption, but practical systems have to make tradeoffs to be usable and manageable. I don't think the article suggests that's "the only form that exists". AFAICT it's only possible with "long key" systems, like the one-time pad, where part of the message is encoded in the key itself, but simply not useful in practice. There was previous discussion about this at #"Significance" and "essence" sections.
#2 It's a related concept, maybe it would be good to describe steganography in summary style. But I agree that the current references to "steganography" in the article aren't relevant. -- intgr [talk] 14:10, 4 September 2014 (UTC)

Deniable Encryption via a Complete Transposition Cipher[edit]

—By adding decoy words to a plaintext, and transposing the result, one generates a ciphertext, which the intended reader will be able to properly reverse-transpose, but a cryptanalyst will face irreducible entropy: a list of plausible plaintext candidates. For example: let the plaintext be P = "We shall meet on Wednesday, at 7pm". The message writer will construct the following combination: P* = "We shall meet on Wednesday at 7pm # Sunday, Monday,... 1pm, 2pm,..... " and then transpose the words into a ciphertext C. The intended reader possesses the transposition-key, and performs a reverse-transposition, then she ignores everything right of the "#". A cryptanalyst, will find several keys that would reverse transpose C to several plausible plaintext candidates. For example: P' = "We Shall meet on Sunday, at 2pm"... For this deniability to work the transposition cipher must be 'complete' namely it must be able to encrypt any arbitrary permutation to any other arbitrary permutation. See more in — Preceding unsigned comment added by GideonSamid (talkcontribs) 06:21, 22 November 2015 (UTC)

@GideonSamid: Right now this is just a preprint; it can't be considered for Wikipedia before it appears in a peer-reviewed journal or conference, and is feasible and useful in practice. -- intgr [talk] 17:02, 23 November 2015 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Deniable encryption. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:45, 10 December 2016 (UTC)