Jim Starkey wrote:

> It's getting a little annoying to hear you say we don't
> know anything. The antidote to ignorance is to learn
> something.

Yes ... Is this some sort of progress we're making here, Jim?
I mean not that long ago you seemed to suggest that you didn't
need to know anything special or extra to use cryptography.

> No, the WEP guys didn't fail to do their homework. When they
> designed the system, it wasn't understood that a) the first
> few bytes revealed a tiny bit about the key and b) knowing
> the progression of generated keys allowed this to be exploited.

That reads an awful lot like a contraction in terms, and
there was more to it. This article gives one cryptographer's
view: http://www.schneier.com/crypto-gram-0103.html#10

And WEP are not the only ones to get it wrong, some manage to
do even worse:
http://www.schneier.com/blog/archives/2005/01/microsoft_rc4_f.html

These are simply examples of people that thought they could
implement a secure system based only on their own knowledge
and the ready availability of some library functions. With
a bit of luck those people may know better now.

> [...]
> So, if you have something to say, say it. If you have a
> comment, a question, an objection, or a suggestion, we're
> all ears. In specific, if there is something about Firebird
> requirements or communication mechanisms, ask. I don't
> think the requirements are at all settled, so that's a good
> place to start, if you'd like to do something constructive.

I've said most of it before so I'll try to be brief:

* I'm not the one to listen to for technical details about
secure protocols. Neither, I would suggest, are you, Jim.

* To get the best possible result I suggest that you choose
one of:

A. Implement (or make it easier for the end-developer to
implement) via existing and well tested protocol(s)
(OpenSSL etc) - rather than trying to design your own.

OR - if you feel you really have to design your own -

B. Get help from _qualified_ sources. Either in person
(perhaps someone from another open source project would
agree to help out) with the initial design stages at least.
Failing that, or in addition to that, whoever is going to
write the code should research up-to-date references on
the subject. This: http://www.schneier.com/book-ce.html
is one example, there are others.


Personally I like option A:

. I think it offers the best opportunity for strong security
that users can feel confident in (can choose from options
where the entire protocol, not just the cipher algorithm,
has been well studied).

. Done well it should still allow developers to choose other
options if they have specific needs. (It may be necessary
for licence reasons etc.)

. The responsibility for identifying and fixing often complex
security vulnerabilities can fall to those with the
knowledge, Firebird can just take up the changes.

. Firebird should concentrate its resources on what it does
best, if it can off-load the work involved in this far from
trivial area then it should do so.

. By implementing in terms of a larger external protocol you
force the database code to remain independent of the
security protocol. The risk with designing and embedding
your own protocol within the database code is for one to
begin to effect the other ... and so for vulnerabilities to
be introduced by others that don't understand the reasons
for certain behaviour. (Obviously most designs would try
to avoid such inter-dependency but a completely separate
protocol package would enforce it.)

--
Geoff Worboys
Telesis Computing