Tom Lane wrote:
>
> "Maurice Gittens" <mgittens@gits.nl> writes:
> > This may be true. The point I'm trying to make is that using one
> > way-functions together with a shared secret will make it possible to
> > avoid denial of service attacks which rely on replaying the "magic
> > token".
>
> > Again I assumed it to be understood that the pid of the particular backend
> > would exchanged with the client during the initial handshake. It would also
> > be included (together with the shared secret e.g. the password and
> > and some form of a sequence id) in the one-way hash.
>
> Ah, now I think I see your point: you want to encrypt the cancel request
> so that even a packet sniffer could not generate additional cancel
> requests after seeing the first one. That seems like a good idea, but
> there is still the problem of what to use for the encryption key (the
> "shared secret"). A password would work in those authentication schemes
> that have a password, but what about those that don't?
Aha!
I'm slowly working through back emails, so I apologize if someone else
already posted this. If we want to create a shared secret between the
postmaster and the client, we should think about the Diffe-Helman
algorithm.
For those unfamiliar with this, we start by picking large numbers b
and m. The client picks a number k and then sends K=b^k%m, while the
server picks a number l and sends L=b^l%m. The client calculates
L^k%m and the server calculates K^l%m, and these numbers are
identical. A third party eavesdropping on the conversation would only
get K and L, and would have no idea what the shared number is, unless
they can calculate the computationally infeasible discrete logarithm.
Anyway, something to think about.
Ocie