New answers tagged

1

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


0

Basically any PRF can be made to generate a key stream in counter mode. So if HMAC is the only thing you have then it can be used to encrypt messages. Simply said: you hash a counter and use the output as key stream, which is XOR'ed with the plaintext to get the ciphertext. HMAC and hashes are often used to create Deterministic Random Bit Generators, which ...


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.


1

This would normally be equivalent to a peppered hash. The attacker should be assumed to know the pepper. It's generally bad practice to assume a salt or pepper will remain secret, and as such, this is not secure practice, since the attack becomes equivalent to normal hash breaking. The information you're hashing doesn't have enough entropy to resist such an ...


0

Only for a trivial key. You have HMAC(<key>, <secret₁>) = <hash>. The attacker knows <hash> and certain <secret>. Having a small search space, different <secret> values might be bruteforced. However, with a proper (long, random) <key> the attacker won't be able to recover the other values. The HMAC-SHA256 itself is ...


Top 50 recent answers are included