Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Deniable encryption

From Wikipedia, the free encyclopedia
(Redirected fromRubberhose (file system))
Encryption techniques where an adversary cannot prove that the plaintext data exists
This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages)
This articlerelies excessively onreferences toprimary sources. Please improve this article by addingsecondary or tertiary sources.
Find sources: "Deniable encryption" – news ·newspapers ·books ·scholar ·JSTOR
(March 2024) (Learn how and when to remove this message)
icon
This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Deniable encryption" – news ·newspapers ·books ·scholar ·JSTOR
(March 2024) (Learn how and when to remove this message)
(Learn how and when to remove this message)

Incryptography andsteganography, plausiblydeniable encryption describesencryption techniques where the existence of an encrypted file or message is deniable in the sense that an adversary cannot prove that theplaintext data exists.[1]

The users mayconvincingly deny that a given piece of data is encrypted, or that they are able to decrypt a given piece of encrypted data, or that some specific encrypted data exists.[2] Such denials may or may not be genuine. For example, it may be impossible to prove that the data is encrypted without the cooperation of the users. If the data is encrypted, the users genuinely may not be able to decrypt it. Deniable encryption serves to undermine an attacker's confidence either that data is encrypted, or that the person in possession of it can decrypt it and provide the associated plaintext.

In their pivotal 1996 paper,Ran Canetti,Cynthia Dwork,Moni Naor, andRafail 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.[3] The notion of deniable encryption was used byJulian Assange andRalf Weinmann in the Rubberhose filesystem.[4][2]

Function

[edit]

Deniable encryption makes it impossible to prove the origin or existence of the plaintext message without the proper decryption key. This may be done by allowing an encrypted message to be decrypted to different sensible plaintexts, depending on thekey used. This allows the sender to haveplausible deniability if compelled to give up their encryption key.[5]

Scenario

[edit]

In some jurisdictions, statutes assume that human operators have access to such things as encryption keys, and governments may enactkey disclosure laws that compel individuals to relinquish keys upon request. Countries such asFrance[6] andAustralia[7] give prosecutors wide-ranging power to compel any person to surrender keys to make available any information encountered in the course of an investigation, and failure to comply incurs jail time and/or civil fines. Another example is theUnited Kingdom'sRegulation of Investigatory Powers Act,[8][9] which makes it a crime not to surrenderencryption keys on demand from a government official authorized by the act. According to theHome Office, the burden of proof that an accused person is in possession of a key rests on the prosecution; moreover, the act contains a defense for operators who have lost or forgotten a key, and they are not liable if they are judged to have done what they can to recover a key.[8][9] Such laws are not universal, however - in theUnited States, though the issue has never reached theSupreme Court, lower courts frequently view forced disclosure ofpasswords as a form ofself-incrimination and an unconstitutional abridgement of theFifth Amendment.[10][11][12]

Incryptography,rubber-hose cryptanalysis is aeuphemism for the extraction of cryptographic secrets (e.g. the password to an encrypted file) from a person bycoercion ortorture[13]—such as beating that person with a rubberhose, hence the name—in contrast to a mathematical or technicalcryptanalytic attack. An early use of the term was on thesci.crypt newsgroup, in a message posted 16 October 1990 byMarcus J. Ranum, alluding tocorporal 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).[14]

Such methods are also euphemistically referred to as "wrench attacks," in reference to anxkcd comic with a similar premise.[15][16]

Deniable encryption allows the sender of an encrypted message to deny sending that message. This requires atrusted third party. A possible scenario works like this:

  1. Bob suspects his wifeAlice is engaged in adultery. That being the case, Alice wants to communicate with her secret lover Carl. She creates two keys, one intended to be kept secret, the other intended to be sacrificed. She passes the secret key (or both) to Carl.
  2. Alice constructs an innocuous message M1 for Carl (intended to be revealed to Bob in case of discovery) and an incriminating love letter M2 to Carl. She constructs a cipher-text C out of both messages, M1 and M2, and emails it to Carl.
  3. Carl uses his key to decrypt M2 (and possibly M1, in order to read the fake message, too).
  4. Bob finds out about the email to Carl, becomes suspicious and forces Alice to decrypt the message.
  5. Alice uses the sacrificial key and reveals the innocuous message M1 to Bob. Since it is impossible for Bob to know for sure that there might be other messages contained in C, he might assume that thereare no other messages.

