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.

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.


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]