# Tag Info

## Hot answers tagged mac

16

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

8

First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It ...

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

6

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional ...

5

My understanding of the term 'pepper' is that it more matches your definition 2, in that a pepper is an unknown salt, which makes it a cryptographic secret, but not a key. However, in use it is not as limited by either of your definitions: The pepper can be different (or random) for all users (like a salt). The pepper can be the same for all users (like a ...

5

The pseudocode has a serious issue: changing the value of nonce2 in an otherwise valid cryptogram is not detected, and results in invalid deciphered plaintext. That would be fixed by encrypt(password, string): nonce1 := generate_random_nonce() nonce2 := generate_random_nonce() key := derive_key(nonce1, password) encrypted := nonce2 || cipher(nonce2, ...

5

NMAC is really just an "education tool" on the way to HMAC and I don't think anyone intended it to be used. The two keys are needed since the first and second hashes have different purposes. The first hash on the message is just needed to get collision resistance, whereas the second hash is supposed to provide a pseudorandom function type property. As such, ...

4

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

4

I really like this question, and have two things to say. First note that CBC-MAC is no good since given the key it's easy to find a collision. Let $t$ be a tag for a message $m=m_1,m_2$ of length $\ell$ bits. Then, in CBC-MAC the input to AES first is $\ell$ and then the output is XORed with $m_1$ and input to AES, and so on. Let $t_1$ be the intermediate ...

4

In summary: Yes, HMAC is the way to go for construction of a MAC from an arbitrary concrete iterated hash. We have no constructive argument of security of the MAC constructs in the question; we even have a concrete attack when using some otherwise apparently fine hashes. I consider a hash constructed by iterating a compression function $F$ as ...

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

3

I'm going to agree with @fgrieu's marvelous post above in a back-handed way. My answer is: No, you don't have to use an HMAC. Do it anyway. As you noted, some hashes, sush as SHA-3 (especially in its Keccak form), Skein (which I was a team member on), and others will work just fine. In the case of Skein, there is a one-pass Skein-MAC that has a proof of ...

3

First, terms: A MAC is a generic term for a class of cryptographic primitives. It's in the same category as "hash" or "PRNG." HMAC is a particular construction that, combined with a suitable cryptographic hash, gives a secure MAC function (it can also be used to generically refer to any HMAC algorithm, since HMAC is secure with pretty much any standard hash, ...

3

A normal security notion for MAC's is that of unforgeability. So given some set of message,tag pairs $(m_0,t_0),\ldots,(m_k,t_k)$ is should be hard to create a tag for a new message not among the $\{m_0,\ldots,m_k\}$, stated informally. In your case, you could just use $E_k(m_0)$ with the secret MAC key $k$ ($H_0$ in your notation); no need for the extra ...

3

The MAC is NOT redundant. As alluded to by Paŭlo Ebermann's comment, the word authentication has a different meaning in the two scenarios you mentioned. In the key exchange phase of SSH, the purpose of authentication is to ensure to both parties that they are indeed talking to the right peer (if using mutual authentication). Typically, the server ...

3

One particularly interesting aspect of Poly1305 is that its security is guaranteed, assuming the underlying cipher is secure. In other words, Poly1305-AES is guaranteed to be secure, as long as AES has not been broken. In the event that AES is broken, AES could be replaced with another cipher, and get a similar security guarantee. DJB talks about his ...

3

$Tag = MAC_k(\Sigma_i m_i)$. Too many attacks to enumerate. As long as the sum over the blocks remains the same, the tag remains valid. If the sum is reduced modulo $2^{\mathrm{blocksize}}$ at the end, the attacker can choose the whole message, apart from a single block used to balance the sum. $t_i = MAC_k(m_i)$ and $Tag = (t_1, ..., t_l)$. ...

3

I would propose a rather different scheme. encrypt(password, string): nonce := generate_random_nonce() secret := pbkdf(nonce, password) mackey := kbkdf(secret, 'mackey') enckey := kbkdf(secret, 'enckey') iv := kbkdf(secret, 'iv') encrypted := cipher(iv, enckey, string) return (nonce || encrypted || mac(mackey, encrypted)) Note that I've ...

3

According to Handbook of Applied Cryptography (15.3.2, ii), ANSI X9.9 (which SEJPM mentioned in the comments but I have no access to) defined CFB-MAC only as a compatible alternative to CBC-MAC: The X9.9 MAC algorithm may be implemented using either the cipher-block chaining (CBC) or 64-bit cipher feedback (CFB-64) mode, initialized to produce the same ...

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

From the Catena paper, version 2. A salt refers to an additional random input value for the password scrambler, stored together with the password hash. It enables a password scrambler to derive lots of different password hashes from a single password like an initialization vector enables an encryption scheme to derive lots of different ciphertexts from a ...

2

The main functional difference is that anyone able to verify a Message Authentication Code is also able to forge one, because the same key is used for both tasks; whereas someone with the public key can verify a digital signature, but can't forge one. Contrary to a MAC, digital signature is thus usable in contexts where the verifier is not trusted, which is ...

2

That's a lot of questions, I'll try and answer in order. A hash or message digest alone is not secure because anybody can calculate and thus substitute a hash value. If you (correctly) add a key to the mix then you get a HMAC, which can be used. Nowadays often a HMAC is used, or an authenticated mode of authentication such as GCM, CCM (for packet ...

2

First, don't roll your own crypto. Second, why would you want to use CBC-MAC, if you have GMAC (GCM-mode) and CMAC and even better HMAC? (all of which are better than CBC-MAC) Third, don't try to fix problems that have been fixed. (see second) Fourth, I'm not aware of this construction being standardized and I'd doubt it has been. (see points 1 to 3) ...

2

What would go wrong if I skipped the encryption step? It's be easy for someone getting some message/UHASH pairs get enough information about the key to produce further message/UHASH pairs himself. If he receives enough pairs (and it wouldn't take that much), he can fully recover the entire key (and then generate a UHASH for any message of his ...

2

You scheme, let's call it pad-MAC-encrypt, would indeed fix any padding oracle attacks against MAC-pad-encrypt. The reason it isn't used is probably that padding oracle attacks weren't known when CBC schemes were initially defined and now that they are known, there doesn't seem to be a convincing use case for CBC. Other modes have advantages over CBC anyway ...

2

A lot has changed recently in this area. Now the only ciphersuites Chrome considers non-obsolete (those that use AES-GCM or ChaCha+Poly1305), do use Carter-Wegman MACs. So, I would say that there is no disadvantage and that any low popularity has been just an artifact of historical decisions in standardization. Secure hashes were the first to be openly ...

2

It is not secure in general, but not insecure in general either. For example, you can get a MAC algorithm for which it would be secure by concatenating constant data to a secure MAC. $Tag_k(m) = M_k(m)||0^n$ is a secure MAC if $M$ is. And clearly taking the first half of that is a secure MAC if $n = |M_k(m)|$. On the other hand, reverse the order of the ...

1

HKDF stage 1 is useful for when the SKM value is derived using some deterministic method, such as a key exchange, or from a source that may not be fully trusted. SKM may be substantially larger than the keys you want, but may have the entropy not evenly distributed. Stage 1 compacts and distributes the entropy into a key that is correctly sized for the hash ...

1

Security The level of security is likely to depend on the cryptographic primitives - the actual hash function and cipher - used. It is very likely that you can construct a function that is insecure, e.g. where the cipher is used for both the hash function an encryption. So you need to prove that the hash function and the encryption primitive are not ...

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