Eric Grange <egra...@glscene.org> 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, encrypting the db >> just adds obfuscation, which is security against lazy hackers. > > Another process would need debug privileges to access your application's > memory.
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 processes running under different users (or suid executables). > If you rely on disk encryption primarily, then if that encryption > compromised, or if backups are compromised, or if a root user copies the > wrong files in the wrong places, or just makes any error, then everything > on that disk can be compromised. > With application-level encryption, user error will only compromise that > app's data, and you otherwise need the root user to be the attacker, which > makes the problem quite different from the root user making a mistake. > > Finally in the grand scheme of things, the likelyhood of any disk > encryption being broken (as an implementation) is extremely high, given it > is such a juicy target. And that's why they attract a lot of attention, and any bugs or even traces of weakness were weeded out very long ago. I'm not so sure about semi-closed application-level security solutions, like SEE. All I've seen in public was not very encouraging (somewhat unusual for disk encryption crypto constructs [with one of primitives already considered to be broken], nothing said about KDF, nothing about IV, nothing about design, etc). > And when it is broken, automated tools will be > available for all lazy hackers to download and deploy with a single > click. > > So while you can and should use disk encryption, it can only be seen as an > added security layer, never as a primary security layer. I'd say opposite. System-wide encryption is a must have (*especially*, swap, hibernation and temporary space encryption; there are *nothing* that can be done about that on application-level!). 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 (and, for AES, often use naive implementation without protection against timing/cache attacks), does not use protected hardware for keeping keys; and in general provides very little or no additional security over FDE plus file/directory permissions. 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). > On Fri, Jun 9, 2017 at 12:13 AM, Wout Mertens <wout.mert...@gmail.com> > 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 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). >> >> If the adversary is another process on the same host, encrypting the db >> just adds obfuscation, which is security against lazy hackers. >> >> On Thu, Jun 8, 2017 at 9:04 PM Richard Hipp <d...@sqlite.org> wrote: >> >> > On 6/8/17, Wout Mertens <wout.mert...@gmail.com> 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 everything on disk. You also have to >> > have administrator privileges to set it up. >> > >> > Encrypting a single database file is an application setting. Some >> > applications might want to hide there data from other applications on >> > the same system, or from the user of the system. Whole disk >> > encryption won't help there. And, database encryption requires no >> > special privileges. >> > >> > -- >> > D. Richard Hipp >> > d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
