Re: [sqlite] to encrypt sqlite db

[Yuriy Kaminskiy]

Etienne wrote:
> - Original message -
> From: Paolo Bolzoni <paolo.bolzoni.br...@gmail.com>
> To: General Discussion of SQLite Database <sqlite-users@sqlite.org>
> Subject: Re: [sqlite] to encrypt sqlite db
> Date: Sun, 1 Sep 2013 18:24:13 +0200
>> On Sun, Sep 1, 2013 at 6:10 PM, Etienne <etienne.sql...@mailnull.com> wrote:
>>>> On Sun, Sep 1, 2013, at 17:50, Clemens Ladisch wrote:
>>>>> Ulrich Telle wrote:
>>>>>> Am 31.08.2013 22:01, schrieb Etienne:
>>>>>>> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
>>>>>>> salts:
>>>>> Well, that's not completely true. The encryption extension coming with
>>>>> wxSQLite3 uses a different IV (initial vector) for each database page.
>>>>> True is that the IVs are not random, but deduced from the page number.
>>>>> However, I don't see much difference between generating an IV
>>>>> algorithmic or using a random nonce which is stored at the end of each
>>>>> database page
>>>> <http://en.wikipedia.org/wiki/Initialization_vector> says:
>>>> | Randomization is crucial for encryption schemes to achieve semantic
>>>> | security, a property whereby repeated usage of the scheme under the
>>>> | same key does not allow an attacker to infer relationships between
>>>> | segments of the encrypted message.
>>>>
>>>> Without a random IV/nonce, every page is guaranteed to encrypt to the
>>>> same data if the contents and the key have not changed.  Thus, wxSQLite3
>>>> gives an attacker the ability to determine whether any particular page
>>>> has changed, by comparing the old and new versions.  With SEE, rewriting
>>>> a page will encrypt to a different value because the IV changes even for
>>>> otherwise unchanged pages.
>>>>> The weak point of probably all SQLite encryption methods is that the
>>>>> unencrypted content of the first 16 bytes of a SQLite database file is
>>>>> well known.
>>>> Many file formats have fixed parts.  However, this is not a problem with
>>>> properly implemented encryption algorithms.
>>>>
>>>
>>> In this particular case, you get what you pay for.
>>>
>>
>> Another weird sentence in the mailing list
>> of probably most used DB that is really free.
>
> wxSQLite (relevant part) and SEE are extensions to SQLite.
>
> wxSQLite is free, while SEE is definitively not.
>
> wxSQLite means "pseudo" encryption (as formerly discussed), while SEE is real
encryption.
>
> What is weird???

Weird is to talk about something one have little clue about? **

