note to developers: when will some crypt/hash/(good)pseudo-random
function appear as firebird functions - there are currently some
udf's that provide it but somehow I don't believe their security ?

> That's my personal web page(in Macedonian) and it doesn't contain

any

> specifics about database encryption. I only used my web space to

upload

> the document I used to read on that topic. I only pointed out some

of

> the ideas I used at my company (since me and Lee J. are obviously

in the

> same business), that is storing hashes of the values that we

needed to

> be indexed (searchable). But for storing credit card numbers it's

not

> that convinient to store a pure hash of the card no since the set

of

> values is fairly limited so it is pretty easy to exhaust the set

of

> values. It's far better suffix the card no (or any other data

within a

> limited set of values) with DB encryption key so if an attacker

get's

> his hands on the data he won't be able to get the source values

without

> the DB encryption key used.

so you store and index hashes of the credit card numbers (or
encrypted data). yes you need to use random padding to enhance the
plaintext space. As far as the performance go I think that firebird
use varchar fields indexes equally well as an integer ones.

What you basicly is needed is to find out if the given credit card
is in system and if so what other data is connected to it. To
resolve this you can search for exact matches of encrypted form.
If you however need to select parts of the encrypted columns than
you need entirely different approach, I understand that in such case
you store hashes of the part of the column that you need to have
indexes (and alos search for exact matches of parts) - you cannot
pad it then (since differnet padding equal to differnet hashes) so
the plain text space is even more limited than before and so an easy
step would be to first decrypt the ordering columns and having part
of the credit card decrypted try to break the hash function (it
should be then fairly easier, since you only need to check if the
part of the result match the already encrypted part).

Also do you use one key to encrypt all the stored data? I believe
that it is the weak point to use the same key multiple times
(especially if the tables you encrypt use hundreds of thousands
encryptions) - even if you use different padding each time. And if
the attacks on key succeds, than entire database stands open.

The real problem with this system is the

> storage of the DB encryption key. If an attacker compromises the

system

> it will be easy to get access to the DB ecnryption key also, so

the

> ultimate secure solution would be to use an HSM (Hardware Security
> Module) under whose MasterKey the data would be encrypted/hashed.

:)
I haven't field tested it yet, but I designed an algorithm that
allow you to encrypt database and yet do not store the master key
anywhere on the system (DBA enter it as he login to start up the
server and perform admin tasks or alternatively the database is
readable as long as the crypto card containingi it is plugged into
the server machine).

>
> regards,
>
> --
> Riste Pejov
> Card Management System
> National Payment Card
> Kuzman Josifovski Pitu br.1
> tel:++ 389 2 3293 826
> Skopje, MKD
> http://www.npk.com.mk

CUIN Kaczy