Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I've implemented an API for one of my clients, it relies on nonces and a shared secret. The structure:

  1. Client's Site (CS) requests nonce from My App (MA), posting their username
  2. MA verifies the username is valid, then generates a nonce in response
    • The nonce is only valid for the given username and is only valid for 1 minute.
  3. CS uses the nonce to make a userful API call; the post looks like this:
    • username, nonce (from step 2), cnonce (Generated by CS), payload (Useful API call), and hash Which is a sha1 hash of the nonce, payload, shared secret, and the client nonce.
  4. MA confirms that the nonce is valid for the given username (and then invalidates the nonce for future use), and then uses the shared secret for the given username along with the nonce and provided client nonce to hash the payload and confirm the hash matches the given hash.

    If it matches, it executes the API call specified in the payload.

My question: Am I using the idea of a cnonce correctly? I'm having a hard time seeing its usefulness.

share|improve this question
3  
The construction Hash(nonce || payload || shared secret || cnonce) is a substandard Message Authentication Code; a safer option is HMAC(shared secret, (cnonce || nonce || payload) ). See the answer to this question –  fgrieu Nov 17 '11 at 10:35
1  
What is your goal with these nonces at all? –  Paŭlo Ebermann Nov 17 '11 at 14:21
    
@fgrieu thank you, I will switch over to that MAC convention [I have used that style before, but had forgotten about it -.- ] –  Shad Nov 17 '11 at 17:47
add comment

1 Answer 1

up vote 4 down vote accepted

The client nonce is there to protect the client against a replay attack. Without the client nonce, an attacker could intercept the initial request for a nonce by CS, and respond with an old nonce that the server used previously. Then, the client would use that old nonce and make an API call with it, which the attacker would again intercept, and the attacker would send back the response that the true server had actually sent when the nonce was first used. To sum up, the replay attack is about making the client interact with an old ghost of the server. The client nonce allows the client to make sure that he is talking with a "fresh and alive" server.

A client nonce would not be needed if the client had a local memory large enough to recall all previously used nonces -- the kind of memory which resists across reboots, and can store all nonces for the whole duration of the shared secret life. That's rarely practical.

share|improve this answer
1  
The cnounce could and should be used as suggested in this answer; but it is not used in this way in the protocol now described in the question. For now, cnounce seems to protects only against an adversary trying to determine if shared secret has changed. –  fgrieu Nov 17 '11 at 20:59
    
Thank you for the explanation. –  Shad Nov 22 '11 at 19:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.