Hot answers tagged

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


15

No. A MAC guarantees unforgeability but not pseudorandomness. It is true that all MACs that I can think of right now are essential pseudorandom functions, but this does not mean that the MAC definition implies this. Indeed, it clearly does not. So, conceptually, you need a pseudorandom function. You can assume that HMAC is a pseudorandom function. It is ...


14

If this requires a single answer among 1/2/3/4 (rather than none), I would select 3, by the following reasoning: Digital Signature provides confidentiality while message authentication code can not We can summarily exclude this, since since Digital Signature simply do not provide confidentiality. Digital Signatures works faster than ...


13

The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.


11

While the one time pad seems obvious, I am not sure about Carter-Wegman-Style message auth. What they are talking about is a Carter-Wegman authentication method that uses a stream of random bits as a part of the process (just like a one time pad uses a stream of random bits to encrypt). Normally, when we implement CW, we use some almost universal (au) ...


10

There are many advantages of MAC's over signatures. For signatures you need to use asymmetric key pairs. Public keys need to be trusted for this to work. Unfortunately establishing trust is not that easy. Furthermore you don't want to use a private key stored on, for instance, a smart card (which would require a PIN and would likely be too slow). Instead ...


8

Can anyone explain why CBC-MAC is not secure for variable length message? For the previous question I'll quote Matthew Green's post from 2013: A quick reminder. CBC-MAC is very similar to the classic CBC mode for encryption, with a few major differences. First, the Initialization Vector (IV) is a fixed value, usually zero. Second, CBC-MAC only ...


7

MACs have some advantages over digital signatures The component of the computational cost that is independent of message size is much higher for digital signatures, to the point of being an obstacle and requiring milliseconds or/and dedicated hardware. We know no signature scheme where both signature and verification of short messages are of speed any ...


6

A simplified* Carter-Wegman MAC could be defined as: $$ t=\sum_{i=1}^n {k_1^i m_i} + k_2 \pmod p$$ $p$ is a sufficently large prime (e.g. 256 bits). You must choose a new truly random $k_2$ uniformly from $0\leq k_2 <p$. It acts as a one-time-pad that prevents an attacker who sees the tag $t$ from learning anything about $k_1$. The polynomial $\sum {...


5

It is widely known, generally, that a MAC is a HASH with key. Nope; there are plenty of perfectly good MACs that, if you know the key, aren't very good hashes at all. Examples of this would include CMAC and GMAC; in both cases, if you know the key, it's easy to generate an image that MACs to a specific value. However, lets assume that you're talking ...


4

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


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

First lets be precise on some definitions : Integrity = only the authorized users can modify the information. Confidentiality = only the authorized users can access the information. Here the information is in plain view. Authentication = Proof of the identity of the content/sender (sort of proof of identity), be sure to not mistake it with identification. ...


4

Triple DES is a block cipher. (Specifically, it's a variant of the old DES block cipher with better security, but several times lower performance.) You can use it to encrypt small blocks of data (64 bits = 8 bytes, for Triple DES), but what it's really useful for is as a building block for other cryptographic schemes, such as stream encryption or message ...


4

No, it is not necessarily secure. Here is a simplified example of why not. Assume one block zero messages are encrypted without padding. The ciphertext is $I||E(I \oplus 0)$. The MAC value is thus $E(E(I) \oplus E(I)) = E(0)$. So regardless of the IV, the MAC is the same for all such messages. So if you encrypt several zero messages you can leak that fact ...


4

One of the main differences is that Message Authentication Codes don't prove authorship of the message. Imagine the situation, when Bob sent a signed contract to Alice. In case of digital signature Alice can go to court claiming that Bob has signed the contract. A judge can verify the signature and make sure that the contract was really signed by Bob as only ...


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

You can use methods for hiding the output of the polynomial hash that don't require nonces, such as encrypting with a block-cipher of matching block-size or hashing it with a keyed hash (PRF). Not using a nonce reduces the security bounds (security decreases as the attacker sees more messages using the same key), makes it incompatible with stream ciphers ...


4

We want to forge the tag for $m = m_1 \oplus m_2$. The tag we need to produce is: $$\operatorname{Mac}_k(m_1||m_2)=⟨F_k(m_1), F_k(m_1 \oplus \overline{m_2})⟩$$ We'll query the oracle with the message $m_1^\prime || m_2^\prime$, which needs to be different from $m_1||m_2$ to count as forgery. Consider $m_1^\prime || m_2^\prime = (m_1 \oplus \overline{m_2}) |...


4

Yes, (asymmetric) encrypt-then-sign would provide the same properties as (symmetric) encrypt-then-mac. It would provide integrity and authenticity of the ciphertext. It is however possible for another person to re-sign the encrypted message if encrypt-then-sign is used. This is a problem when other parties are trusted within the same network. Note as well ...


4

Should be comparable in strength to $H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is $\min(2^{n_O},2^{{n_I}/2})$ where $n_O$ is the output size of the outer hash and $n_I$ the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ...


4

Although your scheme is secure - especially with a random key of 32 bytes or higher - it won't offer any benefit over HMAC. It's therefore not recommended to use such a scheme. Also note that `bcrypt has been designed for key stretching which is deliberately not efficient. You have ample entropy in your key so there is no need for key stretching.


4

Is this hash almost-XOR-universal? No. Consider the two 1 block messages $M = \{0\}$ and $M' = \{2^{n-1}\}$. We have: $$H(M) = ((2\cdot 0 + 1)(2K+1) \bmod 2^{n+1}) /2 = K$$ and $$H(M') = ((2\cdot 2^{n-1} + 1)(2K+1) \bmod 2^{n+1})/ 2 = K + 2^{n-1} \bmod 2^n$$ As $H(M) \oplus H(M') = 2^{n-1}$ has a nontrivial probability of being true, $H$ is not ...


4

I think the attack by Preneel and van Oorschot (MDx-MAC and Building Fast MACs from Hash Functions, CRYPTO'95) in Proposition 4 applies. It was cited by PulpSpy in reply to my question about H(pass||length(data)||data). With fixed-length data, that amounts to a known suffix for the key. Proposition 4 states in a nutshell that for a generic construction ...


4

Can someone quote a protocol, application, etc, where the disadvantages of the MAC relative to digital signatures can be ignored? Your particular attack is of no interest if B has nothing to gain to claim that it got message M from A. As for concrete examples: the TLS record format, IPsec, SSH, the IES public key system; actually, any protocol that ...


3

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC. It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it ...


3

This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it ...


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


3

At least in the case of NaCl, Poly1305's "sudden death" properties aren't much worse than XSalsa20's. With any stream cipher, if you reuse the same stream with two messages, then the XOR of the ciphertexts gives you the XOR of the plaintexts. So your security is already ruined by nonce reuse, whether or not you rely on Poly1305.


3

There is work underway to specify KMAC. It's basically just SHA-3, but with a length specification for the key and a special value to indicate that this is KMAC instead of hashing. These constructions are required to make sure that there are no unfortunate collisions with previously hashed data or - more importantly - key / message pairs where $H(K_1,M_1) = ...



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