# Tag Info

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

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

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

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

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

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

0

You can't. HMAC is one way. You will never get the plaintext back. Furthermore, if you do find a mathematical function to get your plaintext back from that output, you get a free PhD for publishing it.

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

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

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

Top 50 recent answers are included