Hot answers tagged

16

Alas, there is no simple satisfactory answer to this question. What I can offer is a very strong property that $m \mapsto H\bigl(k \mathbin\| H(k \mathbin\| m)\bigr)$ fails to achieve; a more pedestrian property which even HMAC may or may not achieve but is typically asked to achieve; a reason not to worry about it for any new systems; and some historical ...


6

Saarinen in his work GCM, GHASH and Weak Keys says that; This paper is not very clear and has led many people into regrettable confusion about universal hashing authenticators. The paper—both the manuscript you cited and the conference paper at FSE 2012—contains misleading claims and misattribution of ideas; describes attacks that apply only beyond the ...


6

HMAC-SHA-xxx has an output length of xxx bits That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration. HMAC-SHA-xxx-yyy has an output length of yyy bits Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing ...


6

If we view HMAC as a message authentication code or a PRF, this doesn't quite make sense: the security property for a MAC or a PRF assumes that the forger doesn't know the key, but you've given them the key $k$ in the signature. But you have the right intuition that there is something here. While a signature scheme in terms of $H(m)$ requires $H$ to be ...


6

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


4

But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible. Neither work. The IV might seem to work (as doing a brute force search over a space of size $2^{96}$ might appear to be daunting), however the attacker has another potential approach. If an ...


4

Yes, it helps to use HMAC instead of a hash in digital signature (with the HMAC key $k$ sent along the signature), but only when the signer chooses $k$ unpredictably when signing. The attacker can then no longer exploit a loss of collision resistance in the hash, because the attacker can't chose the message $m$ as a function of $k$, and that tends to make ...


4

What you are looking for is a randomized authenticated cipher of short bit strings, 64 bits long. You seem to be willing to accept between 64 and 256 bits of ciphertext expansion. With an $r$-bit randomization string, the probability of a collision after $n$ ciphertexts—which would, at the very least, reveal equality of masked ids—is at best bounded by ...


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

Consider the following system involving a message authentication code like HMAC-SHA256: Alice generates a key and shares it with Bob, and Bob alone. Alice authenticates a message with the key. Bob acts on the message only if it can be verified with the key. Of course, Alice can verify messages too, and Bob can forge messages too. Indeed, anyone who has ...


3

What is the convenience of universal hashes provides? They are simple to describe: $X_i=(X_{i-1}+D_i)\cdot H$, with $D_i$ being the $i$-th data word and $H$ being a key/iv-dependent secret and are really fast to evaluate in hardware and reasonably fast to evaluate in software. This is especially true if you consider the fact that hashes usually have 64 or ...


3

Adding to Yehuda Lindell's answer, there are two special cases that one should take care to avoid: If the HMAC key $k$ is longer than the block size of $H$, then it is compressed into $k' = H(k)$ and $k'$ is used instead with HMAC as usual. This means that there are easily constructed collisions in HMAC keys, namely $k' = H(k)$ and $k$ for any key $k$ that ...


3

If we assume that 1 and 2 are true then HMAC-SHA-512 is a better choice. For the time comparison, as stated Paul Uzsak, if there is no specific time relevant problem around ~50% faster shouldn't be considered. If more secure, then use it. For your comment; The shatter attack on SHA-1 requires a degree of freeness in the hashed data as in PDF's. This ...


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

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


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

Salsa20 has essentially no limits on its own for data volume: it can be used for up to $2^{64}$ messages of up to $2^{70}$ bytes apiece. You could use it in a nonstandard way for, say, more messages if they're each smaller, by carving up the input to the PRF differently, as long as the total volume of data is below $2^{134}$ bytes. You certainly can't ...


2

Let's look at the construction more abstractly. Let $F : \{0,1\}^n \times \{0,1\}^n \to \{0,1\}^n$ be a pseudorandom permutation and let $H : \{0,1\}^* \to \{0,1\}^n$ be a collision resistant hash function. If we look at the simpler construction $$\operatorname{MAC}(k,x) := F_k(H(m))$$ we can actually prove that this is a secure MAC (at least in theory). ...


2

Generally a digital signature is created using a private key and verified with the public key of an asymmetric key pair. Public keys can be easily distributed to verify the signatures. It is however required that the public key can be trusted to be part of the correct key pair; the public key needs to be trusted. For this a public key infrastructure or PKI ...


2

First of all, HMAC is not exactly a hash function. The Wikipedia clearly states that; In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. In ...


2

I see no way. Typed keys are typed to prevent them from being used for another task than being the key to the designated algorithm. What you maybe could do is use the key to derive another, and use it as an HMAC key. But I do not immediately see how we could avoid that the HMAC key could leak of the PKCS#11 device. Note: this comment sketches an option. But ...


2

As cheaper alternatives to HMAC with modest security goals, consider: SipHash—cheaper than MD5 because you don't have to pay for collision resistance; security is limited by the 64-bit output size Maybe a Gimli-based PRF—Gimli is a new compact design Derive a fresh key for each message, and use a one-time authenticator like a polynomial evaluation universal ...


2

the IVs of next blocks are going to be extracted from previous block ciphertext. Here assuming chunks since CBC requires IV only once per message/chunk. IV of CBC should be unpredictable, i.e random. It is not a good idea to extract from a known source. Use randomly generated per chunk. First option Enables chaining, you should also add the IV with the ...


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

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


1

Why does HMAC do that? The process of expanding or compressing the key material to exactly one block length this way shouldn't be necessary from a security perspective. The reason for this transformation is to enable an optimization when the same key will be used to process multiple messages. (See RFC 2104) If this optimization is used, it means that you ...


1

Found a stupidly simple solution: Create an index of md5(key). Alternatively, replace md5 with hash method of your choice.


1

HMAC-MD5 is not vulnerable to length-extension attacks, period. If that's what your code computes, then your code is not vulnerable to length-extension attacks. That said: Length-extension attacks are a part of the protocol, not an implementation of the protocol. It doesn't matter whether you use OpenSSL or something else to implement the same protocol. ...


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