Another scenario involves Alice sending the same ciphertext (some secret instructions) to Bob and Carl, to whom she has handed different keys. Bob and Carl are to receive different instructions and must not be able to read each other's instructions. Bob will receive the message first and then forward it to Carl.

  1. Alice constructs the ciphertext out of both messages, M1 and M2, and emails it to Bob.
  2. Bob uses his key to decrypt M1 and isn't able to read M2.
  3. Bob forwards the ciphertext to Carl.
  4. Carl uses his key to decrypt M2 and isn't able to read M1.

Forms of deniable encryption

[edit]

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, oneciphertext cannot be decrypted to all possibleplaintexts unless the key is as large as theplaintext, so it is not practical in most cases for a ciphertext to reveal no information whatsoever about its plaintext.[17] However, some schemes allow decryption to decoy plaintexts that are close to the original in some metric (such asedit distance).[18]

Modern deniable encryption techniques exploit the fact that without the key, it is infeasible to distinguish between ciphertext fromblock ciphers and data generated by acryptographically secure pseudorandom number generator (the cipher'spseudorandom permutation properties).[19]

This is used in combination with somedecoy 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 ofsteganography.[citation needed]

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.[citation needed]

Examples

[edit]

Layers

[edit]

One example of deniable encryption is acryptographic filesystem that employs a concept of abstract "layers", where each layer can be decrypted with a different encryption key.[citation needed] Additionally, special "chaff layers" are filled with random data in order to haveplausible deniability of the existence of real layers and their encryption keys.[citation needed] 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.[citation needed] Physically, these types of filesystems are typically stored in a single directory consisting of equal-length files with filenames that are eitherrandomized (in case they belong to chaff layers), orcryptographic hashes of strings identifying the blocks.[citation needed] Thetimestamps of these files are always randomized.[citation needed] Examples of this approach include Rubberhose filesystem.

Rubberhose (also known by its development codename Marutukku)[20] 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 byJulian Assange as a tool for human rights workers who needed to protect sensitive data in the field and was initially released in 1997.[20]

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

It was written forLinux kernel 2.2,NetBSD andFreeBSD in 1997–2000 byJulian Assange,Suelette Dreyfus, and Ralf Weinmann. The latest version available, still in alpha stage, is v0.8.3.[21]

Container volumes

[edit]

Another approach used by some conventionaldisk encryption software suites is creating a second encryptedvolume within a container volume. The container volume is first formatted by filling it with encrypted random data,[22] 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[23] andBestCrypt can have many hidden volumes in a container;TrueCrypt is limited to one hidden volume.[24]

Other software

[edit]
  • OpenPuff, freeware semi-open-source steganography for MS Windows.
  • StegFS, the current successor to the ideas embodied by the Rubberhose and PhoneBookFS filesystems.
  • Vanish, a research prototype implementation of self-destructing data storage.

Detection

[edit]

The existence of hidden encrypted data may be revealed by flaws in the implementation.[27][self-published source] It may also be revealed by a so-calledwatermarking attack if an inappropriate cipher mode is used.[28]The existence of the data may be revealed by it 'leaking' into non-encrypted disk space[29] where it can be detected byforensic tools.[30][self-published source]

Doubts have been raised about the level of plausible deniability in 'hidden volumes'[31][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. This problem can be eliminated by instructing the system not to protect the hidden volume, although this could result in lost data.[citation needed]

Drawbacks

[edit]

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.[32]

Deniable authentication

[edit]
icon
This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.
Find sources: "Deniable encryption" – news ·newspapers ·books ·scholar ·JSTOR
(March 2024) (Learn how and when to remove this message)

Some in-transit encrypted messaging suites, such asOff-the-Record Messaging, offerdeniable authentication which gives the participantsplausible deniability of their conversations. While deniable authentication is not technically "deniable encryption" in that the encryption of the messages is not denied, its deniability refers to the inability of an adversary to prove that the participants had a conversation or said anything in particular.

This is achieved by the fact that all information necessary to forge messages is appended to the encrypted messages – if an adversary is able to create digitally authentic messages in a conversation (seehash-based message authentication code (HMAC)), they are also able toforge messages in the conversation. This is used in conjunction withperfect forward secrecy to assure that the compromise of encryption keys of individual messages does not compromise additional conversations or messages.

See also

[edit]

References

[edit]
  1. ^Seehttp://www.schneier.com/paper-truecrypt-dfs.htmlArchived 2014-06-27 at theWayback Machine. Retrieved on 2013-07-26.
  2. ^abChen, Chen; Chakraborti, Anrin; Sion, Radu (2020)."INFUSE: Invisible plausibly-deniable file system for NAND flash".Proceedings on Privacy Enhancing Technologies.2020 (4):239–254.doi:10.2478/popets-2020-0071.ISSN 2299-0984.Archived from the original on 2023-02-08. Retrieved2024-04-02.
  3. ^Ran Canetti, Cynthia Dwork, Moni Naor,Rafail Ostrovsky (1996-05-10)."Deniable Encryption"(PostScript).Advances in Cryptology – CRYPTO '97. Lecture Notes in Computer Science. Vol. 1294. pp. 90–104.doi:10.1007/BFb0052229.ISBN 978-3-540-63384-6.Archived from the original on 2020-08-24. Retrieved2007-01-05.{{cite book}}: CS1 maint: multiple names: authors list (link)
  4. ^See"Rubberhose cryptographically deniable transparent disk encryption system". Archived fromthe original on 2010-09-15. Retrieved2010-10-21.. Retrieved on 2009-07-22.
  5. ^https://web.cs.ucla.edu/~rafail/PUBLIC/29.pdf
  6. ^Articles 30–31,loi no 2001-1062 du 15 novembre 2001 relative à la sécurité quotidienne (in French)
  7. ^Cybercrime Act 2001. Cth. 2004-09-06. ords 12, 28. Retrieved2025-05-31.
  8. ^ab"The RIP Act".The Guardian. London. October 25, 2001.Archived from the original on March 28, 2023. RetrievedMarch 19, 2024.
  9. ^ab"Regulation of Investigatory Powers Bill; in Session 1999-2000, Internet Publications, Other Bills before Parliament". House of Lords. 9 May 2000. Archived fromthe original on 8 November 2011. Retrieved5 Jan 2011.
  10. ^In RE: GRAND JURY SUBPOENA DUCES TECUM, Nos. 11-12268 & 11-15421 (11th Cir. 2012-02-23) ("We hold that Doe properly invoked the Fifth Amendment privilege. In response, the Government chose not give him the immunity the Fifth Amendment and 18 U.S.C. § 6002 mandate, and the district court acquiesced. Stripped of Fifth Amendment protection, Doe refused to produce the unencrypted contents of the hard drives. The refusal was justified, and the district court erred in adjudging him in civil contempt. The district court’s judgment is accordingly REVERSED.").
  11. ^U.S. v Jeffrey Feldman, THE DECRYPTION OF A SEIZED DATA STORAGE SYSTEM (E.D. Wis. 19 April 2013), archived from the original.
  12. ^"State Court Docket Watch: State of Oregon v. Pittman".fedsoc.org. 23 April 2021.Archived from the original on 2021-06-05. Retrieved2022-03-10.
  13. ^Schneier, Bruce (October 27, 2008)."Rubber-Hose Cryptanalysis".Schneier on Security.Archived from the original on August 30, 2009. RetrievedAugust 29, 2009.
  14. ^Ranum, Marcus J. (October 16, 1990)."Re: Cryptography and the Law..."Newsgroupsci.crypt.Usenet: 1990Oct16.050000.4965@decuac.dec.com.Archived from the original on April 2, 2024. RetrievedOctober 11, 2013.
  15. ^Suderman, Alan (2025-05-28)."Why 'wrench attacks' on wealthy crypto holders are on the rise".Associated Press.
  16. ^Ordekian, Marilyne; Atondo-Siu, Gilberto; Hutchings, Alice; Vasek, Marie (2024)."Investigating Wrench Attacks: Physical Attacks Targeting Cryptocurrency Users"(PDF).6th Conference on Advances in Financial Technologies. Leibniz International Proceedings in Informatics (LIPIcs).316.Schloss Dagstuhl – Leibniz-Zentrum für Informatik: 24:1–24:24.doi:10.4230/LIPIcs.AFT.2024.24.ISBN 978-3-95977-345-4.ISSN 1868-8969. Retrieved2025-05-31.
  17. ^Shannon, Claude (1949)."Communication Theory of Secrecy Systems"(PDF).Bell System Technical Journal.28 (4):659–664.doi:10.1002/j.1538-7305.1949.tb00928.x.Archived(PDF) from the original on 2022-01-14. Retrieved2022-01-14.
  18. ^Trachtenberg, Ari (March 2014).Say it Ain't So - An Implementation of Deniable Encryption(PDF).Blackhat Asia. Singapore.Archived(PDF) from the original on 2015-04-21. Retrieved2015-03-06.
  19. ^Chakraborty, Debrup; Rodríguez-Henríquez., Francisco (2008). Çetin Kaya Koç (ed.).Cryptographic Engineering. Springer. p. 340.ISBN 9780387718170.Archived from the original on 2024-04-02. Retrieved2020-11-18.
  20. ^ab"Rubberhose cryptographically deniable transparent disk encryption system".marutukku.org. Archived fromthe original on 16 July 2012. Retrieved12 January 2022.
  21. ^"Rubberhose cryptographically deniable transparent disk encryption system".marutukku.org. Archived fromthe original on 16 July 2012. Retrieved12 January 2022.
  22. ^ab"LibreCrypt: Transparent on-the-fly disk encryption for Windows. LUKS compatible.: T-d-k/LibreCrypt".GitHub. 2019-02-09.Archived from the original on 2019-12-15. Retrieved2015-07-03.
  23. ^"LibreCrypt documentation on Plausible Deniability".GitHub. 2019-02-09.Archived from the original on 2019-12-15. Retrieved2015-07-03.
  24. ^ab"TrueCrypt".Archived from the original on 2012-09-14. Retrieved2006-02-16.
  25. ^See itsdocumentation section on "Plausible Deniability"Archived 2019-12-15 at theWayback Machine)
  26. ^"TrueCrypt - Free Open-Source On-The-Fly Disk Encryption Software for Windows Vista/XP, Mac OS X, and Linux - Hidden Volume".Archived from the original on 2013-10-15. Retrieved2006-02-16.
  27. ^Adal Chiriliuc (2003-10-23)."BestCrypt IV generation flaw". Archived fromthe original on 2006-07-21. Retrieved2006-08-23.{{cite journal}}:Cite journal requires|journal= (help)
  28. ^[title=https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg04229.htmlArchived 2016-07-02 at theWayback Machine [Qemu-devel] QCOW2 cryptography and secure key handling]
  29. ^"Encrypted hard drives may not be safe: Researchers find that encryption is not all it claims to be". Archived fromthe original on 2013-03-30. Retrieved2011-10-08.
  30. ^http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3970Archived 2014-09-05 at theWayback Machine Is there any way to tell in Encase if there is a hidden truecrypt volume? If so how?
  31. ^"Plausible deniability support for LUKS".Archived from the original on 2019-10-21. Retrieved2015-07-03.
  32. ^"Julian Assange: Physical Coercion".Archived from the original on 2013-07-23. Retrieved2011-10-08.

Further reading

[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Deniable_encryption&oldid=1322928705"
Category:
Hidden categories:

[8]ページ先頭

©2009-2025 Movatter.jp