Re: Database encryption.
From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 11/17/03
- Next message: Bob's Friend: "Good enough for crypto?"
- Previous message: John Hadstate: "Re: Database encryption."
- In reply to: S.K.: "Database encryption."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 17 Nov 2003 15:47:25 +0100
On Mon, 17 Nov 2003 09:59:12 +0100, S.K. wrote:
> Hi all.
>
> I am writing application that encrypt paradox type database with IDEA
> algorithm. The application should allow user to work with the database while
> it is encrypted.
First of all, what is the problem that you are you trying to solve?
Encrypting the database by itself is probably not a solution against
serious attackers. They will disassemble your application (that is
easier than you may think) and use that to find the key. What type
of attacks do you expect against your system?
> My general idea is to ecrypt whole database using ECB mode.
ECB mode is generally considered to be very weak, because identical
plain-texts always encrypt to the same crypt-texts. For your
application you should probably use CTR mode, this has the
additional advantage that it can be used to encrypt strings
of arbitrary length, i.e. the strings need not be a multiple
of the block size.
Also it is probably better to use AES instead of IDEA. AES is
"the" new standard and it is generally considered to be a very
good block cipher.
> Then any
> datasearch can be done just by encrypting query and comparing it with
> encrypted field in base. Viewing or seting data is being done the same way -
> data is stored encrypted, and field content is decrypted just before showing
> on the screen. Similary, changing data is done by encrypting inputed text
> and writing it into database field.
>
> However I encountered some problems with implementation of this idea.
> Storing encrypted data in database fields causes difficulties - field must
> be at least 8 bytes large, because of block size in IDEA algorithm.
> Additionaly, in string fileds stored cryptogram causes problems if any byte
> of it happends to be 00000000, because string interpretes it as '\0'
> character, which is used to mark end of string. Similar problem appears with
> such characters as '\' , '\r', and others (I use C++ builder)
The problem with "null" bytes can be simply caused by the fact that
you are using C strings. Can't you use the Pascal string type? Recent
versions of C++ builder include many parts of Delphi, and the Delphi
strings can correctly handle null bytes, if I remember correctly.
It is possible that the Paradox string fields cannot handle binary
data, but I believe that it is possible to store such data in "blobs",
but they are more expensive.
It is possible to store binary data in string fields by converting the
binary data to normal text. One way to do this is to use base64
encoding, but this means that you can only store 6 bits of your binary
data in each database character, in other words your fields will get
33% longer. Still, this is probably the easiest solution for this
particular problem.
With your approach every database field is encrypted independently,
this nasty, because two different database fields that have the same
(unencrypted) contents will encrypt to the same value. It would be
very desirable to have different encryptions for different database
fields but this would require some unique identification of each
database field. I don't know if you can get a unique identification
for each database field in C++ builder, you might be able to do
something based on the record number within the table plus the
number of the column, but then you would not be able to reorganize
the table or to compact the table (deleting a record is probably
OK because I believe that Paradox does not actually remove the
record but only flags it as being deleted, so the record numbers
for the other records are not affected).
A much better approach would be to encrypt the entire database as a
single unit, but this would probably require some serious
modifications to the low-level database drivers.
Anyhow, none of these solutions will work against serious attackers.
The easiest, but not highly secure, solution for you that I see at the
moment is to encrypt individual fields with AES in CTR mode and to use
base64 encoding before storing it in the database.
greetings,
Ernst Lippe
- Next message: Bob's Friend: "Good enough for crypto?"
- Previous message: John Hadstate: "Re: Database encryption."
- In reply to: S.K.: "Database encryption."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