Have you looked at wxSQLite sources? Obviously, no. Otherwise you'd know there
are more in story than just IV generation - they also alters key per-page
(*edit* and, of course, wxSQLite don't use ECB!).

While wxSQLite encryption have some, erm, strangely/unusually designed parts,
that "strangeness" is about on par with (different) SEE's "strangeness".
I don't see reason to claim SEE offers any more "real" encryption than wxSQLite
(in AES256/SHA256 mode).

Compare both of them with "truly real encryption" schemes, e.g. used by LUKS or
truecrypt; you'll notice several differences at once (e.g. lack of key
strengthening in SEE [apparently, they use password as raw encryption key -
there are no other way to explain "... only the first 256 bytes (RC4) or 16
bytes (AES) will be used..."] - important when you target your product for
crypto-illiterate users; plus, while "silent key truncation" is documented and
can be claimed "not a bug", it can lead to nasty surprises in hands of said
crypto-illiterate users; lack of password salting in both; no way to change
password without re-encrypting whole database in both; very unusual/unsuitable
for FDE encryption modes in SEE; unusual per-page keys and IV generation scheme
in wxSQLite [it is not broken in obvious way, but "crypto" and "unusual"
together sounds troubling]; unbalanced AES128/MD5 algo pair in wxSQLite; so
called "random" nonce in SEE - how was that "random" generated and seeded?***;
and, at last, their use of their own crypto implementations instead of optimized
libraries [compare their speed with e.g. `openssl speed aes-128-cbc`, especially
on CPUs with AES-NI or SSSE3 available]; and maybe more).

*** Obtaining *true* randomness in naturally deterministic computers is not
easy, especially on virtualized and embedded platforms; and crypto-quality PRNG
is even more complex problem;
Debian's openssl, sony ps3 or

Re: [sqlite] to encrypt sqlite db

[Yuriy Kaminskiy]

Ulrich Telle wrote:
> Am 31.08.2013 22:01, schrieb Etienne:
   On Sat, 31 Aug 2013 17:17:23 +0200
   Etienne 
 wrote:

   > > On the other hand removing patterns definitely cannot hurt.
   >
   > Precisely.
   >
   > The very first bytes of SQLite files are, AFAIK, well known.

   That's what salt is for, no?

>>> "nonce", "IV", "salt" - call it whatever you want.  Yes.
>>
>> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
>> salts:
> 
> Well, that's not completely true. The encryption extension coming with
> wxSQLite3 uses a different IV (initial vector) for each database page.
> True is that the IVs are not random, but deduced from the page number.
> However, I don't see much difference between generating an IV
> algorithmic or using a random nonce which is stored at the end of each
> database page as SEE does according to the documentation to be found
> here: http://www.sqlite.org/see/doc/trunk/www/readme.wiki

Funny, for all encryption modes, used in SEE (rc4, AES-OFB, AES-CCM), *any* IV
reuse ends up in bad [OFB] or even catastrophic [rc4, CCM] way (you must *never*
encrypt any two blocks with same IV with those modes).

But that's just result of inappropriate choice of those encryption modes. There
are encryption modes with *different* properties. Normally disk encryption use
CBC+ESSIV, XTS or LRW, which ain't sensitive to IV reuse (unmangled/plain sector
number as IV works just fine with them).

> In both cases you know the IV - at least if you have access to the code
> generating it (which is the case for wxSQLite3 as it is open source, but
> not for SEE as it is closed source).
> 
> The weak point of probably all SQLite encryption methods is that the
> unencrypted content of the first 16 bytes of a SQLite database file is
> well known. To get a better encryption maybe the first 16 bytes should
> always be kept unencrypted to not give a clue to a known pattern.
> 
>> 2 SQLite DBs built exactly the same way at different times are
>> byte-to-byte identical.
> 
> That's true. However, in real life it probably matters only for
> read-only databases. As soon as different people start to work with such
> an encrypted database, the database files will certainly deviate from
> each other considerably as it is very unlikely that all users perform
> their actions in exactly the same order.
> 
> BTW, you only get identical database files if you use the same
> passphrase. If the passphrase is hardcoded into the software then
> certainly this may impose a problem. However, for an application with
> high security demands you certainly shouldn't hardcode the passphrase
> into the software.

FYI: two LUKS or truecrypt containers with same passphrase *won't* be same (and
they *don't* need to save per-sector nonce/IV separately, unlike SEE).

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Clemens Ladisch]

Ulrich Telle wrote:
> Am 02.09.2013 06:11, schrieb Etienne:
>> wxSQLite3 does implement AES in ECB mode
>
> Wrong. CBC mode is used.

Inside one page.

If we ignored the actual block size, and viewed the entire database as
a stream to be encrypted by a cipher with a block size identical with
the page size, then wxSQLite3 would be using CTR mode (with the nonce
reused for multiple messages).

But it does not really make sense to try to describe a random-access
encryption algorithm with a _stream_ cipher mode.  SEE's algorithm
(separate IV per block) would not have an equivalent mode.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Ulrich Telle]

Am 02.09.2013 06:11, schrieb Etienne:

wxSQLite3 does implement AES in ECB mode


Wrong. CBC mode is used.

Regards,

Ulrich


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

On Sun, Sep 1, 2013, at 19:59, Ulrich Telle wrote:
> Am 01.09.2013 18:40, schrieb Etienne:
> > wxSQLite is free, while SEE is definitively not.
> 
> The original poster searched for a free encryption extension, of which 
> there exist several: System.Data.SQLite (RC4), wxSQLite3 (AES-128 or 
> AES-256), SQLCipher (AES-256 with nonce) to name a few.
> 
> Depending on the security requirements one of the free solutions may be 
> good enough for the OP.
> 
> > wxSQLite means "pseudo" encryption (as formerly discussed), while SEE is 
> > real encryption.
> 
> This statement is nonsense. Certainly SEE provides stronger encryption 
> than wxSQLite3, however, the encryption used by wxSQLite3 is also "real" 
> AES encryption (not "pseudo", which implies "easy to  break").
> 
> Regards,
> 
> Ulrich

