[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: [OT] Re: random, digest, uuid, cipher & Co
- From: PA <petite.abeille@...>
- Date: Thu, 14 Apr 2005 12:12:56 +0200
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/