Hot answers tagged

12

I don't think there is any official limitations when it comes from standardization bodies such as NIST. However, there do seem to be some papers such as New Generic Attacks Against Hash-based MACs. They show that HMAC may have less security than previously thought after the birthday bound. Generally, if you have a hash output size of, say 256 bits for SHA-...


7

We don't know. Although it seems unlikely to the extreme that there is some kind of mathematical equation that gets easier to solve when the second key relies on the first key, we probably cannot prove it. So that's it for the theoretical problems. One practical problem is that when the key for confidentiality is obtained by the adversary (e.g. through a ...


5

HMAC is a type of MAC. The output of a MAC is called a "tag". Not all MAC (algorithms) are HMAC. MACs are not required to be one-way or collision resistant for someone who knows the key. HMAC, however, inherits the one-way-ness and collision resistance of the underlying hash function. A CBC-based MAC is mentioned as a hint because it is almost trivial to ...


4

In many applications, especially in zero-knowledge proofs, we need commitment schemes that are additively homomorphic. Pedersen commitment schemes do have this property, hash-based commitment schemes don't. If we do Pedersen commitments on elliptic curves for performance reasons, where we fix two points $P$ and $Q$ on a curve, we can define: $\text{commit}(...


4

The usual lectures about the (in)securities of SHA-1 will be skipped. The standard defining SHA-1 is NIST FIPS 180 (recent revision(s)), it specifies how to pad a bit-string into a form suitable for processing in the compression function specified for SHA-1, which it also specifies. As of 2019, all current SHA-series hash functions are single-pass - that ...


3

The point is not to make the attack infeasible time-wise. Computational resources (usually, area*time, which is roughly a measure of the monetary cost) needed for the attack is the only thing you can hope to increase here. As you observed, it is always possible to parallelize brute-force search of passwords, so the best you can do is increase the ...


3

HMAC (and any other MAC) are totally different from Digital Signatures (RSA, DSA, ECDSA, EdDSA). MACs require a shared secret key that both the communicating parties have. The same secret is used to create the MAC as is used to verify it. Anyone with the shared secret key can create a MAC, and anyone with the shared secret key can verify a MAC. Digital ...


3

It would depend on the hash function if this is more or less secure. If the hash is broken and allows collisions then the scheme is decidedly less secure. For instance, if you'd use MD5 for the HMAC then you'd still be secure, as HMAC(k, m) doesn't rely on collision resistance of the underlying hash function. However HMAC(k, MD5(m)) certainly does rely on ...


3

TLDR: Such pre-hashing is weaker, and slower on a standard computer. Most serious security problem: in order to break the MAC with pre-hasing, it is enough to find two different messages with the same SHA-256 hash, and that's an offline attack (it requires a single query to a MAC oracle/device knowing the key). Such breaking of SHA-256's collision ...


3

So in my case is it safe to use PBKDF2 as hashing tool - to hash any thing like (timestamp+sensitive_info+extra_info) with a SECRET_KEY just similar to hmac? The reason that a Password Based Key Derivation Function or password hash is used is because passwords are generally not considered secure enough. The iterations or work factor of such a PBKDF makes it ...


2

The reasoning is wrong: the whole point of the paper is to establish a definition for secure general-purpose KDFs. In definition 7 of the paper, it is defined that a KDF is secure, if it can withstand distinguishing game from an adversary with capability to query the KDF oracle - that's what something linear like SWIFFT cannot provide. As for the quoted ...


2

The first scheme is similar to what's called Encrypt-and-MAC. It is not ideal, but it is not fatally broken, and it is still used by the SSH protocol securely. You need to include a counter or other unique value in the data being MACed to maintain IND-CPA security (i.e. identical plaintexts don't have identical MACs). The second scheme you present doesn't ...


2

No, you can use the same HMAC key for any message, including an already HMAC'ed message (regardless if the HMAC value is encrypted or not). The key in HMAC is protected by the one-way hash function used internally, so getting the key should be hard. The collision resistance and other security properties will also prevent an attacker from generating a HMAC ...


2

The salt of a password hash mitigates multi-target attacks like rainbow tables (and variants like the parallel rainbow table search machine), if you use a distinct salt for each user. Effectively, a distinct salt for each user means each user is using a slightly different hash function, so the advantage of any batch attack on many instances of the same hash ...


2

The tag is to best I can tell, a tag. It's not really a signature, it's not a hash, it's pretty close to a mac. Is tag in this case colloquially synonymous with anything else? It is not just close to a MAC—it is a MAC. Various synonyms: message authentication code / MAC MAC tag authenticator authenticator tag authentication tag Is it right to say ...


