Paper: Plausibly Deniable Encryption with Large Language Models (ICLR-2024)

Reviewer comment (Theory):
This assumes that LM also operates like an encryption scheme. In fact, the core to creating deniable encryption lies in LM, so AES operates only as an output encryptor in the proposed scheme. Thus, it appears to rely only on LM when analyzing the security or characteristics of actual deniable encryption. Excluding AES, the evidence for whether the proposed LM is a reliable encryption method appears to be weak other than the assumption that it "looks random."

Author response:
Firstly, we point the reviewer to our global response about the definition of deniable encryption that we are adopting and the properties therein. We hope this already makes things more clear. As the reviewer points out, we rely on AES as an underlying primitive to guarantee the security of our algorithm, but we would like to highlight that analyzing the behavior of our method requires a unified view where both the language-model encoder and the underlying encryption algorithm (AES in our case) are considered as a single “block”. In our work, AES is not merely used as an output encryptor, but also as an entropy generator when the message is decrypted using a random key (i.e. a DRBG), which results in the generation of a random plausible message. In this scope, the LM-based encoder/decoder is simply used to map the distribution of real messages to/from the uniform distribution, and not as an encryptor. We have made this more clear in the updated PDF, more specifically in Appendix A.1 and A.2, where we formalize our security scheme explicitly.

Reviewer comment (Theory):
Does the proposed method assume a scenario that can be applied in practice? It seems that an attacker would also be able to see that EOS was broken, and thus he/she realizes that the wrong key was used and the output message is not real.

Author response:
> attacker would also be able to see that EOS was broken

This is indeed a very important issue and something we considered by design, and for which we devised a principled padding strategy to avoid precisely this detection mechanism. We discuss this aspect in the first paragraph of Section 3.5 (Implementation details).

Reviewer comment (Theory):
What is the reason for saying encoded plaintext is indistinguishable? Can the encoding be considered an encryption scheme? So why do you need AES?

Author response:
> Can the encoding be considered an encryption scheme? So why do you need AES?

As mentioned above, the encoding is not an encryption scheme. Since we assume a white-box model (where the model weights are known to all parties as well as the attacker), the encoding/decoding operations are simply used to deterministically transform one distribution into another (in our case, the message distribution to/from the uniform distribution produced by AES decryption). Furthermore, the encoding itself is not parameterized by a key, so it needs to be paired with a shared-key encryption primitive.

Reviewer comment (Theory):
A detailed characterization on whether the encoding/decoding part can possibly cause a difference on the plaintext in the « normal » situation in which the encryption is performed normally is currently missing from the paper. For instance, what happens if the value of k is less than 32, does it mean that the decoding will result in a different message with a high probability?

Author response:
A key property of our method is correctness (we clarified this in Appendix A.1). If the message is decrypted with the correct key, it can always be decoded exactly (the encoding/decoding process is deterministic and lossless). The value of k describes the quantization granularity of the output probability distribution, and can be considered part of the protocol. As long as the parties agree on the same value of k, the decoding will be correct. The only issue with low values of k is the introduction of quantization errors (which might bias the model and make detection easier), but this is not a problem in the Huffman variant as it does not rely on a choice of k. We also refer the reviewer to the section on implementation details, where we describe engineering considerations to ensure that the model encoding/decoding process is deterministic and thus correct (e.g. quantization).

Reviewer comment (Theory):
The security analysis should also be more detailed. For instance, it is not clear what are « the optimality assumptions » mentioned in the paper that makes the ciphertext indistinguishable from white noise. Overall, the paper lacks a detailed proof of the security of the proposed scheme. In addition, it also lacks as a review of the main existing families of definitions of the concept of plausible deniability and a detailed discussion on how the proposed notion compares to this.

Author response:
We agree and have formalized our security model and assumptions in detail in the Appendix A.1. In the same section, we also describe our main differences w.r.t. other deniability formulations (notably Canetti et al. ‘97). Finally, we discuss proofs of our security model in the Appendix A.2.

Reviewer comment (Theory):
The transmission of prompting as as external unencrypted information alongside the ciphertext seems to defeat the purpose of plausible deniability as it will directly indicate to the adversary that there is a tentative to generate a message providing plausible deniability.

Author response:
Indeed, prompting would provide context regarding the topic of the message, but would still provide some level of deniability regarding its content (e.g. if the attacker knows that the receiver is expected to receive an address of a meeting and coerces the receiver into providing a key, the receiver can provide a key that generates a fictitious address). Nonetheless, prompting is an optional feature (the approach can also be used in unconditional mode). We would also like to mention that attempting to generate a message providing plausible deniability (where the attacker has a white-box knowledge that such a protocol is being used) is still a valid scenario, as the content of the original message can be denied. Except for steganography (where the content can be denied entirely), knowledge that a certain protocol is being used is a realistic assumption shared by many other schemes.

Reviewer comment (Evaluation):
It seems that even when the decoding is performed with a different key that a lot of the semantics is preserved (for instance an address is still decoded towards an address). This seems to result in the possibility for an adversary to infer some significant information about the cleartext, which is in contrast to other proposal for deniable encryption. This might be due the information contains in the prompt, which significantly contraints the possible decryption but still this leads to a non-trivial leakage.

Author response:
This is because the text demos in the paper were generated with prompting (the prompt is also shown), but as explained earlier it is also possible to use the model without prompt, which will generate a completely random/unrelated message. By contrast, the demos on ImageGPT were generated unconditionally.

Reviewer comment (Writing):
What does a consensus on a model means in practice (introduction)?

Author response:
The parties need to agree on the same model (architecture and weights), so that the encoding/decoding process is fully deterministic and correct (the receiver can reliably decrypt the ciphertext into the original message intended by the sender).