presentation & db encryption
diego
I've been using c#sqlite for several months in a couple of projects.
All of them involve decoding some formats and then storing the results
in sqlite's db files.Now, I need to encrypt sqlite files, ideally
without depending on openssl/gpg binaries/libs. So I've been reading
and exploring the soure code of c#sqlite, and have found an entry
point to insert custom encode/decode routines inside the code.
I'm planning in using a free(gpl) aes256 implementation, but firstly I
decided to try a simply xor encode routine as a proof of concept.
So, first thing was to modify the source so I can compile c#sqlite
with SQLITE_HAS_CODEC defined. Now that I have succeeded (compiles
with no warnings, works exactly the same as before, etc), I would like
to know if anyone is interested, moreover, if it can be included so
there is no need to make these changes again when next version is
released.
Maybe these work has already been done and it is ready in the git
repo.
Kosenko Max
It would be very useful.
About encryption - you shouldn't really use XOR at all.
In case you're on .NET you can use embedded native AES implementation.
In case you're on Silverlight - use AesManaged class
So no need to use GPL 3rd party tool.
Diego Torres
> You should post you diffs with changes here.
> It would be very useful.
For better understading of the code, I used the autoformat tool of
visual studio, so I'm going to recheck my changes to be able to make
proper diffs.
> About encryption - you shouldn't really use XOR at all.
It's a proof of concept. Once I have everything working I could move
to a more complex solution. Is my first attempt at modifying c#sqlite,
so I need to go step by step :)
> In case you're on .NET you can use embedded native AES implementation.
> In case you're on Silverlight - use AesManaged class
I'll give them a look. Using some 3rd party implementation (one that
is small, clean and efficient) ensures portability between ms and mono
implementations.
> So no need to use GPL 3rd party tool.
>
> On Jun 9, 10:20 pm, diego <diego.tor...@gmail.com> wrote:
>> Hi there!
>>
>> I've been using c#sqlite for several months in a couple of projects.
>> All of them involve decoding some formats and then storing the results
>> in sqlite's db files.Now, I need to encrypt sqlite files, ideally
>> without depending on openssl/gpg binaries/libs. So I've been reading
>> and exploring the soure code of c#sqlite, and have found an entry
>> point to insert custom encode/decode routines inside the code.
>>
>> I'm planning in using a free(gpl) aes256 implementation, but firstly I
>> decided to try a simply xor encode routine as a proof of concept.
>>
>> So, first thing was to modify the source so I can compile c#sqlite
>> with SQLITE_HAS_CODEC defined. Now that I have succeeded (compiles
>> with no warnings, works exactly the same as before, etc), I would like
>> to know if anyone is interested, moreover, if it can be included so
>> there is no need to make these changes again when next version is
>> released.
>>
>> Maybe these work has already been done and it is ready in the git
>> repo.
--
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
diego dot torres at gmail dot com - Madrid / Spain
Kosenko, Max
On Thu, Jun 10, 2010 at 02:05, Kosenko Max <kosen...@vyzo.com> wrote:
> You should post you diffs with changes here.
> It would be very useful.
For better understading of the code, I used the autoformat tool of
visual studio, so I'm going to recheck my changes to be able to make
proper diffs.
> In case you're on .NET you can use embedded native AES implementation.
> In case you're on Silverlight - use AesManaged class
I'll give them a look. Using some 3rd party implementation (one that
is small, clean and efficient) ensures portability between ms and mono
implementations.
Noah
If you send me the diffs, I'll integrate them into the current
release, and run them through the test suite to verify
If you send me the XOR encryption CODEC I'll add that to the test
suite as a "trivial" encoding case
Noah
On Jun 9, 5:52 pm, Diego Torres <diego.tor...@gmail.com> wrote:
Noah
only passes about 80% of the tests at this time
As an advance notice, there will be an added file crypto.cs that
implements a RijndaelManaged AES256 based encryption.
You will simply enter
PRAGMA key = "your key here";
after you open the database and everything else is handled.
However, I not sure if this will work with Silverlight, Max???
Maybe next week
Noah
Diego Torres
it is cleaner and I think it should work far better. I dont't know if
you have been working in this by yourself. Do you like me to send you
the updated diffs?
--
-- Use of a keyboard or mouse may be linked to serious injuries or
disorders.
diego dot torres at gmail dot com - Spain
Noah Hart
I've implemented most of your changes already, and used that as a basis
for the RijndaelManaged codec.
Noah
Noah
This was pushed as a working version 6/21 via changeset cfb824b19b6c
Let me know how it works for you
Noah
On Jun 19, 10:12 am, Diego Torres <diego.tor...@gmail.com> wrote:
> If you give me some more time, I'll send you a complete version. This
> is my current work, applies against 3.6.23.1.
>
>
>
> On Sat, Jun 19, 2010 at 16:30, Noah Hart <noah.h...@gmail.com> wrote:
> > Please do, I'll compare them against the versions I'm working with now.
>
> > I've implemented most of your changes already, and used that as a basis for
> > the RijndaelManaged codec.
>
> > Noah
>
> > On 6/19/2010 3:38 AM, Diego Torres wrote:
>
> >> During this week I have been improving the first diff I sent you. Now it
> >> is cleaner and I think it should work far better. I dont't know if you
> >> have been working in this by yourself. Do you like me to send you the
> >> updated diffs?
>
> >> --
> >> -- Use of a keyboard or mouse may be linked to serious injuries or
> >> disorders.
> >> diego dot torres at gmail dot com - Spain
>
> 11KViewDownload
Diego Torres
/* allocate space for salt data. Then read the first 16 bytes header
as the salt for the key derivation */
ctx.read_ctx.iv_sz = FILE_HEADER_SZ;
ctx.read_ctx.iv = new byte[ctx.read_ctx.iv_sz];//sqlite3Malloc( ctx.iv_sz );
Buffer.BlockCopy( Encoding.UTF8.GetBytes( SQLITE_FILE_HEADER ), 0,
ctx.read_ctx.iv, 0, FILE_HEADER_SZ );
Original code takes care when there is no file available, and produces
some random bytes to be used as the IV. In the C# version, you always
use the sqlite file header. Should special care be taken when using
in-memory db with the IV? I can't imagine why the original version
makes the random bytes thing if there aren't some security concerns...
Noah Hart
I'm not a cryptographer, but my understanding is as follows...
The IV must be known to the recipient of the encrypted information to be
able to decrypt it. So in the original implementation, for a new file
===========================================================================
/* allocate space for salt data. Then read the first 16 bytes
directly off the database file. This is the salt for the
key derivation function. If we get a short read allocate
a new random salt value */
ctx->kdf_salt_sz = FILE_HEADER_SZ;
ctx->kdf_salt = sqlite3Malloc(ctx->kdf_salt_sz);
if(ctx->kdf_salt == NULL) return SQLITE_NOMEM;
...
case 6: /* encrypt */
if(pgno == 1) memcpy(ctx->buffer, ctx->kdf_salt, FILE_HEADER_SZ);
/* copy salt to output buffer */
codec_cipher(ctx->write_ctx, pgno, CIPHER_ENCRYPT, pg_sz -
offset, pData + offset, ctx->buffer + offset);
return ctx->buffer; /* return persistent buffer data, pData
remains intact */
break;
===========================================================================
Note: The salt is actually being stored in page 1 of the file
===========================================================================
Q: One problem (er, point of curiosity?)... the CBC mode requires an
initialization vector (IV) that is passed to the encryption and
decryption functions. I've been reading some of the documentation
regarding AES and they all talk about randomly generating the contents
of this IV. I'm not quite getting this... if I randomly generate the
IV... how am I supposed to decrypt the file later unless I have that
exact same IV available to me at that time?
A: The point in using a "random", unique IV is to make sure that the
same message doesn't encrypt to the same ciphertext twice. It has no
function beyond that, and without the key, like the ciphertext, it's
worthless.
===========================================================================
I decided that given the previous points that there was no real benefit
from a randomly generated salt that needed to be stored. Perhaps this
was a short cut, and if so, needs to be changed
Regards -- Noah