# ID-Secret Scheme

I have an ID-Secret scheme and I'd like to hear if there are any vulnerabilities present.

Party 1 and Party 2 hold some credentials, an ID and a Secret.

Party 1 Creates this message:

HMAC(ID, SECRET)
IV + ENCRYPT(MESSAGE, SECRET, IV)


Using: SHA-256 and AES-CBC-256

Party 2 can then verify the user and decrypt the message.

Are there any vulnerabilities present that I may have missed?

-
Using of Alice and Bob would be better than Party 1 and 2. –  ir01 Aug 3 '11 at 10:41
Please don't design a scheme and then ask us "is this secure?". Instead, tell us what you want to achieve and hopefully we can point you to a standard answer accompanied by a good security reduction. –  Paul Crowley Aug 3 '11 at 11:06
@Paul Crowley My aim is to authenticate a user successfully without revealing either the ID or the SECRET. I am fairly certain it is secure as it it, I'm just asking if there are any attacks (theoretical or practical) which reveal the values I'm trying to keep hidden. –  Chris Smith Aug 3 '11 at 13:03

I'm not sure which of the inputs in your HMAC is your key and which one the message. The secret should be in the key position here.

Also, you might want to include the message (either plaintext or ciphertext) itself in the MAC - otherwise you are vulnerable to an attacker which can change the data (even if he can't read it, and does not exactly know to what he is changing).

Perhaps I didn't make clear that the HMAC only serves as an identification method to Party 2 without revealing the actual ID or SECRET (the values I'm trying to hide).

The point is, if your authentication relies only on HMAC(secret, ID), then this value is the effective password, as it does not change between messages.

These are not bound to the message, which means that a changed message is accepted anyways.

Why will it be better to include a MAC of the ciphertext? The ciphertext is encrypted and as such one needs the SECRET (key) to successfully change the underlying input. If an attacker tries to change the ciphertext (without knowing the key), the intended recipient of the message will run into an error decrypting the ciphertext, or the underlying message will fail to be validated.

From this point of view, you don't need the identifying first part of the message at all.

There will not be an error on decrypting a changed message - just the result will be garbage. It depends on the message type which you are transporting here, whether this garbage can actually be identified as such. Using something like

MAC(ID + ciphertext, secret)


makes sure that the receiver will not even try to decrypt a faked message.

-
SECRET is the key, ID is the message on the HMAC. Perhaps I didn't make clear that the HMAC only serves as an identification method to Party 2 without revealing the actual ID or SECRET (the values I'm trying to hide). Why will it be better to include a MAC of the ciphertext? The ciphertext is encrypted and as such one needs the SECRET (key) to successfully change the underlying input. If an attacker tries to change the ciphertext (without knowing the key), the intended recipient of the message will run into an error decrypting the ciphertext, or the underlying message will fail to be validated –  Chris Smith Aug 3 '11 at 13:09
I added a bit of explanation here. –  Paŭlo Ebermann Aug 3 '11 at 14:51
For the first update, HMAC(secret, ID) is used so that an attacker cannot find the ID (which I'm trying to keep secret). In other words HMAC(secret, ID) is used as an identification token if you will... The second part of the message (the ciphertext) carries the authentication request. Each ID has a corresponding SECRET to Party 2, so Party 2 needs to: see if HMAC(secret, ID) exists, and if so check if the ciphertext can be decrypted with the corresponding SECRET. For the second update, as the result of the ciphertext can be validated, there is no need for a message MAC. –  Chris Smith Aug 3 '11 at 17:05
@ChrisSmith: Just rereading old questions/answers/comments: Your protocol will not keep the ID completely secret: if a user uses the same ID/secret combination multiple times, an attacker knows that this is the same user again. –  Paŭlo Ebermann Apr 21 '12 at 16:42
True. This was the first crypto-protocol I attempted to design and there are of course obvious flaws and design oversights. As for the problem faced, asymmetric cryptography proved to be an excellent solution. –  Chris Smith Apr 22 '12 at 10:52