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

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


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


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.


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

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


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


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


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

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

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

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

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

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

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


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

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

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

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

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

I suspect the questioner is asking not about MAC's per say, but rather Authenticated Encryption (AE, and if there is additional data, AEAD). I've been wondering this myself, so I asked Phillip Rogaway of UC Davis, who is one of the creators of EAX - a "two pass" "online" operation mode for block ciphers that - since it provides AE (confidentiality and ...


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.


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

It is not collision-resistant because the tag is only 64 bits, so on average only $2^{32}$ inputs are needed to find a collision. This is the classic birthday bound. This is completely insecure, so SipHash is not collision resistant. This is not a problem for hash tables because hash tables have collision-resolution mechanisms and because the odds of a ...



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