Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

Hi there. Welcome to the site. I'm guessing your down votes are because this question is very difficult to read.
–
Rory Alsop♦Apr 12 '13 at 17:34

1 Answer
1

In an authentication protocol, there is the prover and the verifier. In cryptography and network computing in general, you are what you know. Indeed, from the outside, I "see" you only through what you do on the network (the packets you emit), and thus I can make a difference between "you" and "someone else" only on the basis of what you can do and that someone else could not. Since everybody can buy the same kind of PC, "what you can do" equates to "what you know".

For instance, suppose a simple password-based authentication protocol. "What you know" is the password. "What you can do" is emitting a packet containing the password.

A challenge is a non-fixed value that I, as a verifier, will send to a prover, daring him to perform a computation which involves the challenge and whatever secret value the prover knows. For instance, I know a password and I know that the "genuine Hossein" also knows it. Someone alleging to be Hossein contacts me. To make sure that this is the true Hossein, I send him a challenge, i.e. a random string r. He should then respond by sending me the hash of the concatenation of the challenge r and the password p. The true Hossein can do that (he knows p) and, since I know the password too, I can compute the expected response and see if that's the same value that the purported Hossein returned.

The advantage of this protocol over the simple "show the password" method is that the password is not actually sent "in the clear". An attacker observing the data packets will not learn the password immediately; he just learns the "appropriate response" for a given challenge r. But this won't bring him far: if the attacker tries to impersonate Hossein later on, I will send him another challenge value -- a new random challenge r', not the same r than previously. The attacker, not knowing the password, won't be able to compute the right response for r', since he only knows the answer for challenge value r.

(This simplistic protocol has other issues, but it still illustrate the basic concept of a "challenge" in an authentication protocol.)