wxSQLite3 does implement AES in ECB mode and the SQLite file header is well 
known... so yes, it is definitively pseudo encryption.

It might be enough for the OP's purpose (unknown so far), though.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Ulrich Telle]

Am 01.09.2013 18:40, schrieb Etienne:

wxSQLite is free, while SEE is definitively not.


The original poster searched for a free encryption extension, of which 
there exist several: System.Data.SQLite (RC4), wxSQLite3 (AES-128 or 
AES-256), SQLCipher (AES-256 with nonce) to name a few.


Depending on the security requirements one of the free solutions may be 
good enough for the OP.



wxSQLite means "pseudo" encryption (as formerly discussed), while SEE is real 
encryption.


This statement is nonsense. Certainly SEE provides stronger encryption 
than wxSQLite3, however, the encryption used by wxSQLite3 is also "real" 
AES encryption (not "pseudo", which implies "easy to  break").


Regards,

Ulrich


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

wxSQLite (relevant part) and SEE are extensions to SQLite. 

wxSQLite is free, while SEE is definitively not.

wxSQLite means "pseudo" encryption (as formerly discussed), while SEE is real 
encryption.

What is weird???

Regards,
Etienne


- Original message -
From: Paolo Bolzoni <paolo.bolzoni.br...@gmail.com>
To: General Discussion of SQLite Database <sqlite-users@sqlite.org>
Subject: Re: [sqlite] to encrypt sqlite db
Date: Sun, 1 Sep 2013 18:24:13 +0200

Another weird sentence in the mailing list
of probably most used DB that is really free.

On Sun, Sep 1, 2013 at 6:10 PM, Etienne <etienne.sql...@mailnull.com> wrote:
> On Sun, Sep 1, 2013, at 17:50, Clemens Ladisch wrote:
>> Ulrich Telle wrote:
>> > Am 31.08.2013 22:01, schrieb Etienne:
>> >> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
>> >> salts:
>> >
>> > Well, that's not completely true. The encryption extension coming with
>> > wxSQLite3 uses a different IV (initial vector) for each database page.
>> > True is that the IVs are not random, but deduced from the page number.
>> > However, I don't see much difference between generating an IV
>> > algorithmic or using a random nonce which is stored at the end of each
>> > database page
>>
>> <http://en.wikipedia.org/wiki/Initialization_vector> says:
>> | Randomization is crucial for encryption schemes to achieve semantic
>> | security, a property whereby repeated usage of the scheme under the
>> | same key does not allow an attacker to infer relationships between
>> | segments of the encrypted message.
>>
>> Without a random IV/nonce, every page is guaranteed to encrypt to the
>> same data if the contents and the key have not changed.  Thus, wxSQLite3
>> gives an attacker the ability to determine whether any particular page
>> has changed, by comparing the old and new versions.  With SEE, rewriting
>> a page will encrypt to a different value because the IV changes even for
>> otherwise unchanged pages.
>>
>> > The weak point of probably all SQLite encryption methods is that the
>> > unencrypted content of the first 16 bytes of a SQLite database file is
>> > well known.
>>
>> Many file formats have fixed parts.  However, this is not a problem with
>> properly implemented encryption algorithms.
>>
>> Regards,
>> Clemens
>
> Amen.
>
> In this particular case, you get what you pay for.
>
> Regards,
> Etienne
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Paolo Bolzoni]

Another weird sentence in the mailing list
of probably most used DB that is really free.