2

This is the mechanism of the rolling system of one of the best known crypto faucet website. I think that the previous answer above is a bit misleading. However, when the math is confusing, a simple test with some code and some pseudo-random generated data should not leave any doubt. Your statement: "..the way I see it, it is 50% less likely to hit the ...


2

First of all, even the entropy is 50-bit, it is not easy to list all possible string to execute an attack on the data set. Using hash function can hide the data itself due to pre-image resistance, however, the same data can have the same hash since the hash functions are deterministic. Therefore, it can reveal information, especially there is also side ...


2

Your quote is wrong: The wikipedia page for Length Extension Attacks says "Note that since HMAC doesn't use [Merkle–Damgård constructions], HMAC hashes are not prone to length extension attacks." The part that you've paraphrased in square brackets is a misreading of the original, which reads (my boldface): When a Merkle–Damgård based hash is misused ...


2

Is this protocol design secure? See below. What would be the advantage to use HMAC (or any other MAC) instead of AES encryption? HMAC was originally proposed as a construct that turns a Merkle-Damgaard hash function based on compression functions built from block ciphers, into a message authentication code. Although there's no decryption in HMAC, you ...


1

The collision resistance of this hash will be the collision resistance of $\operatorname{HMAC-SHA256}_{IV}(M)$. Beware of the fact that pre-hashing of the key is a thing with HMAC, so $$\operatorname{HMAC-SHA256}_{\text{ReallyLongIV}}(M)=\operatorname{HMAC-SHA256}_{\operatorname{SHA256}(\text{ReallyLongIV})}(M)$$ Do I still need to include file length in ...


1

Yes this is "OK". Please correct me if I'm wrong there. You are correct. It's effectively ratcheting the original key. However there may be a more elegant solution such as using static keys for auth and ephemeral keys for key agreement (i.e. use Ephemeral-Ephemeral Diffie-Hellman for each new message).


1

If I need to support AEAD sometimes, is it reasonable to just use AEAD all the time and skip HMAC entirely? Yes, and if you only need integrity / authenticity of the message then you can put all of the message in the Associated Data. HMAC should be faster, but how much? I’ll need to test this, but suspect the difference might not be huge. It won't be ...


1

The answer depends on how you define ‘convergent encryption’ and what threats you're hoping to defend against. Here are two broad options that you might mean: You're a storage service and you make lofty promises about encryption to your users, but you also do deduplication between unrelated parties. (Maybe you abuse the term ‘zero-knowledge’; it's trendy ...


1

If you look at $k' = \operatorname{HMAC}_k(m)$ as a key derivation function then you'd expect that $\operatorname{HMAC}_{k'}(mm')$ is secure, even if $m$ is also used to derive $k'$. So from a purely functional point of view then yes, this should be secure. Also from a functional view I would wonder why there is a repetition of $m$, because as it is used to ...


1

I think it must be: $$\Pr[forgery]=\sum_{n=0}^{m-1} \frac{1}{2^{128}-n} $$ This is not correct; this can be seen in the simple case where there are four possible keys and you get three guesses. By the above logic, the probability of guessing the correct key would be $1/4 + 1/3 + 1/2 = 13/12 > 1$, which is absurd (as probability are never greater than 1)...


1

[Suppose] the adversary can predict the key with probability $\alpha$. Can I say the adversary can forge a valid (message,tag) pair with probability $\alpha$? It's not quite $\alpha$. Write it out with the chain rule: \begin{align*} \Pr[\text{forgery}] &= \Pr[\text{forgery} \mathbin\& \text{guessed key}] + \Pr[\text{forgery} \mathbin\&...


1

No, with a reasonable choice of hash function, HMAC can safely authenticate many messages under the same key—it is not a one-time MAC like GHASH or Poly1305. Of course, it may be prudent to use a message sequence number so you can reject replays (and it may be necessary for your encryption scheme, e.g. if you're using AES-CTR or ChaCha). That said, why are ...


1

I want to know if the following would also be equally secure Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305. In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis ...


1

Your goal, if I have understood correctly, is to create an unforgeable bearer token which you will send to a user, and which the user can later present to you in order to gain access to a resource, say a file. An adversary should be unable to guess any tokens they weren't given outright, even if they are given many many tokens. You appear to be constrained ...


1

If you look at RFC 4122 then you can see which bits are not random. I think that are 128 bits in the UUID and 6 of them are non-random to indicate the scheme used. That leaves 122 bits of UUID, which is probably enough to consider them relatively random. Only if you generate many millions of them is there a chance of collision. However, there is a reason why ...


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