Jim Starkey wrote:

> I'd like to suggest a short diversion into cryptology with
> regards to ECB (electronic code book), CBC (cipher block
> chaining), initialization vectors, Firebird, and security.
> It's not important, but it is interesting.

[...]

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

The art of cryptography is NOT to make something that you
don't have the skills to break, the art is to stop someone
else - who may well be smarter or more ingenious than you

The art of cryptography is to give as little away as
possible because it can be VERY difficult to determine what
an attacker may find to use against you.

For example most modern algorithms are resilient to many
recognised forms of attack but the rules can change quite
dramatically if an attacker can, for example, determine
some part of the encryption key (eg: from memory chips,
from file fragments and so on - perhaps some bug in the
implementation let's something usually minor slip, but
something minor combined with a poor implementation can
lead to disaster).

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.

Many here, yourself included apparently, will argue that
if an attacker can't immediately turn the data into
plain-text then the encryption is good-enough.

My counter to that is simply this: If you are going
to implement encryption at a performance cost of around
30% (or whatever) then why not do it to the best of your
ability?

. You may actually find performance increases (some
newer techniques can be faster than old ones).

. If you've spent x% of your performance it would
be nice to get as much as you can for it

. The only cost is admitting that you are not
omniscient and accepting that a reference from
a specialist in the field could actually be
worthwhile.

Throwing 30 year old code at something, without finding out
if it is still the best solution, is not the way to get the
best possible result. This is true for system programming
and it is especially true for cryptography and security.


I understand that I am probably wasting my breath here. I
have good confidence that those that are actually likely to
do any of the work are smart enough to study the current
technology. I'm just hoping my posts may encourage those
looking to develop their own encryption code to find some
real and actual expertise to assist them - to remind readers
that despite the "all knowing" tone of Jim's postings, he is
not a specialist in this field. (See polite I can be. :-)

--
Geoff Worboys
Telesis Computing