Olivier,

>> I think there is market for in-database encryption (probably small), basically the case when people want to protect the data from a casual look (embedded use of Firebird, dictionaries, etc.).
>
> Best handled at the application level then. Cloud computing? Not wanting your data unencrypted "over there"? Simply want to obfuscate or encrypt some data stored on a DVD? Nothing stops a developer to encrypt some of the data before storing it in the DB. Details are completely application dependent. Firebird out of the (in)equation.

Not everything can be encrypted on the application level... How are you
going to perform the range queries on obfuscated content? What about
LIKE queries or using SUM function?

Also as Geoff pointed out, ECB cannot be used here, but then
initializing the encryption code with a deterministic, though random,
init vector complicates the database layer (and I am not talking about
space overhead, when from a 4-byte integer encryption code will generate
e.g. 16-byte block, but that one corresponds 1:1 to the number anyway
and can be mapped easily).

Sorry, for such cases a replacement for PIO that encrypts/decrypts data
transparently seems to be a lot better, easier and separates the
responsibilities cleanly.

> ( And though these are rare events, you can fix the database structure of such a DB with ordinary tools or let other people do it for you: without exposing the secured data. )

Well, that's another topic, which should be considered by those, who
would implement the strong security.

Roman