# Tag Info

16

CBC does not perform authentication This property makes it less suitable for places where authentication is required, basically any transport protocol. TLS uses CBC, but by default performs authentication over the plain text instead of the ciphertext, which opened up a host of attacks. CBC can be used here, but it is error prone and may require an ...

9

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m ... 8 I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ... 8 There are several scenarios where you wouldn’t want to use AES in CBC mode. In CBC mode, each block is dependent on a previous one. As @fgrieu nicely hinted at in his comment, using CBC means that if you have a large, encrypted file and you only want to update/change/modify a tiny fraction of it, you would have to follow the decrypt-modify-encrypt path each ... 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 ... 7 First, the fact that the data is "easy" to guess (in the sense that an attacker has a one-in-2^32 or a one-in-2^64 chance of guessing correctly) doesn't mean much if the attacker has no way of checking if his guess is correct. Or at least, it's not a problem with the cryptography. Second, even if he does have that ability, the problem of protecting your ... 7 The other answer is correct in general. However, if your messages are all exactly one block long (or all one block after padding), ECB is a secure MAC. A PRP looks like a PRF up to half its bit length, i.e. up to$2^{64}$blocks for AES. A secure PRF is a secure MAC of the same size. Thus, AES ECB used on 128-bit messages is a secure MAC as long as you use ... 6 The point of the IV is to prevent the same (key,IV) from ever being used for two different messages in practice. This is an absolute requirement for stream ciphers or block cipher modes such as CTR that are effectively stream ciphers, because re-using the same (key,IV) pair lets an eavesdropper trivially obtain the XOR of two plaintext messages, which means ... 5 GCM Personally, I would go for GCM (Galois Counter Mode) since it is efficient – meaning: it handles pretty much everything you’ld expect from it, while other modes sometimes tend to lack a specific feature here and there (see image below for a comparison that shows what I’m hinting at). Also, GCM has a pretty good performance (assuming non-flawed ... 5 You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset. Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ... 5 If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset ... 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 ... 4 Like the other answers say, it does not always have to be the case. One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value. 4 Well,$\operatorname{GHASH}$might be better understood as the polynomial: $$\operatorname{GHASH}_H(X_1, X_2, ... , X_{m-1}, X_m) = X_1 H^{m} + X_2 H^{m-1} + ... + X_{m-1} H^2 + X_m H^1$$ where addition, multiplication and exponentiation are in the field$GF(2^{128})$. These addition, multiplication and exponentiation operations act algebraically quite a ... 4 Encrypting big amounts of data is no problem for block cipher - if you remember a few important things. You can't encrypt plaintext which is bigger than the block size. You need to do some addition work. Most cipher operation modes first divide the plaintext into blocks of the size of the cipher. Now you can do different things: How about just encrypting ... 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), ... 3 The catch how ever is that if a small part of the file is given along with the location of that bytes from the beginning of the file we should be able to decrypt just that piece. Normal CTR mode encryption allows one to decrypt any block of the file independent of the rest, so no need to invent your own mode. With AES the block size is always 128 bits, ... 3 I would pick EAX as it is by far the simplest to implement and therefore to understand and audit. It is reasonably fast if based on AES. GCM seems quite popular, but I personally see a number of issues with it: it is very difficult to implement in software (which is not surprising, since it was developed with hardware in mind). it is slower than it seems ... 3 No, usually you are required to use hybrid cryptography. ECB, CBC etc. are defined for block ciphers. Although you could possibly apply them to asymmetric cryptosystems, it would make little sense: performing sequential asymmetric cryptography is not efficient, block ciphers are much more efficient in general there will be a lot of overhead per block, ... 3 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 ... 3 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 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 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 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 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 ... 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

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

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