# Tag Info

17

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...

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

It depends on which cipher suites and extensions the client and the server implement, enable and negotiate. The default operation in TLS 1.2 and earlier, is MAC then Encrypt. This corresponds to alternative a in the question. In TLS 1.2 it is possible to use AEAD cipher suites. Such cipher suites (e.g. AES-CCM but not AES-GCM) might correspond to ...

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

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...

5

In short: the question does not explain well the notion of asymmetry in ECC; and the exposition is not how Elliptic Curve Cryptography works. A reasoning sidestepping the notion of Discrete Logarithm Problem over a finite group can not really explain asymmetry as meant in ECC. Asymmetry is in the knowledge Alice and Bob have about the key, not asymmetry of ...

4

I'll take this in parts: But this is clearly not the case when you're doing Encrypt Then Mac. When you do that you provide authentication to something that already has authentication (to decrypt we need to know the key). Encryption, by itself, does not provide authentication. why use a MAC when we can use a hash instead: E(m|h(m))? Here is a ...

4

The Encrypt then MAC is done in general in order to be sure to decrypt into the correct plaintext, without risking of parsing a non-authentic plaintext message. If you don't MAC the IV, then Mallory (attacker that can tamper with messages as a man-in-the-middle) can modify the IV and your MAC will be still validated as good. So you will decrypt into an ...

4

Yes, this should be secure, as it is largely compatible with KDF1 and KDF2 which basically use a 4 byte big endian encoding of the counter instead of a direct ASCII conversion to a byte. Note that this construct works fine for master keys (short length, high entropy) but may be vulnerable to length extension attacks if larger input is allowed. However, if ...

4

The property you are probably looking for is whether the MACs are PRF. With HMAC it depends on the pseudo-randomness of the hash function used. If the hash is a PRF then the HMAC is as well. However, that is not required for MAC security of HMAC, so it's not necessarily true even with a secure HMAC. See New Proofs for NMAC and HMAC: Security without ...

4

Yes, TLS works by MAC then encrypt. This is the source of a large number of padding-oracle-type attacks over the past few years.

3

Anon2000 - as currently constructed your mode is fatally flawed. Given two known messages encrypted with the same key (i.e. where the attacker knows the plaintexts) that are each at least two blocks in length (not counting the IV or final validation block), the attacker can trivially forge at least two other 'valid' messages (and many more than that if the ...

3

I would think these numbers would have been put on the google search engine, and yield (probably) many hits. This assumption is wrong. Certificate serial numbers are not indexed by common search engines, nor are they typically posted to any HTML site. Frankly, I'm not sure why you would assume they'd be indexed. The Wordpress certificate is used for ...

3

The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ...

3

I'll answer the related questions in order: No, because a ciphertext (generated from a key stream generated by a stream cipher) should be indistinguishable from random data, and a MAC should be as well. No, because #1 depends on the secret, and the secret was derived using a Diffie-Hellman key agreement algorithm, using the given curve. To know ...

2

Depends on what you mean by Keccak. There is actually a slight issue here that not all 256-bit Keccak variants have 256-bit preimage resistance. SHA3-256 (in the current SHA-3 draft) does have 256-bit preimage, but if you are using Keccak with 256-bit capacity it only has 128-bit preimage resistance. At least some of the earlier documents had 256-bit output ...

2

The really important thing is, not encrypt-and-mac. The other two, you can debate, but both are at least theoretically sound -- one might just practically be better than the other. Encrypt-and-MAC falls apart for a very simple reason, though: the MAC is not meant to keep the plaintext secret. The MAC is based on the plaintext. Authentication is not designed ...

2

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id ...

2

I did some more research and yes it does include both AD length and ciphertext length, so is not vulnerable to a length extension attack as length is part of GCM GHASH. Based on NIST SP-800-38D (PDF) page 18 len(A) and len(C) are both part of the input into the GHASH function. And double-checked this in an implementation gcm_finish method: both lengths are ...

2

Fgrieu has already posted a good answer, which I won't try to repeat. However, here are a few additional observations: For an embedded system, you may want to consider using CMAC-AES instead of HMAC, since you can reuse your AES implementation, and don't need a separate hash function. Further consider using SIV mode (RFC 5297). It's very similar to ...

2

When we have regions of the packet that we only authenticate but not encrypt, that happens because we have data that we want to bind to the encrypted region, but we don't need to include within the encrypted region. Examples of this are: For IPsec, we include the sequence number (as a part of the ESP header). We include that within the authentication ...

2

If you want to encrypt a long message with authenticated encryption, you should split it into many small segments (e.g. 4KiB each), with each fragment having its own tag. That way you only release plaintext to the application after verifying its tag. (As usual there are some pitfalls with designing such a construction). Such a construction works with any ...

2

The usefulness of online AE (locally): Assume you wrote a program that encrypt arbitrary files. Now further assume the user wants to view a movie, encrypted with this tool. The tool can now use the online-property to stream the movie in real-time as it uses online-encryption. The usefulness of online AE (programatically): Assume you want to process ...

2

FFX is not malleable. It's a strong tweakable pseudo-random permutation, where the "strong" here indicates that both encryption and decryption look like random permutations from the attacker's perspective. In particular, there's no relationship between the plaintexts of closely related ciphertexts (aside from the trivial observation that different ...

2

This [Carter-Wegman] MAC is not, in general, secure in the quantum setting This is true; however we need to ask "what is this setting, and is it a realistic one?" This setting is one where the adversary can ask queries that are composed of a superposition of quantum states, and the oracle returns the superposition of the answers. In other words, the ...

2

According to Wikipedia, GCM is defined for block ciphers with a block size of 128 bits. So no, you can't use GCM with 3DES or DES, because of the 64-bit block size. You could use something similar to GCM, but it wouldn't be GCM.

2

This does not meaningfully authenticate the ciphertext. Your encryption is the same as OFB, meaning no block depends on the previous plaintext; for instance, $$C_2=P_2\oplus E(P_1\oplus (P_1\oplus E(IV\oplus 0)))=P_2\oplus E(E(IV)).$$ That means confidentiality should be fine; however, it provides no authentication except of the length of the message.

2

No. Yes, by choosing an authenticated encryption scheme with a known $\:I\hspace{.03 in}V\hspace{.04 in}||\hspace{.04 in}C\hspace{.04 in}||\hspace{.04 in}tag\:$ and $k_{\hspace{.02 in}0}$ and $k_1$ such that decrypting $\:I\hspace{.03 in}V\hspace{.04 in}||\hspace{.04 in}C\hspace{.04 in}||\hspace{.04 in}tag\:$ with $k_{\hspace{.02 in}0}$ and $k_1$ yields ...

1

Consider what would happen if an attacker altered one of the ciphertext blocks, but kept the IV and all previous ciphertext blocks identical. i.e. Xor some difference $\Delta$ to ciphertext block $C_x$, so that the altered block $C''_x = C_x \oplus \Delta$. This will produce an altered corresponding Plaintext block, like so: P''_x = C''_x \oplus ...

1

First, some notes on your choices of primitives: AES-256: You don't need to use AES-256 unless the data you want to protect needs to remain confidential for more than 30 years SHA-256 for authentication. Don't use plain SHA-256. Either use HMAC-SHA-256 using an encrypt-then-authenticate approach or (even better!) use AES-GCM or AES-EAX as your mode of ...

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