11
$\begingroup$

I'd like to encrypt files deterministically, such that any users encrypting the same plaintext will use the same key and end up with the same ciphertext. The ciphertext should be private as long as the plaintext is.

I plan to use AES-128-CTR with an IV of 0 and the SHA-256 of the plaintext as the key.

IV values are required to produce different output with the same key, but I am explicitly avoiding that behaviour here. I have heard that some ciphers/modes of operation also require the IV to provide randomness for the algorithm and that using an unrandom value (like zero) can be dangerous.

Aside from the repeatable output, is there any danger in using AES-128-CTR with an IV of zero?

Having done a bit more reading, here's my current understanding; verification or corrections appreciated:

NIST SP800-38A §6.5 describes CTR mode as just XORing each plaintext block with the result of ciphering the counter value with the key (where the initial counter value is called the IV).

If the a key is reused with the same IV (or a numerically-close one), this will will produce duplicate values in the stream with which your plaintext is hashed. This presents a large weakness to any attacker who can obtain multiple ciphertexts.

In my specific case, because I'm using a key that's unique to the plaintext it will have a unique stream of data to be XORed with the plaintext, making it secure.

The choice of zero for the IV is as theoretically dangerous as any other constant.

Improve this question
$\endgroup$
2
  • $\begingroup$ Is your construction ideal for achieving the properties you want? Encryption allows you to recover a copy of the plaintext if you know the key. In your construction, you need to already have a copy of the plaintext to compute the key and recover the plaintext. Can you not achieve the same properties (deterministic, hidden output if you don't know the input) by simply hashing the message and treating the output as your "ciphertext"? $\endgroup$
    – PulpSpy
    Jan 4, 2012 at 15:02
  • 1
    $\begingroup$ @PulpSpy This is a standard convergent encryption scheme. You don't need a copy of the plaintext file to decypt, you only need its hash, which is much shorter. $\endgroup$
    – CodesInChaos
    Mar 17, 2012 at 9:44

1 Answer 1

Reset to default
8
$\begingroup$

Well, no, in your case, a constant IV is not a problem. With counter mode, the rule is that you cannot reuse the same IV with the same key. However, it is perfectly fine to use the same IV with different keys, and that's what you're doing.

One minor correction to what you have (that doesn't directly relate to your question): you state that there are problems if "a key is used with the same (or a numerically-close one). Actually, as long as the IVs are different, "numerically-close" IVs are not an issue. In fact, it is actually pretty common to select counter mode IVs using a message counter (e.g. the first message gets IV 0, and second one gets IV 1, etc.)

However, I do have one question: how do you expect someone to decrypt the ciphertext? If what you're doing is generating a hash of the plaintext, why don't you just go with the SHA-256 hash of the plaintext?

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ This is for a freenet-style peer-to-peer scheme: the URL will contain the hashes of both the plaintext (private) and the ciphertext (public). The ciphertext's hash is used to locate it on the network, after which it is decrypted and verified using the plaintext's hash. $\endgroup$
    – Jeremy
    Jan 4, 2012 at 6:29
  • $\begingroup$ My tentative understanding is this: NIST SP800-38A Appendix B warns that "The initial counter blocks for each message that is encrypted under the given key must be chosen in a manner than ensures the uniqueness of all the counter blocks across all the messages". It also defines that the standard way of incrementing the counter value as what seems to be ordinary unsigned binary addition, so an IV of 0 in one message would result in its first block being ciphered in the same way as the second block of a message with an IV of 1. $\endgroup$
    – Jeremy
    Jan 4, 2012 at 6:42
  • 3
    $\begingroup$ @Jeremy, poncho: There are different understandings of what exactly constitutes the IV: either the whole 128 bit starting counter (to which then the per-block-in-message counter is added), or a smaller (say 64 bit) number which is then concatenated to the per-block-in-message counter (which then is limited to 64 bits). In the latter case, you can simply increment the per-message IV by one for the next message, in the first case encrypting a message burns a whole series of (numerically-close) IVs. $\endgroup$
    – Paŭlo Ebermann
    Jan 4, 2012 at 12:13
  • $\begingroup$ @PaŭloEbermann are you sure? I read it and I think they meant that the NONCE (officially not the IV) consists of the prefix + counter - not that it matters, as long as you treat it as a counter (encoded in [blocksize] bytes in big endian mode, or you'll loose compatibility). $\endgroup$
    – Maarten Bodewes ♦
    Jan 7, 2012 at 16:51
  • 1
    $\begingroup$ @user153882: he can compute the xor of the two plaintexts, which may be enough (depending on the contents of the plaintext) for him to deduce the contents of the plaintexts. $\endgroup$
    – poncho
    Feb 5, 2017 at 3:31

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.