What effect would there be if you used the same value you were hashing as the Key in an HMAC?

For instance given the following example:

message: "my secret message" 
nonce: "0BHKK9IFbdF85KrzMFNpauyxWsM="

If I combined the message and nonce (message + nonce) and use that combination for the HMAC Key and that combination is also what is being hashed what affect would that have in terms of security of the HMAC?

It would seem on the surface that this solves the issue of having to keep a contstant secrect key, because the Key itself, the message, is only known by the person who wrote the message in the first place and the nonce would simply be appended during verification.


2 Answers 2


HMAC is not an encryption mechanism. It works like this: you can compute the HMAC output over a given message and another piece of data called the key. Computation is deterministic, so for the same message and key you always get the same output. However, without knowing the key, it is infeasible to compute the HMAC output on a given message, even given a bunch of other HMAC outputs computed with the same key over other messages (so, in particular, one cannot recover the key from a HMAC output, even knowing the message).

HMAC thus serves as keyed integrity: you store the HMAC output with some data, so that you can recompute the HMAC later on and see if it still matches what is stored. On mismatch, you know that either the data, or the stored HMAC output, or both, has been modified.

However you put it, HMAC uses a key which is secret. If there is no key per se, that's no longer the MAC model, that's just creatively complicated hashing.

I understand your question as being implicitly this: you have an encryption system, which, for a given message, uses a secret key K and an per-message Initialization Vector (which you can call "nonce" if you wish). The IV is adjoined (as cleartext) to the encrypted message. You want to add some integrity check, so that you can reliably detect malicious alteration. So your idea is about computing something with hash functions, over the concatenation of the plaintext message and the IV, and store the hash output as a MAC (transforming the hash into "HMAC with the same data as key and main input" does not fundamentally change things here).

Basically, this kind of scheme is weak. The attacker knows the IV (since knowledge of the IV is necessary to decrypt, it cannot be itself encrypted). If the attacker "guesses" the message, then he can recompute the hash. If he can do some targeted modifications on the message (which is especially easy if the encryption is XOR-like, like a stream cipher, or a block cipher in CTR mode), then he can simply recompute the hash value and store it there. Even if you encrypt the hash output with the message itself, then the attacker can still modify the message and the hash correspondingly if encryption is XOR-like.

Also, that hash (or sort-of-HMAC output) can be used as a test to guess the message: the attacker can hash various messages combined with the IV, until a match is found.

If you do want to do encryption with a key, and have checked integrity, you are warmly encouraged to do so with an encryption mode which has been designed for that, e.g. EAX. If there is no encryption in your system and you still want checked integrity, you will need to store a secret key for that, however you take it, and there is little point in not using HMAC as it was meant to be, i.e. with a key as the "key".


A MAC is an authentication code. A correct MAC says “I, the key holder, have seen this exact message”. The whole point of using a MAC is to put the possessor of the secret key into the loop. If the key is deduced from the message, the only thing the value tells you is that you know the message. A simple digest does this already.

Adding a salt is orthogonal; you can do this with a digest or with a MAC.

Ok, now read Tom's answer (which somewhat hides the answer in an interesting essay).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .