Tag Info

13

Contrary to what Stephen says, you absolutely can compute the tag in parallel. Here's how it works; the tag computation is essentially "assemble the AAD, data, the length field and $Encr(Nonce)$ into a series of values $x_n, x_{n-1}, x_{n-2}, ..., x_0$", and then "compute the polynomial $x_nh^n + x_{n-1}h^{n-1} + x_{n-2}h^{n-2} + ... + x_0h^0$ This ...

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

The modern trend for encryption-only modes is clearly CTR, which has a number of advantages over other modes: no padding is needed (contrary to CBC); the computationally-intensive part can be efficiently performed with the IV (and key) only, before the plaintext or ciphertext is available (contrary to CBC, CFB); the computationally-intensive part can be ...

7

There are probably quite a few good reasons for this, although I don't expect that a scientific answer can be composed (as you would need to use a survey, and I've never heard of such a thing for modes of operation). Let me list a few possible reasons: Developers don't know about CTR mode of operation; most questions on StackOverflow are about ECB and CBC ...

6

SIV is a mode specially designed for this purpose. SIV-AES would be a good choice, but it has the same issues as AES-wrap; not many implementations. If you use a GCM you should make sure that the IV is unique (if your plaintext is ever not random you would otherwise be in problems). As for the password based key derivation function: yes, PBKDF2 is good, ...

5

I know that some of them are pretty hard to crack, but since they are so commonly known is it even practical to consider using something like that as an encryption method considering the algorithms for encryption and decryption are commonly known (from a security perspective)? In fact, this is exactly what we want. Schneier's law Anyone, from the ...

5

The GCM flowchart on Wikipedia and my intuition support the notion that some of the GCM work can be done in parallel. At the very least you can do each $E_k(ctr)$ operation in parallel, but it doesn't look like you should be able to parallelize the authentication, as each $mult_H$ requires the output of a previous call as its input. Edit: poncho explains why ...

4

If you have an error in a cipher text block you can generally represent this as: $$C'=C\oplus\Delta$$ Now if you try to decrypt this block using the previous ciphertext block $IV$ as IV you get $P'=IV\oplus D_K(C\oplus\Delta)$ which is completely unrelated to $P=IV\oplus D_K(C)$ assuming the block cipher acts as a pseudo-random permutation. As the input ...

4

It is certainly wrong to state that "MAC can only be produced with AES in CBC and CFB mode", but there seems to be a simple reason that people were inspired by these modes when thinking up possible MAC constructions: They carry along some state that incorporates information from the message while traversing the input blocks. In both modes, encrypting a block ...

4

There are two well-known Encryption modes, that can construct a $mn$-bit tweakable blockciphers from a $n$-bit blockcipher ($n=64$ for DES) with $1\le m\le n$. The older one is CMC, being not parallelizable. It was superseeded by Encrypt-Mix-Encrypt (EME), which is parallelizable. The basic idea of the two algorithms is to encrypt each block of input data ...

4

What is this method/algorithm/construction called? Dunno; this is a new one on me. Is it as secure as CBC implemented the normal way? Should be. Modeled as an abstract 'take plaintext, output ciphertext' model, this method (with a random last ciphertext bits) has precisely the same ciphertext output distribution as CBC mode (with a random IV), ...

4

