Hot answers tagged

14

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 ...


9

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 ...


9

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 ...


9

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 ...


8

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 ...


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 a fixed IV and a random first plaintext block. If we use CFB with an all-zeros IV and a random 16-byte value prefixed to the message ...


8

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. ...


7

Yes, you can do this. If you want to know how to do it (as opposed to just blindly copying a code snipped written by someone else and hoping it'll work), you'll need to understand a little bit about how CFB mode encryption works. First of all, CFB is a block cipher mode of operation. That is, it's a recipe for taking a block cipher like AES, which can ...


6

By parallelizable, what we mean is that the encryption/decryption process can be broken down into multiple tasks that can be run at the same time. For block cipher modes, this means that if we have multiple copies of the block cipher, we can use that to go faster. For example, in CBC decryption mode, the decryption transform of several adjacent blocks is ...


5

Yes, CFB just takes the previous block as the IV for the next block making it a stream cipher. If you modify your iv_dec equal the result of the previous block, however long that is, it should work. Perhaps my answer was confusing because the image included above was for encryption and your asking about decryption. images from Wikipedia


5

RFC 4880, OpenPGP (superseded RFC 2440 which was up to date in 2002) contains a chapter on security considerations, which also discusses the decryption oracle attack Jallad et al described: In late summer 2002, Jallad, Katz, and Schneier published an interesting attack on the OpenPGP protocol and some of its implementations [JKS02]. In this ...


5

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 CBC, ...


5

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 ...


5

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 ...


5

To address the other issue (with the CFB-1, CFB-8, registers, etc.): Note that in the picture we encrypt whole blocks of the previous ciphertext, and xor the result with the next plaintext block, to get a whole new ciphertext block, to encrypt again, etc. So we process the plaintext in chunks of whole blocks, except maybe the last partial block, where we ...


5

First, approximately nothing in modern cryptography cares about the notion of error propagation in block cipher modes of operation—it is an archaic relic of the dark ages of crypto engineering that left us with hopelessly confusing concepts like ‘block cipher modes of operation’ thrust into the faces of hapless application engineers. If you want to detect ...


5

The only reason I can imagine why one would prefer CFB over OFB or CTR is error propagation. Another reason may be technical issues with the relieability of the transmission line. This comes from the fact that if you flip a single bit in an OFB ciphertext then you only get the same bit flipped in the underlying plaintext. But if you flip a single bit in CFB ...


4

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.


4

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 ...


4

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 http://...


4

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 ...


4

No, there are of course other methods of verifying your implementation. Note that there are a few separate steps that can be distinguished: the TEA block cipher; the CFB mode (using the right number of bits to forward); The encoding of the message and ciphertext. First, test your block cipher (without CFB mode of operation) against any available test ...


4

Caesar cipher You are confusing Caesar cipher with block ciphers. In Caesar cipher the ciphertext is calculated as $$c_i = p_i + 3 \bmod 26$$ There is no security in Caesar Cipher. A ciphertext only attack possible, as worst scenario. CFB Caesar cipher $c_i = c_{i-1} + 3 + p_i \bmod 26 $, with $c_0 = IV$ And, the decryption; $p_i = c_i - 3 -c_{i-1} \...


3

Depends on the type of corruption (mangled vs. lost data) and what the segment size is. If you use a segment size equal to the block size, which is most efficient from a computational point of view, you can recover from corruption that changes data. However, you cannot recover from dropped bytes unless you happen to fall on the same block boundary – i.e. ...


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

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$ (...


3

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, most ...


3

In CFB-mode you effectively have a data-dependent stream cipher and you'll need $\lceil\frac{l}n\rceil$ block cipher calls or "cycles" as you call them to process the full message, where $l$ is the mesage length (in bits), $n$ the block size (in bits) and $\lceil\cdot\rceil$ is the ceiling function. However, you get the encryption of the $i$-th plaintext ...


3

First, when the textbook talks about 'dropped bits', they are not referring to bits that are received incorrectly; instead they are talking about transmission errors where certain bits are deleted. One example of this would be if the sender sent the pattern: $$0123456789$$ and the receiver received: $$012456789$$ That is, the byte containing the value 3 ...


2

You asked if there is anything else that can be done, so I'll add some things that mikeazo did not mention. You should make very sure that the IV you are using is a nonce. In other words, you should never ever repeat an IV value using the same key. You should check your known value (prepended padding) before using any part of the decrypted ciphertext. It's ...


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