On Sun, Sep 1, 2013 at 6:10 PM, Etienne  wrote:
> On Sun, Sep 1, 2013, at 17:50, Clemens Ladisch wrote:
>> Ulrich Telle wrote:
>> > Am 31.08.2013 22:01, schrieb Etienne:
>> >> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
>> >> salts:
>> >
>> > Well, that's not completely true. The encryption extension coming with
>> > wxSQLite3 uses a different IV (initial vector) for each database page.
>> > True is that the IVs are not random, but deduced from the page number.
>> > However, I don't see much difference between generating an IV
>> > algorithmic or using a random nonce which is stored at the end of each
>> > database page
>>
>>  says:
>> | Randomization is crucial for encryption schemes to achieve semantic
>> | security, a property whereby repeated usage of the scheme under the
>> | same key does not allow an attacker to infer relationships between
>> | segments of the encrypted message.
>>
>> Without a random IV/nonce, every page is guaranteed to encrypt to the
>> same data if the contents and the key have not changed.  Thus, wxSQLite3
>> gives an attacker the ability to determine whether any particular page
>> has changed, by comparing the old and new versions.  With SEE, rewriting
>> a page will encrypt to a different value because the IV changes even for
>> otherwise unchanged pages.
>>
>> > The weak point of probably all SQLite encryption methods is that the
>> > unencrypted content of the first 16 bytes of a SQLite database file is
>> > well known.
>>
>> Many file formats have fixed parts.  However, this is not a problem with
>> properly implemented encryption algorithms.
>>
>> Regards,
>> Clemens
>
> Amen.
>
> In this particular case, you get what you pay for.
>
> Regards,
> Etienne
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

On Sun, Sep 1, 2013, at 17:50, Clemens Ladisch wrote:
> Ulrich Telle wrote:
> > Am 31.08.2013 22:01, schrieb Etienne:
> >> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
> >> salts:
> >
> > Well, that's not completely true. The encryption extension coming with
> > wxSQLite3 uses a different IV (initial vector) for each database page.
> > True is that the IVs are not random, but deduced from the page number.
> > However, I don't see much difference between generating an IV
> > algorithmic or using a random nonce which is stored at the end of each
> > database page
> 
>  says:
> | Randomization is crucial for encryption schemes to achieve semantic
> | security, a property whereby repeated usage of the scheme under the
> | same key does not allow an attacker to infer relationships between
> | segments of the encrypted message.
> 
> Without a random IV/nonce, every page is guaranteed to encrypt to the
> same data if the contents and the key have not changed.  Thus, wxSQLite3
> gives an attacker the ability to determine whether any particular page
> has changed, by comparing the old and new versions.  With SEE, rewriting
> a page will encrypt to a different value because the IV changes even for
> otherwise unchanged pages.
> 
> > The weak point of probably all SQLite encryption methods is that the
> > unencrypted content of the first 16 bytes of a SQLite database file is
> > well known.
> 
> Many file formats have fixed parts.  However, this is not a problem with
> properly implemented encryption algorithms.
> 
> Regards,
> Clemens

Amen.

In this particular case, you get what you pay for.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Clemens Ladisch]

Ulrich Telle wrote:
> Am 31.08.2013 22:01, schrieb Etienne:
>> I simply wanted to warn the OP that wxSQLite, while free, does NOT use
>> salts:
>
> Well, that's not completely true. The encryption extension coming with
> wxSQLite3 uses a different IV (initial vector) for each database page.
> True is that the IVs are not random, but deduced from the page number.
> However, I don't see much difference between generating an IV
> algorithmic or using a random nonce which is stored at the end of each
> database page

 says:
| Randomization is crucial for encryption schemes to achieve semantic
| security, a property whereby repeated usage of the scheme under the
| same key does not allow an attacker to infer relationships between
| segments of the encrypted message.

Without a random IV/nonce, every page is guaranteed to encrypt to the
same data if the contents and the key have not changed.  Thus, wxSQLite3
gives an attacker the ability to determine whether any particular page
has changed, by comparing the old and new versions.  With SEE, rewriting
a page will encrypt to a different value because the IV changes even for
otherwise unchanged pages.

> The weak point of probably all SQLite encryption methods is that the
> unencrypted content of the first 16 bytes of a SQLite database file is
> well known.

Many file formats have fixed parts.  However, this is not a problem with
properly implemented encryption algorithms.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Mohit Sindhwani]

On 31/8/2013 9:52 PM, dd wrote:

Thank you for your quick response.

I am looking for freeware. If freeware not available, I have to implement
encryption support for sqlite on winrt.

