On Sun, Oct 21, 2012 at 4:10 AM, Staffan Tylen <staffan.ty...@gmail.com>wrote:
>
>> Have you tested things? With the encryption ability added, can you still
>> work with un-encrypted databases? In other words, with the encryption
>> added, could someone that doesn't need / want the encryption use the
>> oosqlite.dll without problems?
>>
>>
> Mark, to answer your question: yes, it's all transparent. If you don't use
> the sqlite_key interface as the first action against the newly connected
> database it is assumed that the database is non-encrypted and even if you
> use it against an existing database it doesn't change its current
> encryption state, BUT it prohibits you to access the non-encrypted database
> for the rest of that connection session! Using sqlite_key late in a process
> has no effect, but sqlite_rekey can be used anytime, either to encrypt a
> non-encrypted database or to change the encryption key of an already
> encrypted db. I've confirmed all this.
>
Okay, that sounds good.
Yesterday when I said that adding encryption did not change the database
size by much, I was wrong. I didn't realize that the build had linked
dynamically against the botan DLL. The pre-built binaries from the botan
project did not include a static library to link with.
So I built the botan libraries myself to get a static library to link with.
Then static linking to that library increases the size of the ooSQLite
binaries about 2.5 times:
With encryption support:
----------------------------------
1,913,344 oosqlite.dll
1,868,288 ooSQLite3.exe
Without encryption support
--------------------------------------
790,016 oosqlite.dll
746,496 ooSQLite3.exe
The advantage of static linking is that the Rexx user does not need to
install anything else for ooSQLite to work.
Unless someone has the botan.dll installed for some other program, there is
no file size advantage in dynamically linking to the botan DLL:
2,205,696 botan.dll
Right now I'm thinking of having one ooSQLite.cls file with the key and
rekey methods, a method for checking if the loaded DLL has encryption
support or not, and adding encryption support enabled / disabled to the
output of the version command. If the DLL without encryption support is
loaded, then key and rekey return an error code if invoked.
The normal ooSQLite package would have the non-encrypted support DLL. A
DLL with the encryption support compiled in would be available for
download. Anyone could download this DLL and replace the non-encrypted one
with the one with encryption support.
There are other ways to do this of course. There could be two completely
separate packages with different file names. Or there could only be the
DLL with encryption support.
Wonder what people think here.
>
> I've started some more serious testing and I believe that the suggested
> approach MAY need a refinement. My sample code for the key/rekey features
> in ooSQLite lack the possibility to specify a database name, so 'main' is
> always assumed. I believe this might be necessary in order to create
> encrypted backups using the sqlite_backup interface (e.g. .ooSQLiteBackup).
> Saying that I found it encouraging that SQLite by default supports not only
> sqlite_key and sqlite_rekey (WITH an explicit database name so it should
> probably be part of the Rexx API as well)
I'm not sure I understand what you mean here Staffan. sqlite_key and
sqlite_rekey are added in to SQLite through codecext.c. Neither of those
APIs provide a way to specify a database name:
int sqlite3_key(sqlite3 *db, const void *zKey, int nKey)
{
// The key is only set for the main database, not the temp database
return sqlite3CodecAttach(db, 0, zKey, nKey);
}
There is no argument to the API to specify a database name.
> but I also found that the non-documented(?) extension 'KEY xxx' to the
> ATTACH command seems to work as well.
Using non-documented extensions is always risky.
> The following command scenario therefore works OK (assuming the encrypted
> databases already exist and have some data):
>
> >oosqlite3 encrypted.db
> .key abc123
> select * from tbl1;
> attach 'encrypted2.db' as anotherdb key def123;
> select * from anotherdb.tbl1;
>
> Good, eh? :)
>
> So to summarise I think the key and rekey features should be extended to
> support format (re)key([db], key), with 'main' being the default for db.
>
I don't see any way to do that. The underlying API does not support that
as far as I can see.
--
Mark Miesfeld
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
