Tag Info

Hot answers tagged

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


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


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

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


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


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


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

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


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

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

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

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

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


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

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

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

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

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

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

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


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


2

In general we nowadays use fixed paddings or a stream mode of operation such as CTR. Authentication tags are usually used to validate integrity/authenticity. Examples of authentication tags are those created by calculating a MAC or HMAC over the ciphertext and additional data such as the IV. In general known plaintext - including the padding - should not ...


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



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