What is the procedure to implement encryption support on winrt?

Thanks,
dd


Many others have replied with the couple of other known alternatives.  
Frankly, I find this insistence on "freeware" a bit flawed unless you 
plan to open source the final solution and want something that offers 
you a license to do so.  Assuming you get paid at least US$500 per 
month, I think you'll find that the solutions will be cheaper than 
actually implementing it yourself.  I am confident that you'll spend at 
least 4 man months to convince management, search other alternatives, 
figure out how encryption works, design a solution that works within 
SQLite, create tools for building the encrypted database, create code 
for querying the encrypted database, test the solution works well for 
you and then document it for other devs to use.  Instead of that, a 
US$2000 solution that is royalty free and can be used on any number of 
projects (as long as they are built at the same site IIRC), is a "steal".


On the other hand, maybe, your requirements are dead simple.  What do 
you want as "encryption support"?  Something that encrypts the full 
file, the content in some of the fields/ tables, or something that also 
supports querying such a database?  I don't think that the last one is 
quite that straightforward.  I would recommend you sit down someone from 
management and explain to them that what the cost tradeoffs are.


Best Regards,
Mohit.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Ulrich Telle]

Am 31.08.2013 22:01, schrieb Etienne:

  On Sat, 31 Aug 2013 17:17:23 +0200
  Etienne  wrote:

  > > On the other hand removing patterns definitely cannot hurt.
  >
  > Precisely.
  >
  > The very first bytes of SQLite files are, AFAIK, well known.

  That's what salt is for, no?


"nonce", "IV", "salt" - call it whatever you want.  Yes.


I simply wanted to warn the OP that wxSQLite, while free, does NOT use
salts:


Well, that's not completely true. The encryption extension coming with 
wxSQLite3 uses a different IV (initial vector) for each database page. 
True is that the IVs are not random, but deduced from the page number. 
However, I don't see much difference between generating an IV 
algorithmic or using a random nonce which is stored at the end of each 
database page as SEE does according to the documentation to be found 
here: http://www.sqlite.org/see/doc/trunk/www/readme.wiki


In both cases you know the IV - at least if you have access to the code 
generating it (which is the case for wxSQLite3 as it is open source, but 
not for SEE as it is closed source).


The weak point of probably all SQLite encryption methods is that the 
unencrypted content of the first 16 bytes of a SQLite database file is 
well known. To get a better encryption maybe the first 16 bytes should 
always be kept unencrypted to not give a clue to a known pattern.



2 SQLite DBs built exactly the same way at different times are
byte-to-byte identical.


That's true. However, in real life it probably matters only for 
read-only databases. As soon as different people start to work with such 
an encrypted database, the database files will certainly deviate from 
each other considerably as it is very unlikely that all users perform 
their actions in exactly the same order.


BTW, you only get identical database files if you use the same 
passphrase. If the passphrase is hardcoded into the software then 
certainly this may impose a problem. However, for an application with 
high security demands you certainly shouldn't hardcode the passphrase 
into the software.


Regards,

Ulrich


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[j . merrill]

If Windows RT supports the "encrypted files and folders" option of the NTFS 
file system -- I could not find anything that said explicitly that it either 
was or was not supported, and I don't have a Windows RT device to test with -- 
that would definitely be the way to go. It would require only the effort to 
turn on the encryption feature for the database file (or the directory holding 
multiple database files).

It's appropriate to always ask the question "what is the motivation for 
encrypting the database?"

If the reason is to prevent someone who steals the device from easily reading 
the data file (for example after removing or copying the hard drive), consider 
that someone who steals the device could run whatever installed software that's 
designed to be able to read/write the database. You would need to prevent them 
from being able to do that, otherwise the encryption would not be very useful.

[quoted message from Paolo Bolzoni]
Date: Sat, 31 Aug 2013 14:40:19 +0200
From: Paolo Bolzoni <paolo.bolzoni.br...@gmail.com>
Subject: Re: [sqlite] to encrypt sqlite db
Message-ID:  
<cao4loozq1wr_ovnbh4wtfqupbjyd+pxr1rhpthcxv9nc8n8...@mail.gmail.com>

There is a non-free version of sqlite that
encrypt the db. If it is that you want then
you have to contact them directly.

