# Tag Info

128

@Ninefingers answers the question quite well; I just want to add a few details. Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ...

50

Hugo Krawczyk has a paper titled The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?). It identifies 3 types of combining authentication (MAC) with encryption: Encrypt then Authenticate (EtA) used in IPsec; Authenticate then Encrypt (AtE) used in SSL; Encrypt and Authenticate (E&A) used in SSH. It proves ...

43

Before answering your questions: GCM is an authentication encryption mode of operation, it is composed by two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...

41

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

35

AES-GCM has the following problems: In the case of nonce reuse both integrity and confidentiality properties are violated. If the same nonce is used twice, an adversary can create forged ciphertexts easily. When short tags are used, it is rather easy to produce message forgeries. For instance, if the tag is 32 bits, then after $2^{16}$ forgery attempts and $... 30 In comparison against CBC mode and HMAC, GCM mode is quite commonly better alternative. But, I'll go to detail where it neccessarily is not. Just like Richie Frame, I also do not agree that CBC + HMAC is always the best comparison target. I've added few other details. Hope you find them useful. Against CBC and HMAC I'll discuss downsides first. The ... 28 This is something I tend to disagree somewhat with Colin Percival on. You should use Encrypt-then-HMAC if and only if you can get it right. The biggest pitfall is using a short-circuiting string comparison versus a constant-time string comparison. Given the former, people can use timing attacks to forge valid HMACs for arbitrary ciphertexts. With an ... 28 Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key ... 27 The crucial difference between plain encryption and authenticated encryption (AE) is that AE additionally provides authenticity, while plain encryption provides only confidentiality. Let's investigate in detail these two notions. In the further text, we assume$K$to be a secret key, which is known to authorized parties, but unknown to attackers. Goals ... 26 Those "magic numbers" are related to the security proof behind the HMAC construction. In their Crypto'96 paper, Bellare, Canetti and Krawczyk first prove that$\mathrm{NMAC}_{(k_1, k_2)}(x) = F_{k_2}(F_{k_1}(x))$forms a secure MAC ("message authentication code") provided$F_k(\cdot)$is an iterated and keyed compression function enjoying some good ... 22 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 ... 21 Generate a file of cryptographically strong random data at least as long as the message to be sent. This will allow communicating the secret using the random data as a one-time-pad. I.e., produce the ciphertext by using a bit-by-bit combining function such as XOR. Purchase a plane ticket for an international flight connecting through Sheremetyevo airport. ... 20 The paper you cite (Deterministic Authenticated-Encryption...) gives quite a bit of useful information (but I'm assuming you already knew that). It looks like a pretty good read (I'll let you know if that assumption holds after I finish it). For why simpler constructions (CBC/CTR with a MAC or even AEX mode) don't satisfy (emphasis added): A key-wrap ... 17 Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ... 17 Would it not be easier simply to send$E(m||s,k)\$ where s is a salt shared across the system? Yes, that would be simpler; however, that would not (in general) be secure. The assumption you are making is that if someone modifies the ciphertext in any way, then the last few bits of the resulting plaintext must also be modified. This is often not the case: ...

16

If you look closely at the definition of authenticated encryption modes, you will see they all are, actually, the combination of symmetric encryption and a MAC. Using traditional encryption and an independent MAC has a few tricky points, none of them being unsolvable: The encryption mode will use a key, and the MAC will also use a key; using the same key ...

15

Because OCB is patented. And there are other good solutions for authenticated encryption that aren't patented. This makes them more suitable, in most situations. I can recommend, e.g., EAX, GCM, or CWC. EAX and GCM have been used in some standards, and AES-GCM has been standardized. For pointers where you can learn more, read Wikipedia. And try using ...

14

The original security proof of HMAC, as well as a new one not requiring collision-resistance of hash, are for the construction hash(o_key_pad ∥ hash(i_key_pad ∥ message)) with o_key_pad different from i_key_pad (and both filling a block). That's the rationale for at least one of the constant. The other plays no role, it just must be different from the first. ...

13

I think Encrypt-then-MAC does not deliver Plaintext integrity, but only ciphertext integrity. If the MAC over the ciphertext is OK but then we use the wrong key to decrypt (for whatever reason), then the recipient receives a plaintext that the sender did not send and did not vouch for. If this can happen, this is a violation of plaintext integrity. So, ...

13

I've been suggested to digitally sign it, thus, I have my private key, and I ship my application with a public key, and the application then uses the public key to check the QR code As long as you can live with the requirements for RSA (signature size, computation), that sounds like an excellent idea. Am I encrypting the whole message using the private ...

12

As D.W. mentioned, the patent on OCB really is a killer; who would want to go through the legal hassle and expense of licensing OCB, when there are free authenticated encrypted modes available. Another, considerably more minor issue, is that OCB does not support 'Additional Authenticated Data'. This is data that both the encryptor and decryptor provide to ...

12

The rationale goes this way: On a "big" system like a PC or a smartphone, ChaCha20+Poly1305 or AES/GCM are very efficient; the latter is fast because the hardware provides dedicated opcodes that implement both AES itself (aesenc, aesenclast on x86 CPU) and the GHASH part of GCM, which is used for the integrity check (pclmulqdq opcode on x86 CPU). On much ...

11

I'd use HKDF's "expand" step to generate multiple keys from one masterkey. Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2. //Extract MasterKey = PBKDF2(salt, password, iterations) //Expand AES-Key = HMAC(MasterKey, "AES-Key" | 0x01) MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01) (where | ...

11

First up, I think your question is less something for crypto.SE and would fit better in the security.SE corner. Nevertheless, here goes: ...except his name or identity... That's in itself already describes your problems when it comes to security and cryptography. Problem due to lack of verification options. Currently, world news outlets (example: ...

11

The GCM authentication tag doesn't need to be encrypted. Just attach it to the ciphertext in the clear. A very quick intuitive justification: It's an authentication tag derived from the ciphertext, it doesn't contain any sensitive information itself. The security of the GCM model assumes the tag is left in the open. (The GCM spec, SP 800-38D, shows the ...

11

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

10

Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it ...

10

An OCB like mode seems impossible with stream-ciphers. It's coupled tightly to the concept of a keyed permutation i.e. a (tweakable) block-cipher. Many authenticated encryption actually combine two distinct primitives. It's just that the specification and API only expose the combination. Essentially these xor a key-stream into the message to encrypt it (i....

10

The first 32 bytes of XSalsa20 output are used as key for the one-time-mac Poly1305. Poly 1305 needs a new 32 byte key for each message, using part of the key-stream is a natural way to obtain those. Requiring those empty bytes makes implementing the API easier. The implementer only needs to call XSalsa20 on the zero padded input buffer once, receiving both ...

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