Subject Re: [Firebird-Architect] SRP, TLS, and a Security Architecture
Author Jim Starkey
The short answer is that TLS is huge, slow, and does a lot of stuff you don't need.

Founder, NimbusDB, Inc.
978 526-1376

On Nov 29, 2010, at 3:51 AM, Alex Peshkoff <peshkoff@...> wrote:

> 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
>> 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?
> ------------------------------------
> Yahoo! Groups Links