Jim Starkey wrote:

> Geoff, this is so staggeringly silly as to qualify you as a
> prime candidate for the Firebird "Helen of the Year" award.

Not very often you throw compliments around, Jim. Thanks.

> AES, like most modern encryption algorithms, is *not*
> vulnerable to plaintext attacks or,
> [...]
> And, no, a developer doesn't have to understand the crypto to
> use it, [...]

You speak of AES as if it is something complete in and of
itself. You only need to look at any competent implementation
to realise that this is not true.

A symmetric encryption block cipher allows encryption of only
a single block of data. Conceptually that process looks
something like this:

K
|
P-(A)-C

Where C is the CipherText (encrypted text)
P is the PlainText
K is the Key
and (A) is the encryption/decryption process: AES or whatever.

This is deterministic to the extent that if K and P are the
same then (A) will produce the same C (and vise-versa for
C and K producing P).

As I understand it (A) is written so that it is very difficult
to determine K even given matching P and C pairs ... BUT this
is only true for AES (and most others) if executed with
sufficient "rounds" to ensure this property (ie. You still
have to know how to implement it properly.)


But that is not the only form of plain-text attack.

Remember that a block-cipher typically encrypts only small
blocks at a time (eg: 16 bytes). The deterministic nature of
(A) means that every block of P that you encrypt with the same
K will produce the same C.

If you were foolish and ignorant enough to use ECB mode of
operation (as per the example you so generously posted to this
list, Jim) then you have just opened a major vulnerability in
your encryption.

What you are left with is like a huge jigsaw where some parts
are known (or can be easily guessed) and some parts are not
known but may well be inferred from adjacent known parts (and
once inferred they add to your overall knowledge).


1: There are quite a large number of pages in a Firebird
database for which we already know the content (or most of the
page). So we start every new attack already having a large
number of known pieces. [This is valuable input for any brute
force attack that, but it is not the only problem.]

2: I am guessing that internal knowledge of Firebird page
structure may very well lead to good guesses about parts
(16-byte parts?) of many (most?) other pages. (eg: Easy
identification of index pages from data pages etc.)

3: Plain text - of which a Firebird database contains a great
deal - is simply not very random. Given the small blocks of
encryption some of your database is very likely to repeat
itself. (Especially given its multi-generational transactions
etc.)

4: It is subject to replay-attacks because a user of the
system could easily prime the database with inputs to aid
later analysis.

5: If you were also foolish enough to not have any salt
involved per database (so you end up with multiple databases
all using the same K) then you are going to exacerbate the
problem - and given some of Firebird's other vulnerabilities
this could well lead to a very effective attack.

6: If you were foolish enough to implement the same effect
on your line protocol then the repetitive nature of
communication between the server and client is likely to
reveal a lot about your data.


This is, admittedly, just an amateurs analysis. I suspect that
a specialist in the field may be able to take this further.
But I think it's enough.

If people here want to take Jim's word for it then go ahead,
it's not a feature I intend to use anyway. But if you want to
implement some real encryption I strongly urge you to listen
to someone more qualified.

--
Geoff Worboys
Telesis Computing