# Tag Info

9

This is a problem created by the library. Either the HMAC algorithm is skipped entirely, or - more likely - the HMAC authentication tag is generated and then forgotten. The reason is likely the spotty to non-existent handing of authenticated ciphers in the OpenSSL command line and (likely) higher-level functions. The string is recognized by the cipher ...

6

Is there an efficient way to do this? 32 bytes of "good randomness" provided by hashing some secret value gives much less entropy than required to directly compute a sample of 100 items from a list of 100000. If this is required for any cryptographic purpose, you must use a good CSPRNG to convert your starting entropy into as much randomness as ...

6

Yes, there is an important one; The Non-Reputation; Non-repudiation refers to a situation where a statement's author cannot successfully dispute its authorship or the validity of an associated contract The HMAC key is a symmetric key therefore there is no non-repudiation. Both sides can not claim that the other side sends them the message $m$. I.e. They ...

6

In 2006, Mihir Bellare, in their article New Proofs for NMAC and HMAC: Security without Collision-Resistance proved that if the compression function is a PRF then HMAC is a PRF ( this is a short story, see below). As a result, HMAC like HMAC-MD5 does not suffer the weaknesses of MD5. However, still prefer HMAC-SHA256 or KMAC of the SHA-3 series. Keep ...

5

For basic AES, it is easy to find two keys in this way. Take any $key1$ and $plaintext1$ and compute $c=AES_{key1}(plaintext1)$. Then, take any $key2$ and compute $plaintext2 = AES^{-1}_{key2}(c)$. It follows that $AES_{key1}(plaintext1) = AES_{key2}(plaintext2)$. Having said this, if AES is used in an authenticated encryption mode with a MAC, this may not ...

5

Well, supposing everything is properly domain separated, nonces are always generated randomly for encryption queries, and your KDF behaves like a perfectly random function, the first step is to bound the probability of a nonce repeat. A birthday bound tells us that this happens with probability at most $$q^2/2^{256}\,,$$ where $q$ is the number of ...

5

The point (( also see this answer)) is that the hash calculation is free for everybody and we assume that your methodology is known by Kerckhoffs's principles. Anybody can calculate the hash of any information and this may leak the encrypted message. In Cryptography, we consider the attackers computationally bounded, but not restricted to adapt any method on ...

4

You are describing encrypt-then-MAC using AES-CTR for encryption and HMAC for the MAC. This indeed results in authenticated encryption. There may be better choices for the key derivation function, but I'm not very familiar with the options, so I'll let others comment. I don't understand why you salt the KDF when deriving the key. This just means that you ...

4

