# Tag Info

10

Thomas is correct; there's no attack on CFB mode if you can predict the IV; NIST is just being cautious. With CBC, the value of the first encrypted block $C_0 = E_k( IV \oplus P_0)$, where $IV$ is the IV used for that packet, $P_0$ is the value of the first plaintext block, and $E_k$ is the evaluation of the block cipher. If an attacker can predict the ...

8

One obvious thing that it is vulnerable to a known plaintext attack that truncates the known message. This attack is quite simple; suppose the attacker knows a message $(P_1, P_2, ..., P_n)$ and the corresponding ciphertext $(C_1, C_2, ..., C_n, T)$ (using some IV; we don't care what it is). Here is how the attacker can generate a ciphertext that would ...

8

I recommend that you prepend a random 16-byte prefix. Prepending a random 16-byte prefix, before encrypting with your CFB mode, will be just as good as using a random IV. The argument is pretty similar to Using CBC with fixed IV. If we use CFB with an all-zeros IV and a random 16-byte value prefixed to the message before encryption, as you suggested, we ...

8

I found a little more info on Google, so let me provide a partial answer to my own question. In particular, I found a post by David Wagner to sci.crypt in 2004, titled "IND-CPA for CFB mode", which in turn led me to a paper titled "Practical symmetric on-line encryption", published in FSE 2003 by Fouque, Martinet and Poupard. In this paper, the authors ...

7

CFB with a fixed IV? Yikes! That is completely insecure: for the first 16 bytes of plaintext, it is even worse than ECB mode, and that's saying something. Please go enlighten whoever thought it was a good idea to expose this as the only mode of encipherment available (or even one among multiple options). Let me elaborate. It sounds like the baseline is ...

6

The modes you are referencing are specifically modes of operations for block ciphers, and therefore are not directly applicable to hash functions. Block cipher operations take 2 inputs, the key and a block-sized input value, and output a block-sized keyed permutation of the input. Hash functions take a variable length input, and output a fixed length value. ...

6

Actually, for CFB mode, the IV is the same size as the block size, 16 bytes. As for your question "does keeping the IV secret help security", the answer is "not really". CFB mode processes the message in blocks, and for each block of plaintext, combines that with the previous block of ciphertext to generate the next block of ciphertext. What the IV is ...

4

Actually, s is in CFB mode to handle transmission channels for the encrypted data that can add or drop individual bytes. In the olden times (say, the 70's), it was common to transmit data over serial channels, for example, RS-232. These channels were not perfect, and one common error we see is that if the transmitter sent 7 bytes, the receiver might get ...

3

Yes, it is correct. Just follow the bits in the decryption pictures on the Wikipedia page about modes of operation. Modes of operation don't have to have a meaning compared to other modes of operation. I don't see CFB or OFB used too much anymore. OFB with partial feedback has been shown to be less secure, so that shouldn't be used anymore. Currently the ...

3

Forget OFB mode. You should use CTR (counter) mode. It has the best bounds, and is parallelizable. This means that when you are using the AES-NI instruction set, encrypt with CTR is about 7 times faster than CBC, OFB etc. If you encrypt in OpenSSL you will get this performance. For a good thorough analysis and comparison of modes of operation, see ...

3

According to Handbook of Applied Cryptography (15.3.2, ii), ANSI X9.9 (which SEJPM mentioned in the comments but I have no access to) defined CFB-MAC only as a compatible alternative to CBC-MAC: The X9.9 MAC algorithm may be implemented using either the cipher-block chaining (CBC) or 64-bit cipher feedback (CFB-64) mode, initialized to produce the same ...

3

No, because CFB isn't commutative. You can see this by looking at the decryption of double-CFB encrypted ciphertext. Even assuming a constant IV (so single-use keys), if you decrypt in the wrong order it cannot work, since the ciphertext is used as input into the block cipher and will differ from what was used with that key when encrypting. The exception, ...

3

For CFB mode: NEVER make the IV constant, it must be unique for every message. The IV does not need to be secret or impossible to predict, only unique. It can be a simple counter, for example. The IV may not be chosen by the attacker. I can not emphasis UNIQUE enough, if your IV is not unique you've basically lost all security.

2

At least one thing goes very wrong: if an adversary can obtain the ciphertext for a few short chosen plaintexts and the same reused key/initial state, that allows reconstructing the state because the indexes vary in a controlled way. That certainly works if we obtain the ciphertext for the $2^{24}$ plaintexts consisting of the 3 bytes $u$ $v$ $w$ $0$ ...

2

I have a problem with OFB mode, because I have heard that it is stronger than CFB. On the contrary I would say that CFB is stronger. OFB means encrypting the IV again and again to produce the keystream. If you end up in a cycle, the keystream will start repeating itself. (This should not be a practical weakness, but why chance it?) CFB is more like ...

2

There is no real advantage, other than the fact that it allows you to convert a block cipher into a stream cipher securely. Since there has been a large amount of research put into block ciphers and ciphers such as AES are commonly implemented in hardware (such as AES-NI), it allows for reuse of the primitives. Side note: the nonce generally does not need ...

2

I've been thinking a little bit about it, and now I think it is possible, but you have to consider the generalization of CFB in ISO 10116 (I don't have access to the ISO 10116 standard, so I will assume that the description by Rogaway is correct). The generalization of CFB from the ISO standard seems to have two main changes: The feedback block (FB), of ...

1

A predictable nonce that cannot be controlled by the adversary is safe as a CFB IV (with some assumptions), as shown in the other answers. However, a nonce that can be chosen by an adversary is not safe against chosen plaintext attacks, as shown in Evaluation of Some Blockcipher Modes of Operation (page 36): Assume s = n. The adversary asks its oracle to ...

1

Cipher Feedback mode turns the block cipher (AES) into a self-synchronizing stream cipher which feeds back the full ciphertext block as the next IV. If you encrypt something smaller than a multiple of the block size, it will not use all of the block cipher output to create the ciphertext, just the amount it needs. Therefore there is not a padding ...

1

Initialization Key hash function hashstring Configuration: E is Rijndael with a block size and key size of 256 bits Input: keystring Output: hash The keystring is padded up with bytes valued zero and split up in blocks of 256 bits $S_0$ to $S_n$; The key blocks $K_0$ to $K_n$ are generated, where $K_0$ consist of $S_0$. The following blocks - if any, ...

1

It just leaks information about the blocks with the same IV. Specifically, if the two messages encrypted with the same IV started with blocks $M_0$ and $M'_0$, then the attacker learns the value $M_0 \oplus M'_0$ (and if those where the same, then the attacker also learns the corresponding xor with the second block, etc) However, the attacker learns ...

Only top voted, non community-wiki answers of a minimum length are eligible