Tag Info

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

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

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

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

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

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

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

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

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

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

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

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} \... 4 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 ... 4 Yes, with some more ciphertext. The CFB mode encryption equations; \begin{align} I_0 &= \text{IV}\\ I_i &= \big((I_{i-1} \ll s) + C_i\big) \bmod 2^b,\\ C_i &= \operatorname{MSB}_s\big(E_K(I_{i-1})\big) \oplus P_i\\ \end{align} and decryption equations; \begin{align} I_0 &= \text{IV}\\ I_i &= \big((I_{i-1} \ll s) + C_i\big) \bmod 2^b,\\ ... 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 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 the2^{24}$plaintexts consisting of the 3 bytes$uvw0$(... 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 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 "Recovery", in this case, does not mean that the full plaintext can be recovered even if part of the ciphertext is missing.* Instead, the "eventual recovery" property of self-synchronizing stream ciphers simply means that dropping one block from the ciphertext doesn't turn all decrypted plaintext after that block in the same message into garbage, as it ... 3 simplified CFB supports random read access. but what about the real CFB where we have a shift register? Sure it does; actually, it's not that difficult. In CFB, the "plaintext" submitted to the underlying block cipher is the previous$b$bits of the ciphertext (where$b\$ is the block size). The shift register is there just to allow us to track ...

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

2

There are two possible ways (I can think of) an attacker could mess you up here, but they both stem from very poor design. So I don't know how realistic they are. Note: the following figure assumes a 64-bit blocksize CFB is only self synchronizing against insertions/deletions of a specific length. The length is determined by the shift register. If the ...

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