Tag Info

Hot answers tagged

2

Well, there are two potential key recovery attacks against HMAC (assuming a reasonable hash function): Brute force the key; that is, take a valid (Message, MAC) pair, and try every possible key, and look for a key that gives that MAC for that Message Brute force the internal hashing state immediately after processing the IPAD/OPAD; here, you would take a ...


2

Not, that should be not possible, at least if you have a good key. All this is only valid as long as SHA-256 is still a secure hash algorithm and not broken. To be precise, as long as HMAC-SHA-256 is not broken. Does the attacker have any informations about the messages (other than the length and that they are "random-noise")? If he/she doesn't: No, ...


1

If the keys and messages are known, yes, you can distinguish which were used - because you can test them all. If not, then this is "sligtly harder" (= not really possible with big enough values). Anything of the further answer will assume that the attacker doesn't know the keys or the messages. The definition of HMAC looks like this: $HMAC(K, m) = H(K ...


1

I'm not sure about your specific system; this only addresses "can a key derived from the password make a good shared secret?" The most common password hashing functions are actually designed for exactly this purpose -- deriving a cryptographic key from a (weak) password. That's actually what PBKDF2 stands for: "password-based key derivation function #2" ...


1

NIST specifies the paired hash digest size beat least twice the key size of AES, therefore: AES-128 is paired with at least SHA-256 or SHA-512/256 AES-192 is paired with at least SHA-384 AES-256 is paired with SHA-512 SHA3 hash functions will be added to the list in the future The reason being that the collision and preimage resistance of the hash ...



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