I currently use server-side AES encryption on MySQL and would welcome this change.

I think you would have to add a "salt" column so that if a clear text value is repeated in the same column across many records, the random salt value (appended to the clear-text password prior to encryption) would cause the encrypted value to be different in each duplicate record.

One of the ways to attack an encrypted system is to look for repeated values and deduce their contents. Salting passwords randomizes all the fields making cryptoanalysis anywhere from difficult to impossible.

Please do use Cipher Block Chaining (CBC) - I think that is what you are referring to in Item #2.

Kevin

If Devart is successful, this will make using Clouds much safer, at least for text data. I assume that you won't be able to encrypt integer or double column types like you can with table wide encryption (dbISAM, NexusDb etc.). The encrypting password should be entered at the client to allow each customer to have their own encryption pw and it gets decrypted on the client. I wouldn't want the entire table to be encrypted with the same pw. This is the only way to ensure secure customer data. The developer can then choose whether to store the pw on the server or not. The AES algorithm is a good choice, and if you could allow for the developer to plug in other algorithms that would be great too.

Brent

We are researching the possibility to add client-side encryption. Our vision of this feature is the following:

1. After user have specified which fields need to be encrypted, their data will be encrypted on the client side (before sending to the server) and will be stored in the database in encrypted form.

2. After encryption the same data fragment in different places will be different after encryption. For example, a word “Delphi” in the beginning of the sentence may be encrypted as #$01#$AB#$54#$34#$C0#$A5, and the same word “Delphi” in the end of the sentence may be encrypted as #$D4#$12#$B5#$27#$5A#$50. As the same data fragments after encryption will differ, SQL queries with WHERE condition on the encrypted fields will not work correctly. Only client filtering with the Filter property of the DataSet will be possible.

3. Fields of Text and BLOB datatype (and of the corresponding types on other database servers) can be encrypted.

Should you have a different vision of this feature or have more suggestions on it, do not hesitate to post a comment.

Hello.
I want to understand.