lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Apr 13, 2005, at 20:21, David Haley wrote:

If the client is in charge of validating the signature, where is your authentication? Are you worried about connection interception? Your protocol seems like it is very vulnerable to an intruder listening on the network who could impose as either one of the players.

As the others have pointed out, there is more to a secure protocol than throwing together lots of hashes and encryptions. You took out the shared secret; do you know what role it plays? Why is it important? Does your protocol allow client authentication to the server? What about server authentication to the client? Do you care about either/both of these? Cryptography is only a portion of the problems when it comes to protocols. Even a protocol that uses (theoretically!) unbreakable cryptography can be very vulnerable to imposture or authentication failure.

Yes. "Security" is always a compromise. And there is no foolproof "security", whatever that word means in practice.


In this specific scenario, I would like to somehow identify the client to the server. Client and server can reverse roles, so this goes both way. In other words, client and server are peers. And the entire communication between the peers is automated. There is no user involved and no one to type any password anywhere, anytime, anyhow.

One could use client and server side X509 certificates to identity client and server to each other. The question remains on how to get those certificates in place and how the "chain of trust" is setup. A problem by itself altogether.

One way or another, a hard core public key infrastructure is out of reach for my little Lua setup. What I would like to achieve instead is some form of lightweight, casual, "identification" of some sort or another.

The current concoction involve 3 steps:

(1) Upon connection, the server provide a random token to the client
(2) The client sign the token with its private key and pass it back to the server (3) The server ask a directory service for the location of the client and ask that node to validate the token signature.

And yes, each step can be compromised one way or another: the random token could not be that random. The signature could turn out to be quite predictable. The directory service could be compromised. The callback could be highjacked. Etc...

I'm open to concrete and practical suggestions beside pointers to Mr Schneier's blog :)


PA, Onnay Equitursay