# Tag Info

7

They don't, and in fact the sponge construction used in Keccak (SHA-3) allows for variable length output. In other hashes the Merkle-Damgård construction was used which has a fixed output length due to the nature of its design. But there is no reason to not allow for variable output length other than ease of development or use.

5

The distinction is that ECDSA solves a problem that HMAC does not. If you need that problem solved, then you need to do ECDSA rather than HMAC; if you do not, then HMAC works just as well (and is a lot cheaper). With HMAC, here is what we have: we have an authenticator that has a secret key. It takes a message, and gives that (and the secret key) to the ...

3

To add to poncho's answer (since they beat me to it!), there are several advantages to choosing HMAC over ECDSA (or RSA) if you can get away with it: Insanely better performance: signing and verifying is much faster Much simpler implementation: this is important for security (even if you're not the one doing the implementation), since more complexity leads ...

3

One solution is to use the choice of which equivalent message you send as a way to encode a MAC value. Take a "base message", where e.g. each word choice is the alphabetically first one. (Or some other known rule.) Calculate the MAC for that: MAC(key, message). The MAC should be $m$ bits or less. HMAC, possibly truncated would work fine. Encode that MAC ...

3

I would just concatenate. Two 256-bit keys lead to a 512-bit key which is short enough for HMAC with common hash functions to use as is. XOR would allow the second party to easily choose a related key (and has worse behavior when neither key is perfectly random). Hashing and double HMAC use more resources without a clear benefit, unless you care about the ...

3

To me it seems like HMAC(salt, IKM) would be weaker against a brute force search of IKMs, as the digest of the salt can in this case be precalculated by an attacker (assuming the salt is a non-secret value or zero). Yes, it is slightly faster to brute force, but if the IKM does not have enough entropy to give brute force resistance, then a small factor ...

2

Q: Why do cryptographic hashes need to have a fixed length output? I know that the shallow answer is that an output that varies by key size or file size can leak information somehow, leading to cryptanalysis, but I would like some more intuition as to why this is the case. It depends on what you mean with that. If you mean that they need to have a ...

2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...

1

No, the nonce is not fit to be a HMAC key, because anybody can view the nonce in transit. If - on the other hand - the TLS connection does deliver enough security then you would not need the HMAC. It's fine to use the nonce as one time code, but you don't need the HMAC for that. If an attacker can obtain nonce's send to clients than the attacker can always ...

1

Most applications store their private keys for TLS in a cleartext file protected with filesystem permissions. On UNIX-ish systems this location is typically in /etc/ssl/private/mykey.key readable only by root. Windows-based systems store private keys in a special secured portion of the system registry database, which only the SYSTEM account (equivalent to ...

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