The answer given by @kelalaka is 100% correct; this breaks the security of encryption and so shouldn't be used. However, I want to add that this doesn't even guarantee integrity. In particular, integrity should hold even if the attacker knows the message. Assume that the attacker knows $m$ and wishes to change the first bit. This change can be easily made (...

3

If the MAC is theoretically secure, but its implementation has a side channel (like by Differential Power Analysis, maybe even timing) leaking information about the MACed message (but not the key), and the encryption is secure including it's implementation, then neither MtE nor MtEtM are safe (because the side channel leaks about the message), but EtM is ...

3

"brute force a PBKDF2-HMAC-SHA1" is not about collisions (at least, if a single hash is targeted, or if there's salt at the input of the password hash). It's a preimage attack. The hash output by SHA-1 is 160-bit. That's 20 bytes (not characters; these are different notions, and why we have character encodings). It can take $2^{160}$ values. The ...

3

Indeed FIPS 140-2 requires a module to validate itself, and this has no security benefit. In order for a code integrity check to have a security benefit, both the code that performs the verification and the data that it uses (hash value for a hash, MAC value and secret key for a MAC, public key for a signature) need to be integrity-protected (and with a MAC, ...

3

If your secret material (you call this my secret so I'll use that name) is chosen with sufficient min-entropy, then yes this scheme is acceptable. my secret, however, must be in itself sufficiently hard to guess; it becomes effectively a password cracking problem. As such, I would suggest my secret be a randomly generated keyfile, or at least a really secure ...

3

No, it is not providing confidentiality as it is not encrypting your message but fingerprinting it. It provides authentication and integrity because only the creator (or the one who knows the secret) can check the fingerprint for validity. Though the creator doesn't know which of the two qualities is compromised if the validation fails.

3

What's keeping a running transcript hash value ? It means keeping the internal state of the hash in-between processing pieces of the message hashed. Virtually all hashes are designed to make this easy, for the benefit of devices with limited RAM. They can hash large messages piece by piece, with a three-function interface Start/Hash/Finalize allowing to ...

2

Is it secure to use the same shared symmetric key, used for encryption with the arbitrary generation of a new nonce per message, for unlinkable contact signaling? Yes, as long as adversaries do not manage to get hold on the key. That condition implies None of the multiple holders of the key in the proposed system are adversaries. Each is competent at ...

2

Recall the definition: a cipher is AE-secure iff it is secure against chosen ciphertext attacks and has ciphertext ingegrity. Try going through the attack games with $(E_1,D_1)$ and $(E_2,D_2)$: if the adversary succeeds, can he succeed for $(E,D)$? It's fairly easy to see that $(E_1,D_1)$ and $(E_2,D_2)$ are CPA-secure. If the adversary can distinguish ...

2

I read one answer to a similar question that put forth that a hash function is distinct from a PRF, however I've also found materials purporting that cryptographic hash functions are PRFs, and I'm not sure now. Those latter materials are wrong. Random function A mathematical function (i.e. a "pure" function) whose output values depend only on its inputs, ...

2

You can just use a hash tree with a pre-configured node size then only the last hash value would be vulnerable to a length extension attack. In that sense this is not that different from performing a HMAC over a single hash. However, that's kind of besides the point. A length extension attack is only applicable for keyed hashes. As the hashes are not keyed ...

2

No, it is not useful to change the key between invocations of HMAC. That would not change the expected probability of collision, which remains about $n(n-1)/2^{257}$ for $n$ values under a model of HMAC-SHA-256 as a PRF. For $n=2^{40}$ (over a million million, the UK bilion), that's less than $2^{-177}$, the probability of 177 consecutive tails with a fair ...

2

It's indeed a genuine concern. How to fight this? Well, once client had provided the SHA256 hash of the file (to quickly index the file on the server), your server then provide a random one-time key and ask the client to hash the file again with HMAC and the key. Since the key is one-time and random, adversaries have little chance at guessing the key and ...

2

Be reassured: both $\text{HMAC}(k,m)$ [instantiated with a strong hash function, e.g. SHA-512; even SHA-256 would do] and $\text{AES}(k,m)$ [understood as direct encryption of 128-bit $m$ with the block cipher] are believed to be computationally secure Message Authentication Codes for the foreseeable future when the key is 256-bit, irrespective of how many ...

2

Even collision resistance is not sufficient to make HMAC unforgeable, so neither is second-preimage resistance. Let $H : \{0,1\}^* \to \{0,1\}^n$ be a collision resistant hash function. We define the hash function $H' : \{0,1\}^* \to \{0,1\}^{n+1}$ as $$H'(m\Vert b) = H(m)\Vert b,$$ where $|b|=1$. Since for any $m_0\Vert b_0$ and $m_1\Vert b_1$, it holds ...

2

I'd confidently go for "first N bytes". It's quite universally recognized that the output of practical cryptographic hashes are bitstrings or bytestrings; where a bytestring starts is subject to little ambiguity; and how to count starting from that is unambiguous. That's not to say that an error is impossible. In particular, the MD5 output is 128 ...

2

In general, we always assume that the mode of operation is known ahead of time. In practice, this should be bound to the key - if the key is only used for a single mode of operation then the above shouldn't happen. However, if the same key is used for multiple modes of operation, then the mode ID should be made part of the ciphertext and therefore included ...

2

TLDR: (2) is a sufficient condition, but probably not a necessary condition. Most people would probably believe that HMAC-SHA-1 is indeed a PRF, although SHA-1 is not WCR. The 2006 paper by Bellare claims to prove that e.g. HMAC-SHA-1 is a PRF, if the inner compression function of SHA-1 is a PRF. No known attacks break the pseudorandomness of the inner ...

2

Linux uses "sha512crypt", which isn't memory-hard but is fine given a moderately strong input passphrase. HMAC-SHA256 isn't a password-hashing algorithm. It's not even a hash function. It requires a uniformly-random secret key which it uses on a message to produce a Message Authentication Code (tag) of that message under that key. The password-...

2

The difference seems to be that cmacs are using a symmetric encryption additional to the hash-function while hmacs process the key within the hash-function itself. Is that correct? There is no "normal" collision-resistant hash involved with CMAC. See below for details. For HMAC, the internals of the hash function are exploited to process the key, ...

2

I had emailed Dr Thomas Pornin the very same question and received his reply. With his permission I cross post his answer as followed From: "Thomas Pornin" ... Date: 2021/04/22 11:38 Q1: Additional data k' is concatenated after bits2octets(H(m)) in HMAC input in step d. May we also need to concatenate k' after bits2octets(H(m)) in HMAC input in ...

1

Lastly, a 32-byte HMAC value of the ciphertext is created using the HMAC key and SHA-256 and written as the last two blocks of the ciphertext (32 bytes). You really should include the IV in the calculation. Otherwise the authentication tag validates, and with a wrong IV it will still result in invalid plaintext. This is less of an issue with the salt, as a ...

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