Jim Starkey wrote:

>> ECB vs CBC? CBC isn't really a contender for this situation
>> any more. For want of better/easier reference you could read
>> this: http://en.wikipedia.org/wiki/Disk_encryption_theory
> There are bunch of assumptions that he makes that don't --
> and can't -- apply to a database engine. User access to raw
> pages, the ability to create raw pages and cause them to be
> decrypted, and the concern that given these, knowing whether
> or not a page has been changed or not is a problem. I'm not
> at all convinced he has anything but a straw man argument.

Ever heard of Firebird embedded? (That is after all where the
requests mostly start.) The parallels between disk and database
storage are very strong.

> [...]
>> Many techniques have dated, not because they are easily
>> broken, but because they give away details about the
>> information they were protecting. Such details make the
>> security vulnerable or potentially vulnerable and so new
>> techniques are derived to combat these problems.
> Could you give us an example of a peer reviewed crypto-system
> broken by other than brute force? Of course it's possible.
> But the current crop of codes have been pretty well studied.
> And even if broken, a security architecture isn't dependent
> on any specific algorithm.

I cannot attest to it's credibility but here is one off a
quick Google search:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.1857&rep=rep1&type=pdf

They say: "We demonstrate the cryptanalytic applicability of
these methods to the Advanced Encryption Standard (AES, [10])
by showing a known-plaintext (or known-ciphertext) attack that
performs efficient full key extraction. For example, an
implementation of one variant of the attack per-forms full AES
key extraction from the dm-crypt system of Linux using only 800
accesses to an encrypted file, 65ms of measurements and 3 seconds
of analysis; attacking simpler systems, such as “black-box”
OpenSSL library calls, is even faster at 13ms and 300 encryptions."

This isn't a situation most Firebird developers are likely to
be overly concerned about but understand that there are a great
many people looking for weaknesses - NOT just in the core
encryption algorithm BUT IN THE WAY IT IS IMPLEMENTED AS USED.

There are lots and lots and lots of such analyses going on all
the time. By following state of the art implementation
techniques you can reduce your exposure to the risks.

> [...]
> Are you accusing AES, RSA, and SHA-1 of being 30 years old

Nope. CBC was invented by IBM in 1976 (according to Wikipedia
but close enough for my purposes).

> [...]
> I, er, am sufficiently expert to know a) 2048 is divisible by
> 16, and b) XORing a fixed pattern with the code published is
> likely to be insecure.
>
> So what is your position:
> [...]
> or what?

Fairly simple.
* The effort to do a good job is non-trivial
* Putting in that much effort seems to indicate actually
learning enough about the subject could pay-off
* Doing it right/better is not more difficult, it just means
taking a little bit of time to learn about the subject

> I'm only arguing that you need a defensible security
> architecture before you start hacking. Design first,
> implement second.

You missed a step. Learn about your subject first.

Once you know something about the current state of the art
then you just might be qualified to consider design.

Sure there are lots of libraries out there that have ready
implementations of AES etc - but so far you have not
demonstrated an understanding of why such libraries
(including libtom that you suggested) include features like
CTR and LRW. The right tool for the right job. Learn
enough about your subject so you can actually identify
which are the right tools.

--
Geoff Worboys
Telesis Computing