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


14

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


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.


6

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


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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

The strength here depends on the collision resistance of $H$. If $H$ is not collision resistant, like MD5, then the attacker can find $H(m) = H(m')$, ask for the MAC of one message and forge it for the other. So for many secure hashes you lose half the security bits. E.g. SHA-256 should give you a 256-bit secure HMAC, but would be at most 128-bit secure in ...


3

Yes. A secure PRF is a secure MAC. A secure MAC of a secure MAC is a secure MAC. Therefore, applying a PRF to a MAC still gives you a MAC. Depending on the length of the inner MAC and the PRF you may lose security bits, but if they are long enough it works.


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

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

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



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