[OT] Re: random, digest, uuid, cipher & Co

[PA <petite.abeille@...>]

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.

"WYTM?"
http://iang.org/ssl/wytm.html

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 :)

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/