Talk:Deniable encryption

obey government requirements

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

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

My apologies, that was a good addition, sorry about that. I will fix it now. LegoK^ontribsT^alkM 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? 99.90.197.244 (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)

References

DoxBox

Can someone please update this article to add a reference to DoxBox (https://t-d-k.github.io/doxbox/ ) which is a relaunch of FreeOTFE. I am the maintainer of DoxBox. — Preceding unsigned comment added by Squte (talk • contribs) 23:57, 30 August 2014 (UTC)

Rework

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 http://www.devttys0.com/2013/06/differentiate-encryption-from-compression-using-math/ 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

—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 https://eprint.iacr.org/2015/510 — Preceding unsigned comment added by GideonSamid (talk • contribs) 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)

Proposed merge of Rubberhose (file system) and Rubber-hose cryptanalysis into Deniable encryption

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was merge. Softlem (talk) 05:55, 19 March 2024 (UTC)

---

All three pages have source and notability problems. Rubberhose pages are both about deniable encryption and should merge to it to make one good page Softlem (talk) 05:06, 12 March 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.