Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Jens Alfke writes: >> On Jun 17, 2017, at 7:02 AM, Yuriy M. Kaminskiy wrote: >> >> *) don't appear to be able to keep key in system-provided secure >> device/enclave; > > In their defense, I think this is out-of-scope for a cross-platform db > encryption

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

> On Jun 17, 2017, at 7:02 AM, Yuriy M. Kaminskiy wrote: > > *) don't appear to be able to keep key in system-provided secure > device/enclave; In their defense, I think this is out-of-scope for a cross-platform db encryption library, as there are so many different APIs for

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Jens Alfke writes: >> And any non-opensource crypto should be taken with triple caution. Or >> even opensource, but not widely-used or otherwise not known to be >> carefully peer-reviewed (FWIW, I looked at e.g. wxsqlite crypto code, it >> looks not exactly promising too). > >

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 9 June 2017 at 22:30, Yuriy M. Kaminskiy wrote: > > Don't know about windows, but on linux no additional "debug privileges" > needed. You can attach debugger (ptrace syscall) to any process running > with under same user. Additional privileges needed only for debugging >

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 2017-06-09 00:13, Wout Mertens wrote: > Isn't it all just obfuscation? Any root user can read your key, if not from > disk then from memory. Any normal user can't read your key, nor from disk, > nor from memory; and they can't read your db file either. > > So if the adversary is someone with

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

> On Jun 9, 2017, at 7:30 AM, Yuriy M. Kaminskiy wrote: > > On other hand, application-level encryption should be used with great > caution; it is a way too often designed and implemented by > non-cryptographers, does not use optimized or hardware-assisted crypto > primitives

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

> On Jun 8, 2017, at 3:13 PM, Wout Mertens wrote: > > Isn't it all just obfuscation? Any root user can read your key, if not from > disk then from memory. Keys on disk are [or should be!] generally stored by special OS subsystems (like the Keychain on Apple platforms)

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Eric Grange writes: >> Isn't it all just obfuscation? > > Not really, the encryption protects the file, wherever it is, as long as > the attacker does not have access to the application keys or application > memory. > >> If the adversary is another process on the same host,

[sqlite] Questions about SQLite Encryption Extension (SEE)

Aha, that does make sense, thinking of each risk in terms in likelihoods. So encrypting the db as well as the disk seems the safest route here. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

> Isn't it all just obfuscation? Not really, the encryption protects the file, wherever it is, as long as the attacker does not have access to the application keys or application memory. > If the adversary is another process on the same host, encrypting the db > just adds obfuscation, which is

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 8 Jun 2017, at 11:13pm, Wout Mertens wrote: > So if the adversary is someone with access to your disk image, disk > encryption trumps db encryption (unless the disk encryption is vulnerable > to known-plaintext attacks, but I guess they probably apply to sqlite too).

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Isn't it all just obfuscation? Any root user can read your key, if not from disk then from memory. Any normal user can't read your key, nor from disk, nor from memory; and they can't read your db file either. So if the adversary is someone with access to your disk image, disk encryption trumps db

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 6/8/17, Wout Mertens wrote: > Just musing: is an encrypted disk not more reliable? You have to store the > key somewhere… Maybe. I guess it depends on your threat model. Encrypting the whole disk is a system setting,. Anybody who has access to the system can see

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Just musing: is an encrypted disk not more reliable? You have to store the key somewhere… On Thu, Jun 8, 2017, 7:07 PM Richard Hipp wrote: > On 6/8/17, Karl Sanders wrote: > > I would like to know if an encrypted database allows hot backups and > >

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 6/8/17, Karl Sanders wrote: > I would like to know if an encrypted database allows hot backups and > page sizes different from the default one. Yes and Yes. > > Is encryption applied to everything that gets written to disk? > Including transient indices and

[sqlite] Questions about SQLite Encryption Extension (SEE)

I would like to know if an encrypted database allows hot backups and page sizes different from the default one. Is encryption applied to everything that gets written to disk? Including transient indices and materializations of views and subqueries? Regards, Karl