Fandom

DSZQUP XJLJ

Deniable encryption

566pages on
this wiki
Add New Page
Talk0 Share

In cryptography and steganography, deniable encryption is encryption that allows its users to convincingly deny the fact that the data is encrypted or, assuming that the data is obviously encrypted, its users can convincingly deny that they are able to decrypt it. Such convincing denials may or may not be genuine, e.g., although suspicions might exist that the data is encrypted, it may be impossible to prove it without the cooperation of the users. In any case, even if the data is encrypted then the users genuinely may not have the ability 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.

Normally ciphertexts decrypt to a single plaintext and hence once decrypted, the encryption user cannot claim that he encrypted a different message. Deniable encryption allows its users to decrypt the ciphertext to produce a different (innocuous but plausible) plaintext and insist that it is what they encrypted. The holder of the ciphertext will not have the means to differentiate between the true plaintext, and the bogus-claim plaintext.

FunctionEdit

Deniable encryption allows an encrypted message to be decrypted to different sensible plaintexts, depending on the key used, or otherwise makes it impossible to prove the existence of the real message without the proper encryption key. This allows the sender to have plausible deniability if compelled to give up his or her encryption key. 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.

ScenarioEdit

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

  1. Alice is the wife of Bob, who suspects his wife is engaged in adultery. She 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 a harmless message M1 about boring math stuff for Carl (intended to be revealed to Bob in case of discovery) and a burning love letter M2 to Carl. She constructs a cipher-text C out of both messages M1, M2 and emails it to Carl.
  3. Carl uses his key to decrypt M2 and possibly M1 (in order to know 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 message M1 about boring math stuff to Bob. Since Bob does not know the other key, he has to assume that there is no other message M2.

Another possible scenario involves Alice sending the same ciphertext to Bob and Carl, to whom she has sent different keys. Bob's key could decrypt the ciphertext to a claim that Carl has maligned Bob, and Carl's key could decrypt the ciphertext to a claim that Bob has maligned Carl. Under the assumption that neither Bob nor Carl can find out each other's keys, Alice's ruse would never be discovered unless Bob and Carl find out that they have different keys.

Modern forms of deniable encryptionEdit

Modern deniable encryption techniques exploit the pseudorandom permutation properties of existing block ciphers, making it cryptographically infeasible to prove that the ciphertext is not random padding data generated by a cryptographically secure pseudorandom number generator. 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 form of deniable encryption is sometimes referred to as "steganographic encryption".

One example of deniable encryption is a cryptographic filesystem that employs a concept of abstract "layers", where each layer would be decrypted with a different encryption key. Additionally, special "chaff layers" are filled with random data in order to have plausible deniability of the existence of real layers and their encryption keys. The user will 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. 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. The timestamps of these files are always randomized. Examples of this approach include Rubberhose filesystem and PhoneBookFS.

Another approach utilized by some conventional disk encryption software suites is creating a second encrypted volume within a container volume. The container volume is first formatted by filling it with encrypted random data[3], 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. Concerns have, however, been raised for the level of plausible deniability in hiding information this way – the contents of the "outer" container filesystem (in particular the access or modification timestamps on the data stored) could raise suspicions as a result of being frozen in its initial state to prevent the user from corrupting the hidden volume. This problem can be eliminated by instructing the system not to protect the hidden volume, although this could result in lost data. FreeOTFE[4] and BestCrypt can have many hidden volumes in a container; TrueCrypt is limited to one hidden volume.[5]

Needless to say, insecure block ciphers or pseudorandom number generators can make it possible to compromise the deniability of such filesystems. To escape the assumption that the used pseudorandom number generation is cryptographically secure, it has been advised to instead fill the encrypted space with pseudorandom data which has itself been encrypted, thus being protected by a separate encryption key since encrypted data is impossible to differentiate from encrypted data[4] In addition to that, the flawed use of block cipher modes of operation can also compromise the cipher algorithm due to watermarking attacks.[6]

Malleable encryption Edit

Some in-transit encrypted messaging suites, such as Off-the-Record Messaging, offer malleable encryption which gives the participants plausible deniability of their conversations. While malleable encryption is not technically "deniable encryption" in that its ciphertexts do not decrypt into multiple plaintexts, 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 (see HMAC), he is also able to forge messages in the conversation. This is used in conjunction with perfect forward secrecy to assure that the compromise of encryption keys of individual messages does not compromise additional conversations or messages.

SoftwareEdit

See alsoEdit

Template:Portal

ReferencesEdit

Further readingEdit

ru:Двусмысленное шифрование

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.