2

I have this argument that I'd like to verify:

If ONLY Alice and Bob have the shared symmetric key, why cannot message encryption serve for authentication in practice instead of digital signature schemes? If an attacker can capture this message, he won't be able to do anything unless he knows the keys. Thus, message encryption seems a valid authentication mechanism to me which takes less computation than digital signature ( thus more efficient! ).

2
  • But that wouldn't work in the case of public key crypto systems, correct?
    – katrix
    Nov 21, 2016 at 19:44
  • 1
    en.wikipedia.org/wiki/… ​ ​
    – user49075
    Nov 21, 2016 at 21:44

3 Answers 3

4

Yes, well-observed. In fact this is used in real-world crypto systems:

The Kerberos protocol that underpins all Windows authentication does almost exactly what you're suggesting (source: wikipedia.org/Kerberos_(protocol).

Client Authentication

  1. The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server).

  2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:

    • Message A: Client/TGS Session Key encrypted using the secret key of the client/user.

    • Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

  3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key.


As you point out, this is as a valid authentication mechanism which takes less computation than digital signature, but it requires a pre-shared secret. This is a BIG BUT in a lot of situations.

For example, I want to create a new account at mybank.com, which I want to do over https. My browser has never been there before, so I don't have a pre-shared secret with the mybank.com server. Part of the https handshake is having the server authenticate itself to the client (prove that it is infact mybank.com, and not a man-in-the-middle), which is impossible to do using only symmetric crypto and no pre-shared secret.

It is for situations like this that Public-Key cryptography is king.

4
  • 1
    I think the important thing here is the "it does almost exactly what you're suggesting" line. The exact protocol used, and the way it is implemented, matters greatly. If you leave out just a small part, you might break the authentication property in all kinds of ways (for example, making replay attacks possible by forgetting timestamps or validity periods, etc). Simply encrypting something is NOT a good way to authenticate it, you need a very well-thought-out protocol to make it work. Nov 21, 2016 at 21:38
  • @pascal I agree, but I think you're making this more complex than it needs to be: the OP asked "can symmetric encryption be used for authentication?" The answer is yes, here's an example. If the OP comes back with t a new question about designing their own protocol, then all the usual warnings will apply. Nov 21, 2016 at 21:46
  • I thought the question was "is symmetric encryption a general solution for message authentication" (hinted at by the title of the question), in which case the answer would be "no, unless you really know what you're doing". The assumption used in the question (if the key remains secret, authentication works, the attacker can't do anything) can be shown to be false. Nov 21, 2016 at 21:56
  • Ok. I've answered based on my interpretation of the question, you've answered based on yours. I'm fine with that. Nov 21, 2016 at 22:00
2

No. Message encryption only works in well-defined circumstances to authenticate a message, it's not a general authentication solution.

If an attacker can capture this message, he won't be able to do anything unless he knows the keys.

This is false. Here's a set of circumstances where it completely fails: Imagine you're using a block cipher using 8-byte blocks in ecb mode. In that mode, a preceding block doesn't influence the following block.

Now assume Alice encrypts a secret to Bob, namely, "I love you, Bob!". This yields "ztlk43aAb2329iw2". I want to change this message Alice really doesn't like Bob's job, and if I can goad her into encrypting something like "I hate your job!" with the same key, that might yield something like "7ZutlwNmsdlfdsaK". Now I simply take the first 8 bytes of this and stick the last 8 bytes of the original message to the end, yielding "7ZutlwNmb2329iw2". When Bob decrypts this, it produces "I hate you, Bob!".

Authentication failed, and budding love died in midflight.

As Christian said, you need to use an hmac to authenticate. Hmacs work by concatenating a secret (password) to the message to be encrypted and hashing it (it's a bit more complicated than that, in fact, because simply concatenating wouldn't be secure), and you authenticate the message by doing the same with the known secret and comparing the resulting hash value.

There used to be a debate among security people as to whether to encrypt-then-authenticate or authenticate-then-encrypt, which goes to show that encryption alone isn't considered enough, even if the sequence of the two operations wasn't/isn't immediately obvious.

In fact, I think the right way to do this is encrypt-then-authenticate (and on the receiver's end authenticate-then-decrypt), so that you never try to decrypt a message that wasn't first authenticated.

3
  • The same kind of problem (determinism of the output, and even blocks - if we wanted oto use block chaining on assymetric reason) applies to public-key crypto without proper padding and hashing. So its not a matter of using symetric x assymetric. You may use symetric crypto to authenticate, just need to use, as in assymetric crypto, a proper crypto scheme for it.
    – CristianTM
    Nov 21, 2016 at 20:14
  • Yes. Never said it was a matter of symmetric vs asymmetric, but I did say it only works in well-defined circumstances. Edited the answer to make it clearer. Nov 21, 2016 at 20:15
  • I see. You assumed he wants to use plain symetric crypto, I assumed that he wants to replace assymetric crypto by symetric ;). Well, re-reading the answer I think you may be right, but ill wait the OP
    – CristianTM
    Nov 21, 2016 at 20:18
0

Yes, it is possible to use symetric encryption instead of assymetric encryption to authenticate. But not just simple symetric ciphering, as you may be thinking.

What you are describing is correctly done by a MAC - Message Authentication Code - tipically by HMAC (Hash based MAC) - that does just that - Authentication using symetric crypto/shared key.

2
  • HMACs use keyed hashes. MAC may also be based on symetric encryption algorithms too, eg CBC-MAC en.wikipedia.org/wiki/CBC-MAC. Anyway, having a single symetric key, it is symetric crypto ;)
    – CristianTM
    Nov 21, 2016 at 20:06
  • 1
    Fair enough, I retract my comment :P Nov 21, 2016 at 20:08

You must log in to answer this question.

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