Actually, Maarten isn't quite correct; in most cases, the counter doesn't have to be updated in constant time (because it's not secret); however in one case it does: GCM with an IV size that's not 12 bytes. The reason the counter needs to be secret in this case is not because how it is used, but how it is generated. It is initialized to ...

3

In addition to the tweakable enciphering schemes in the comments, I'll leave this reference here: https://eprint.iacr.org/2009/356.pdf It essentially shows (in the ideal cipher model) that using an n-bit block cipher in a three-round Feistel construction gives you a 2n-bit block cipher.

3

The standard for full-disk encryption (FDE) is XTS mode or ESSIV-AES-CBC. XTS tweaks each block within each sector differently (and hence avoids ECB's problems) and is considered the best choice available at the moment. ESSIV-AES-CBC works by using AES-CBC with the IV being the hash of the sector index. The problem with this mode is that you can flip bits ...

3

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ...

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

Block ciphers map bit strings of fixed length to other bit strings of the same length. Hence, using only the block cipher primitive, you can't encrypt more than one block (typically 16 bytes), which is of course undesirable. The straight-forward (but bad!) way around this limitation would be to split up the message into chunks of block length and ...

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

Your mode is essentially equivalent to CFB mode, except that: you've reversed the order of the blocks in the message, and you're using the block cipher in the opposite direction than usual. Neither of those differences should have any direct security implications (since all standard block ciphers have the same security properties in both directions), ...

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

2

No, the IGE encryption cannot be parallelized. Also the decryption of IGE/ABC is serial. The input to the block cipher for encryption is the ciphertext of the previous block xor'd with the plaintext (and the result is then xor'd with the previous block plaintext). For decryption, you have to XOR the ciphertext with the plaintext of the previous block ...

2

This all depends on the IVs. If they are independently generated, the IVs will not only be different (so $IV_1 \neq IV_2$), but also their sequences will not overlap with overwhelming probability. In that case, then everything should be fine, so $C_2 = E(K,(nonce,IV_2))$, and $C_1 = M_1 \oplus E(K,(nonce,IV_1))$. However, if they are reused (so $IV_1 = ... 2 It doesn't make too much sense at all to send the IV together with the key. The whole idea of an IV is that it is unique per key. But if the key changes value each time, then any IV is unique. So you could use a static IV or even an IV that consists of all zeros. In that case you only need to worry that you don't reuse the key at other locations in the ... 2 Dmitry's suggestion to use AES in counter mode sounds good to me, assuming that you only need confidentiality, and not integrity protection. (Counter mode, like most stream ciphers, is very malleable.) One trick you can use to save a bit of space is to use the current time as part of the nonce. (Of course, this only works if your devices have fairly well ... 2 A self-made modification to CBC is a bad idea, since your "IV" will not be random enough, whereas it must be truly random for CBC. Stream cipher is a good idea. You may use AES in the Counter mode, or you could use Salsa20, or any other eStream portfolio cipher (software and hardware implementations are available for all of them). Ensure that you have ... 2 Look at how the keys$K_1$and$K_2$are used in CMAC (pdf, Section 6.2): If$M_n^*$is a complete block, let$M_n = K_1 \oplus M_n^*$; else, let$M_n = K_2 \oplus (M_n^*||10^j)$, where$j = nb-Mlen-1$. They are combined with message blocks using XOR. So they must be equal in length to the block size, not the key size (if different), of the ... 2 The schemas from the relevant Wikipedia page really explain it all: As you see in the decryption schema, the IV is used for a single XOR that yields the first plaintext block; it is obvious that the IV impacts only that block. When encrypting, though, modifying the IV alters the first ciphertext block, then the second ciphertext block, and so on. The ... 2 PCBC is provably secure for confidentiality, assuming you use a random IV like with CBC. The attacks you mention are all on the integrity rather than confidentiality of PCBC. No, you probably cannot construct secure authentication with PCBC and an unkeyed hash. For that you should instead use an actual MAC. While PCBC propagates errors, it only propagates ... 2 The output of the block cipher is used as the new key, and also passed to the "output block" function, which is referenced in the NIST document as$B^m_R$. The purpose of the IV$R$and the function$B^m_R$is to reduce the output to a smaller size in a manner that hides the true output of$f\$. Too large an output allows key recovery. The output of this ...

2

Yes, there are modes of operation that achieve the property that you are describing. For example, the Propagating Cipher Block Chaining (PCBC) mode of operation: This mode is similar to CBC but the output for each block is propagated to the input of the next one, so a small error will propagate indefinitely, both for encryption and decryption. There may ...

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