On 11/27/10 01:32, Jim Starkey wrote:

> The crypto handshakes I was working on were variations of encrypted
> key exchanges (EKEs) where session keys are exchanged using a variation
> of { account, password } as the encryption key. The simplest form of an
> EKE requires that the password or a password equivalent reside on the
> server so that a successful server attack would yield login
> credentials. A slightly more sophisticated version encrypts the {
> password, session }, allowing the server to authenticate the client
> without a password plaintext equivalent, but can still be broen with a
> successful server attack and capture of a login packet.
>
> This is the problem that the Secure Remote Password (SRP) protocol
> solves -- mutual authenticate with immunity to anything but a dictionary
> attack if the server is completely compromised; QED. A succinct
> description of SRP-6 can be found at http://srp.stanford.edu/design.html
>
> With regards to Firebird, the question is whether to include a full TLS
> implementation or just SRP and RC4. Assuming the TLS implementation is
> up date, the very best Firebird is going to get out of TLS is an SRP
> handshake followed by RC4 line encryption. The downside of a full TLS
> encryption includes:
>
> 1. A gigantic code base
> 2. A latency inducing crypto negotiation before the two ends agree on
> a SRP handshake
> 3. The API and library hassle of introducing full TLS in various clients
>
> An SRP implementation requires only a multi-precision arithmetic
> library. There are a variety available under various license, including
> the Gnu GMP library under LGPL.

If I'm not mistaken, your favorite libtom project also contains
multi-precision arithmetic library.

> All in all, I think a full implement of SRP-6 (aka RFC 5054) is probably
> smaller than code required to support TLS. Given identical security
> algorithms between a native Firebird and a full TLS, I think it makes a
> great deal more sense to go native.

Though I myself do not like idea of using full TLS, I wish to ask a
question to make sure.

TLS is already widely used thing. May be instead of adding TLS code into
our client (and server) we should better use already existing in OS TLS
support? What prevents us from doing it?