Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

share|improve this question
    
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"? –  PulpSpy Jan 4 '12 at 15:02
1  
@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. –  CodesInChaos Mar 17 '12 at 9:44
add comment

1 Answer 1

up vote 4 down vote accepted

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?

share|improve this answer
    
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. –  Jeremy Banks Jan 4 '12 at 6:29
    
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. –  Jeremy Banks Jan 4 '12 at 6:42
2  
@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. –  Paŭlo Ebermann Jan 4 '12 at 12:13
    
@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). –  owlstead Jan 7 '12 at 16:51
    
@owlstead: I'm not sure what Jeremy and poncho meant here, but the important thing is that you should never reuse a nonce, and this can be reached either by chosing a new (128-bit) IV for each message (then you get your nonces by incrementing the complete IV), or by incrementing the prefix for each message. Of course, the receiver should do it the same way for interoperability. –  Paŭlo Ebermann Jan 8 '12 at 11:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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