Hot answers tagged

5

HMAC does not provide an obvious security improvement over the KMAC construction, which is optimal for Keccak based functions. HMAC is designed to create a secret initialization vector or IV for Merkle-Damgård type hash functions, KMAC does the same for sponge based hash functions but much more efficiently. HMAC also needs to deal with the length extension ...


4

Should be comparable in strength to $H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is $\min(2^{n_O},2^{{n_I}/2})$ where $n_O$ is the output size of the outer hash and $n_I$ the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ...


4

Short answer: 32 bytes of full-entropy key is enough. Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger ...


3

The strength here depends on the collision resistance of $H$. If $H$ is not collision resistant, like MD5, then the attacker can find $H(m) = H(m')$, ask for the MAC of one message and forge it for the other. So for many secure hashes you lose half the security bits. E.g. SHA-256 should give you a 256-bit secure HMAC, but would be at most 128-bit secure in ...


3

"Given the above assumptions and limitations, is the encryption scheme still secure?" No; the attacker can remove blocks of [IV + rest_of_ciphertext] from either end to remove corresponding plaintext blocks without affecting any other part of what it decrypts to change the IV to change the initial plaintext block in the same way as for the OTP, without ...


3

It depends on the protocol. In general IND-CPA secure ciphers are assumed. That would mean that confidentiality is taken care of by the cipher. If integrity and/or authenticity are also required then it should be made explicit in the protocol. In that case it is however perfectly possible to use one key, e.g. by using an authenticated cipher such as GCM. ...


2

HMAC is a message authentication code (MAC). MACs produce "tags" that can can be used to prevent a message from being tampered with (sort of like a digital signature). There's no way to "decrypt" an HMAC tag to get back the original message, so it sounds like HMAC is not what you're looking for. I would suggest using AES-GCM instead, since it's designed to ...


1

I am using 32 character long random alphanumeric strings as the cryptographic keys First, I would suggest generating the keys differently. Cryptographic keys are not like passwords. There are specific requirements for the format of a cryptographic key, which depends on the algorithm. In the case of AES, HMAC, and most other symmetric algorithms, the ...


1

Hashes and therefore HMAC do not take alphanumeric characters as input. You'd first have to convert the textual "key" into bits. I've put "key" in quotes because keys for HMAC should consist of bits in the first place. The recommendation for HMAC is (indeed) that the key size is identical to the output size (and the intermediate state for Merkle–Damgård ...


1

as far as I know, MAC's can vary depending on implementation and/or situation, like in SSL certs. So standartizing a MAC hardly can mess things up, so that's why they're not included


1

You're essentially asking if SHA-3 can use a keyed hash instead of an HMAC. The short answer is yes. But there's more to it than that. In the SHA-3 competition, two of the finalists (Keccak and Skein) were specifically designed to have a one-pass MAC as part of their design, and that's what the answer above is giving about Keccak. KMAC is Keccak's ...



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