>> If you want any chance of security by obscurity you must do it
>> outside the open source - the Firebird developers cannot do it
>> for you.

> I'm sorry to interrupt but this subject really interest me.

> Kerchkhoff's Principle
> In cryptography, a system should be secure even if everything
> about the system, except for a small piece of information
> — the key — is public knowledge.

>>From what I understand PenWin's proposal is embed the key on the
> application's executable. That would be the only part of the system
> depending on security by obscurity. The rest would be standard
> cryptography routines. That's not obfuscation by any means.

The principle is talking about public KNOWLEDGE of the
cryptography system. This is quite different to talking
about public ACCESS to the platform on which the encryption
(and/or decryption) process is occuring (which is the subject
of this conversation as it relates to Firebird databases).

You must understand that cryptography is only part of a secure
system. You must look at the entire life cycle of the object
you are protecting and identify all the risks; databases cannot
remain permanently encrypted, so the obvious weak point to
attack is where it is being decrypted for use.

Kerchkhoff's Principle is predicated on the fact that you must
_trust_ the platform on which you are encrypting/decrypting.
If you do not control it then it is unlikely you can trust it.

If you want some examples of end-to-end security, security in
which encryption is often used but is recognised as only part
of the whole, then take a look at this excellent book;
"Security Engineering" by Ross Anderson.
http://www.cl.cam.ac.uk/~rja14/book.html

There are examples in the book about efforts made to protect
secrets (often encryption keys and the like) inside tamper
proof boxes and smart cards, and how these are broken without
needing to break the encryption algorithm. The examples are
all much more difficult to crack than the simple problem of
finding the right spot to patch a Firebird server to reveal
unencrypted data.

There are also examples in the book of innocent lives disrupted
because, for example, the banks in the UK refused to admit that
their security system was vulnerable (see Chapter 9). Such
examples provide warnings to those that would blindly assume
their systems are secure.

(If you are still not convinced I suggest you try various
other forums. PGP-Basics (on yahoo groups) or the TrueCrypt
or GnuPG forums. These will all contain people that can
confirm what I have been saying here.)

--
Geoff Worboys
Telesis Computing