On Wed, 22 Apr 2015 20:07:45 +0100
Simon Slavin wrote:
>
> On 22 Apr 2015, at 7:18pm, Scott Hess wrote:
>
> > The only way SQLite can get to the disk is using the vfs, so if the
> > vfs encrypts things, all of the files (main db, temp db, journal,
> > everything) will be encrypted.
>
> Guys.
On Wed, 22 Apr 2015 16:56:07 +0100
Simon Slavin wrote:
> You have made me realise, however, that a nice attack against
> encrypted SQLite databases might be to crash a SQLite application
> while it's processing and examine any journal files, shared memory
> file and temporary index files. It
On 22 Apr 2015, at 9:40pm, John McKown wrote:
> ?only his app has access to this directory,
> so there are no worries about "somebody else" putting files in it. So I am
> _guessing_ that there are files in that directory which need to persist
> between executions of his application.
Correct.
> ?Well, the best that I can think of is to have your application create a
> new, randomly named, directory...
I can't help directly (I don't the innards of SQLite) but can
hopefully clarify what *I* think Simon's asking: he's already said in
his original message that he used to use a temporary
On 22 Apr 2015, at 7:18pm, Scott Hess wrote:
> The only way SQLite can get to the disk is using the vfs, so if the
> vfs encrypts things, all of the files (main db, temp db, journal,
> everything) will be encrypted.
Guys. Guys. Guys. My app doesn't have access to any level below standard
Actually, I assumed SQLite made the duplicates / alternates, it may well
have been the anti-virus doing it. I doubt anything else had a motive
though.
On 2015-04-22 06:20 PM, R.Smith wrote:
>
>
> On 2015-04-22 05:56 PM, Simon Slavin wrote:
>> On 22 Apr 2015, at 4:46pm, Michael Stephenson
>>
On 2015-04-22 05:56 PM, Simon Slavin wrote:
> On 22 Apr 2015, at 4:46pm, Michael Stephenson
> wrote:
>
>> Simon, if the data in the database is sensitive, could you encrypt the
>> database (ala something like https://www.zetetic.net/sqlcipher/)?
> Unfortunately, this doesn't help. I'm not
On 22 Apr 2015, at 4:46pm, Michael Stephenson wrote:
> Simon, if the data in the database is sensitive, could you encrypt the
> database (ala something like https://www.zetetic.net/sqlcipher/)?
Unfortunately, this doesn't help. I'm not concerned with the database file
itself. I know
On Wed, Apr 22, 2015 at 3:50 PM, Simon Slavin wrote:
>
> On 22 Apr 2015, at 9:40pm, John McKown
> wrote:
>
> > ?only his app has access to this directory,
> > so there are no worries about "somebody else" putting files in it. So I
> am
> > _guessing_ that there are files in that directory which
On 22 Apr 2015, at 3:46pm, Jim Callahan
wrote:
> Can you turn off logging and overwrite the database with unencrypted zeros
> or nulls;
> just before deleting it?
The operating system overwrites disks and memory with random bits both just
after it is released and just before it is allocated
On Wed, Apr 22, 2015 at 2:58 PM, Graham Holden
wrote:
>
> > ?Well, the best that I can think of is to have your application create a
> > new, randomly named, directory...
>
> I can't help directly (I don't the innards of SQLite) but can
> hopefully clarify what *I* think Simon's asking: he's
On 22 Apr 2015, at 3:23pm, John McKown wrote:
> If it is
> a POSIX compliant, perhaps what you could do is create a "temporary"
> (mktemp) file of "appropriate" size.
I had never considered that idea. Thank you very much. Unfortunately it won't
work in this situation because the people in
On Wed, 22 Apr 2015 13:50:43 +0100
Simon Slavin wrote:
> Dear folks,
>
> Assuming no hardware/OS faults is it possible for any other
> SQLite-created files to still exist ? Journal ? Temp index ?
> Shared memory ? Anything ?
a) If the app crash, it may create a dump file with sqlite cache
On Wed, Apr 22, 2015 at 12:07 PM, Simon Slavin wrote:
> On 22 Apr 2015, at 7:18pm, Scott Hess wrote:
>> The only way SQLite can get to the disk is using the vfs, so if the
>> vfs encrypts things, all of the files (main db, temp db, journal,
>> everything) will be encrypted.
>
> Guys. Guys.
On Wed, Apr 22, 2015 at 2:07 PM, Simon Slavin wrote:
>
> On 22 Apr 2015, at 7:18pm, Scott Hess wrote:
>
> > The only way SQLite can get to the disk is using the vfs, so if the
> > vfs encrypts things, all of the files (main db, temp db, journal,
> > everything) will be encrypted.
>
> Guys.
On 22 Apr 2015, at 2:07pm, Paul Sanderson
wrote:
> You haven't said what operating system you are using
Sorry, but I can't. However, the OS is strongly oriented towards security
paranoia. As long as the proper OS calls are used to delete files and release
memory, you can assume that they
You haven't said what operating system you are using but I strongly
suspect that there will be plenty of pages from your database thrown
around by the OS itself in various caches/pagefiles etc. all of course
outside of the ability of SQLite to prevent.
Getting at these cached pages is not
Dear folks,
I have a setup where an app creates a single-user SQLite database by opening a
connection, uses it for a number of complicated things, closes the connection,
then deletes the database before quitting. The data which goes into this
database is highly sensitive and it's very
Regarding:
...A nice attack against encrypted SQLite databases might be to crash a
SQLite application while it's processing and examine any journal files,
shared memory file and temporary index files. It might be interesting to
review the various encryption systems widely available for SQLite
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
-- next part --
On 04/22/2015 12:07 PM, Simon Slavin wrote:
> On 22 Apr 2015, at 7:18pm, Scott Hess wrote:
>
>> The only way SQLite can get to the disk is using the vfs, so if the
>> vfs encrypts things, all of the
...@mailinglists.sqlite.org] On Behalf Of John McKown
Sent: Wednesday, April 22, 2015 11:12 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Destroy all evidence of a database
On Wed, Apr 22, 2015 at 9:34 AM, Simon Slavin wrote:
>
> On 22 Apr 2015, at 3:23pm, John McKown
&
The only way SQLite can get to the disk is using the vfs, so if the
vfs encrypts things, all of the files (main db, temp db, journal,
everything) will be encrypted.
I think in your case you can probably even get away without the more
elaborate encrypted systems, because it sounds like you don't
Can you turn off logging and overwrite the database with unencrypted zeros
or nulls;
just before deleting it?
Encrypting the overwrite character(s) would give the encryption attacker a
cleartext -- a bad move right out of the "Imitation Game".
Jim
On Wed, Apr 22, 2015 at 10:34 AM, Simon Slavin
On 4/22/15, Simon Slavin wrote:
> Dear folks,
>
> I have a setup where an app creates a single-user SQLite database by opening
> a connection, uses it for a number of complicated things, closes the
> connection, then deletes the database before quitting. The data which goes
> into this database
On Wed, Apr 22, 2015 at 9:34 AM, Simon Slavin wrote:
>
> On 22 Apr 2015, at 3:23pm, John McKown
> wrote:
>
> > If it is
> > a POSIX compliant, perhaps what you could do is create a "temporary"
> > (mktemp) file of "appropriate" size.
>
> I had never considered that idea. Thank you very much.
On Wed, Apr 22, 2015 at 9:23 AM, John McKown
wrote:
> On Wed, Apr 22, 2015 at 8:14 AM, Simon Slavin
> wrote:
>
>>
>> On 22 Apr 2015, at 2:07pm, Paul Sanderson
>> wrote:
>>
>> > You haven't said what operating system you are using
>>
>> Sorry, but I can't. However, the OS is strongly oriented
On Wed, Apr 22, 2015 at 8:14 AM, Simon Slavin wrote:
>
> On 22 Apr 2015, at 2:07pm, Paul Sanderson
> wrote:
>
> > You haven't said what operating system you are using
>
> Sorry, but I can't. However, the OS is strongly oriented towards security
> paranoia. As long as the proper OS calls are
27 matches
Mail list logo
