Re: Database encryption.
From: John Hadstate (jh113355_at_hotmail.com)
Date: 11/17/03
- Next message: Ernst Lippe: "Re: Database encryption."
- Previous message: Benjamin Choi: "Re: Constructing S-boxes with recursive Feistel networks"
- In reply to: S.K.: "Database encryption."
- Next in thread: TC: "Re: Database encryption."
- Reply: TC: "Re: Database encryption."
- Reply: Bryan Olson: "Re: Database encryption."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 17 Nov 2003 06:06:47 -0800
"S.K." <stach78@poczta.onet.pl> wrote in message
news:bpa2m0$c4n$1@atlantis.news.tpi.pl...
> 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.
>
> My general idea is to ecrypt whole database using ECB mode.
Bad idea! Identical fields will encrypt to identical values. Thus, if I
known the plaintext at one row-column intersection and I know the
corresponding ciphertext, I also know the plaintext values at every
intersection containing that same ciphertext.
(A) Here is an alternative proposal that solves this problem, but gives rise
to other, perhaps less severe, problems. Before you encrypt a data item,
append the table name, the row number and the column name to the real data.
Then encrypt the whole string. This will substantially expand the size of
each encrypted data item, but will help insure that two identical values
don't encrypt the same way.
(B) Another option is to concatenate the table name, the row number, the
column name, and, if necessary, a counter into a single string. Then
encrypt this string, and XOR the ciphertext against your plaintext. If the
block size of your cipher is too small, increment the counter, encrypt the
new string, and again XOR the ciphertext against your field data. Continue
in this way until your entire field is encrypted. CAUTION: this technique
requires that you at least authenticate each row in the table to protect
yourself from attacks that might change a field value from say, 001.00 into
101.00. This will also expand your storage requirements, though not as much
as Option (A).
> Then any
> datasearch can be done just by encrypting query and comparing it with
> encrypted field in base.
Still true.
>
> 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.
Alternative (B) solves this problem. The ciphertext will have the same
length as the plaintext.
> 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)
What you need is called "armor". You convert your string into Base-64
representation before storing. A simpler alternative is to convert it to
Hexadecimal digits. In either case, the armored ciphertext will occupy more
space than the original ciphertext.
>
> P.S. sorry for any mistakes or errors in the text above - my english is
not
> perfect... yet ;-)
Your English is a lot better than my Polish ;-)
- Next message: Ernst Lippe: "Re: Database encryption."
- Previous message: Benjamin Choi: "Re: Constructing S-boxes with recursive Feistel networks"
- In reply to: S.K.: "Database encryption."
- Next in thread: TC: "Re: Database encryption."
- Reply: TC: "Re: Database encryption."
- Reply: Bryan Olson: "Re: Database encryption."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|