2
$\begingroup$

We are designing an encrypted file system. We plan to use the PCBC (Plaintext Cipher Block Chaining) encryption mode for encryption. This is because we desire the feature ("small changes in the ciphertext would propagate indefinitely when decrypting") in PCBC.

However, to our best knowledge, PCBC is not a good choice from security and privacy perspective. It is a non-standard mode. It suffers from the adjacent swap attack. It has been cryptanalysis for message integrity.

So, I want to ask questions:

  1. Can PCBC provide confidentiality on message? I just find some materials for breaking the integrity of PCBC, and the book Applied Cryptography saying "Although no one has figured out how to exploit this weakness, Kerberos version 5 switched to CBC mode after the flaw was discovered." I am not aware of anything discussing the confidentiality provided by PCBC.

  2. For integrity, we plan to append a message hash with the content of message for PCBC encryption, instead of using an identical block. But from a cryptanalysis paper which says "In fact, even if the final plaintext block is a CRC computed as a function of all the previous plaintext blocks, an attack along similar lines is still probably possible.", it seems it is insecure even using hash for integrity checking. So I want to ask whether it is secure if I apply this hash in the FIRST block, or if you can give any better suggestions for integrity checking.

  3. We want, (a) the decryption succeeds only when both the entire ciphertext and key are used; (b) if the ciphertext is not integrated, even getting the key, any useful information about the message cannot be extracted. Besides PCBC, do you have any better suggestions on choosing a standard and secure mode to achieve our goal?

$\endgroup$
2
  • 3
    $\begingroup$ What's wrong with normal CBC + HMAC over IV and ciphertext? $\endgroup$
    – Maarten Bodewes
    Mar 21, 2015 at 19:32
  • 1
    $\begingroup$ @Maarten I want to guarantee if the ciphertext is not integrated, even getting the key, any useful information about the message cannot be extracted. If using CBC, given two continuous block ciphertexts $C_1$ and $C_2$ and key, attacker can decrypt the $C_2$ by computing $C_2 = {\sf Dec}(K, C_2) \oplus C_1$. $\endgroup$
    – Jingwei
    Mar 23, 2015 at 6:28

1 Answer 1

3
$\begingroup$
  1. PCBC is provably secure for confidentiality, assuming you use a random IV like with CBC. The attacks you mention are all on the integrity rather than confidentiality of PCBC.

  2. No, you probably cannot construct secure authentication with PCBC and an unkeyed hash. For that you should instead use an actual MAC.

  3. While PCBC propagates errors, it only propagates them towards the end of the message. It sounds like you would want the file to be completely undecryptable if modified. What would work is an all-or-nothing transform. Such schemes are typically unkeyed, but if you encrypt the result of the AONT, the whole thing needs to be correctly decrypted to reveal the plaintext.

So what I would recommend is:

  1. Use an all-or-nothing transform on the plaintext.
  2. Encrypt that using some standard authenticated encryption algorithm. Like AES-GCM or AES-CTR + HMAC.

Note that nonce uniqueness is critical with these encryption algorithms, especially the former where you lose both authentication and confidentiality if nonces are reused.

$\endgroup$
2
  • 1
    $\begingroup$ @Demetri, I undid most of the edit. Highlighting the nonce-uniqueness requirement is a good idea, but I do not want to recommend algorithms that have seen little use and no standardization so far. You can add your own answer if you disagree strongly. $\endgroup$
    – otus
    Apr 6, 2016 at 6:36
  • $\begingroup$ That's a good point $\endgroup$
    – Demi
    Apr 6, 2016 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.