# Tag Info

96

I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here: Encrypt-then-MAC: Provides integrity of Ciphertext. Assuming the MAC shared secret has ...

55

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

18

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

17

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

17

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

13

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

12

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

12

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

11

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(.)$ is an iterated and keyed compression function enjoying some good security ...

11

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

9

Using EAX with a 64-bit block cipher is problematic, because the short block size causes some weaknesses due to internal collisions. I do not recommend it. Use a 128-bit block cipher. Indeed, the world has moved away from 3DES and towards AES exactly because of these fundamental problems with a 64-bit block size: the internal collision effect means that, ...

8

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

8

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

7

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

7

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

7

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

7

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

7

The article mentions that 3-DES was used to encrypt these passwords in ECB mode. DES has a 64-bit/8-byte block. So let's say you use ECB to encrypt a nine byte password. The first 8-bytes are encrypted using ECB. So far so good. But what happens when we come to the ninth byte? Well we're now in a new block but only the first byte is populated with any ...

7

The GQ identification scheme is essentially a zero-knowledge proof of a value $x$ such that $x^\mu \equiv J \pmod N$ where $N$ is an RSA modulus and $(\mu,N)$ are system parameters and $J$ is known to the verifier and $x$ only known to the prover. Now your question is not directly concerned with the aforementioned proof where a user shows the possession of ...

7

Thought I'd begin with some references for you that might be of interest. These terms are used as key 'selling points' for a number of schemes, including many of the CAESAR submissions. Some examples using the terms specifically are given below - most of which are from CAESER because I have the zoo in-front of me: "Online": OCB, Ascon, CBA, APE, NORX ...

7

If the data to protect has no built-in redundancy at all (for example, has each of its bit determined by fair coin toss), there is no way to protect integrity without expansion (Proof sketch: there are as many distinct possibilities for valid plaintext as there as possibilities for valid enciphered-and-protected data, hence every possible ...

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

6

If you go through the math, it appears that exactly the expected amount of ciphertext expansion is happening. Here's what's happening: The GCM takes the plaintext as a byte string of size N, and generates a ciphertext which is a byte string of size N+28, where 12 of the 28 is the nonce, and the other 16 is the authentication tag. Then, that octet string ...

6

Well, no, it is not safe to use a GCM authentication tag as a hash. If you know the key, it is straight-forward to find preimages; that is, find a message that hashes to a specific target value. Note that you asked for second preimage resistance; not only does it fail to provide that, it fails to provide the weaker preimage resistance. CCM and OCB have ...

6

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

6

Don't believe every claim ever made in any paper ever written, particularly when the paper provides little or no justification for the claim; not everything you read reflects the cryptographic consensus. This is particularly true for a paper written in 2002, which is a time our understanding of authenticated encryption and security engineering was still in ...

6

A is acting as a square-root oracle in that protocol. We can use that oracle to factor $n$ and break the scheme. Suppose you are an attacker that wants to impersonate A. You: Pick a random $m$; Send $m^2$ to A; Compute $p = \gcd(m_1 - m, n)$, thus factoring $n$. This works with probability $1/2$ for each attempt.

5

First, convert the string which is to be encrypted into a sequence of bytes. UTF-8 is easy enough; you may reduce the size a bit, depending on what you know on the input strings (e.g. if the strings are domain names, they are ASCII-compatible, so you need only 7 bits per character -- actually a bit less). For the rest of this post, we need to assume that the ...

5

I don't have my Real 802.11 Security book present, so my answer is based only on what I could glean from the CCMP and CCM page on Wikipedia. As stated there, CCM is only a mode of operation providing authenticated encryption (using CTR-mode for encryption and CBC-MAC for authentication), whereas CCMP is a protocol which utilizes the CCM-mode of operation. ...

5

The idea that cryptography alone can provide non-repudiation is a myth. I realize it is one that is taught in many crypto textbooks -- but the textbooks are wrong. See, e.g., my answer here and here. I could suggest some constructions (e.g., sign the message, append the signature to the message, then encrypt it using an authenticated encryption mode of ...

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