Otherwise just use sqlite on a EncFs mounted
disk?

On Sat, Aug 31, 2013 at 2:25 PM, dd <durga.d...@gmail.com> wrote:
> Hi All,
>
>   I have to encrypt sqlite database on winrt.
>
>   What are all the necessary steps to do to encrypt sqlite database?
>
>   Thanks in advance.
>
> Regards,
[end of quoted message from Paolo Bolzoni]

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Mikael]

Wait, can you clarify what you mean by SEE here, and also which library you
mean for BW?

Thanks


2013/8/31 Etienne 

> > Those first few bytes are just as well known after they have been run
> > through zlib or libbz2 or whatever compression library you are using.
> Your
> > encryption algorithm, whatever it is, needs to be resistant to a
> > known-plaintext attack.
>
> LZ is a sequential algorithm, while BW works with large blocks of data.
>
> > SEE uses a random IV or nonce on each page.
>
> Exactly the reason why I would recommend SEE over wxSQLite for paranoiac
> usage.
>
> I did mention WXSQLite because the OP is looking for a free solution.
>
> Regards,
> Etienne
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

> >  On Sat, 31 Aug 2013 17:17:23 +0200
> >  Etienne  wrote:
> > 
> >  > > On the other hand removing patterns definitely cannot hurt.
> >  >
> >  > Precisely.
> >  >
> >  > The very first bytes of SQLite files are, AFAIK, well known.
> > 
> >  That's what salt is for, no?
> > 
> "nonce", "IV", "salt" - call it whatever you want.  Yes.

I simply wanted to warn the OP that wxSQLite, while free, does NOT use
salts: 2 SQLite DBs built exactly the same way at different times are
byte-to-byte identical.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Richard Hipp]

On Sat, Aug 31, 2013 at 1:10 PM, James K. Lowden
wrote:

> On Sat, 31 Aug 2013 17:17:23 +0200
> Etienne  wrote:
>
> > > On the other hand removing patterns definitely cannot hurt.
> >
> > Precisely.
> >
> > The very first bytes of SQLite files are, AFAIK, well known.
>
> That's what salt is for, no?
>
>
"nonce", "IV", "salt" - call it whatever you want.  Yes.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[James K. Lowden]

On Sat, 31 Aug 2013 17:17:23 +0200
Etienne  wrote:

> > On the other hand removing patterns definitely cannot hurt.
> 
> Precisely.
> 
> The very first bytes of SQLite files are, AFAIK, well known. 

That's what salt is for, no?  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

> Those first few bytes are just as well known after they have been run
> through zlib or libbz2 or whatever compression library you are using.  Your
> encryption algorithm, whatever it is, needs to be resistant to a
> known-plaintext attack.

LZ is a sequential algorithm, while BW works with large blocks of data.

> SEE uses a random IV or nonce on each page.

Exactly the reason why I would recommend SEE over wxSQLite for paranoiac usage.

I did mention WXSQLite because the OP is looking for a free solution.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Richard Hipp]

On Sat, Aug 31, 2013 at 11:17 AM, Etienne wrote:

>
> The very first bytes of SQLite files are, AFAIK, well known.
>

Those first few bytes are just as well known after they have been run
through zlib or libbz2 or whatever compression library you are using.  Your
encryption algorithm, whatever it is, needs to be resistant to a
known-plaintext attack.

SEE uses a random IV or nonce on each page.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

> That last sentence is quite weird, a good encryption system should
> give a random-like sequence even with very low-entropy input.
> 
> On the other hand removing patterns definitely cannot hurt.

Precisely.

The very first bytes of SQLite files are, AFAIK, well known. 

While "encryption-only" practice might be enough to discourage an average user, 
it would probably not resist to a determined hacker... just my $0.02.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Paolo Bolzoni]

That last sentence is quite weird, a good encryption system should
give a random-like sequence even with very low-entropy input.

On the other hand removing patterns definitely cannot hurt.

On Sat, Aug 31, 2013 at 4:38 PM, Etienne  wrote:
>> Thank you for your quick response.
>>
>> I am looking for freeware. If freeware not available, I have to implement
>> encryption support for sqlite on winrt.
>>
>> What is the procedure to implement encryption support on winrt?
>>
>> Thanks,
>> dd
>
>  might help you.
>
> It does supply free AES128/256 encryption (look in /sqlite3/secure/src/).
>
> However, be aware that there is no compression involved here, making (any) 
> encryption significantly weaker.
>
> Regards,
> Etienne
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Etienne]

> Thank you for your quick response.
> 
> I am looking for freeware. If freeware not available, I have to implement
> encryption support for sqlite on winrt.
> 
> What is the procedure to implement encryption support on winrt?
> 
> Thanks,
> dd

 might help you.

It does supply free AES128/256 encryption (look in /sqlite3/secure/src/).

However, be aware that there is no compression involved here, making (any) 
encryption significantly weaker.

Regards,
Etienne

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Eric Sink]

SQLCipher is free.

But it's not compatible with WinRT.

I'm pretty sure that right now there is nothing that meets both of your 
requirements.

--
E


On Aug 31, 2013, at 8:52 AM, dd  wrote:

> Thank you for your quick response.
> 
> I am looking for freeware. If freeware not available, I have to implement
> encryption support for sqlite on winrt.
> 
> What is the procedure to implement encryption support on winrt?
> 
> Thanks,
> dd
> 
> 
> On Sat, Aug 31, 2013 at 6:34 PM, Stephan Beal  wrote:
> 
>> On Sat, Aug 31, 2013 at 2:59 PM, Mohit Sindhwani  wrote:
>> 
>>> Adding on to Paolo's answer, see this: http://www.hwaci.com/sw/**
>>> sqlite/prosupport.html 
>>> See SEE and CEROD on that page.
>> 
>> @devs: minor typo on that page:
>> 
>> "The SQLite software free and it works great."
>> 
>> missing "is"
>> 
>> --
>> - stephan beal
>> http://wanderinghorse.net/home/stephan/
>> http://gplus.to/sgbeal
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[dd]

Thank you for your quick response.

I am looking for freeware. If freeware not available, I have to implement
encryption support for sqlite on winrt.

What is the procedure to implement encryption support on winrt?

Thanks,
dd


On Sat, Aug 31, 2013 at 6:34 PM, Stephan Beal  wrote:

> On Sat, Aug 31, 2013 at 2:59 PM, Mohit Sindhwani  wrote:
>
> > Adding on to Paolo's answer, see this: http://www.hwaci.com/sw/**
> > sqlite/prosupport.html 
> > See SEE and CEROD on that page.
> >
>
> @devs: minor typo on that page:
>
> "The SQLite software free and it works great."
>
> missing "is"
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Stephan Beal]

On Sat, Aug 31, 2013 at 2:59 PM, Mohit Sindhwani  wrote:

> Adding on to Paolo's answer, see this: http://www.hwaci.com/sw/**
> sqlite/prosupport.html 
> See SEE and CEROD on that page.
>

@devs: minor typo on that page:

"The SQLite software free and it works great."

missing "is"

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Mohit Sindhwani]

On 31/8/2013 8:40 PM, Paolo Bolzoni wrote:

There is a non-free version of sqlite that
encrypt the db. If it is that you want then
you have to contact them directly.

Otherwise just use sqlite on a EncFs mounted
disk?



Adding on to Paolo's answer, see this: 
http://www.hwaci.com/sw/sqlite/prosupport.html

See SEE and CEROD on that page.

Best Regards,
Mohit.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] to encrypt sqlite db

[Paolo Bolzoni]

There is a non-free version of sqlite that
encrypt the db. If it is that you want then
you have to contact them directly.

Otherwise just use sqlite on a EncFs mounted
disk?

On Sat, Aug 31, 2013 at 2:25 PM, dd <durga.d...@gmail.com> wrote:
> Hi All,
>
>   I have to encrypt sqlite database on winrt.
>
>   What are all the necessary steps to do to encrypt sqlite database?
>
>   Thanks in advance.
>
> Regards,
> dd
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] to encrypt sqlite db

[dd]

Hi All,

  I have to encrypt sqlite database on winrt.

  What are all the necessary steps to do to encrypt sqlite database?

  Thanks in advance.

Regards,
dd
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users