Questions about SQLite Encryption Extension (SEE)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Questions about SQLite Encryption Extension (SEE)

Karl Sanders
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
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Richard Hipp-3
On 6/8/17, Karl Sanders <[hidden email]> 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 materializations of views and subqueries?
>

The database file and rollback journal or WAL file are all encrypted.
Actually, in the rollback journal and WAL file, the meta-data is not
encrypted, just the page images that will be written back into the
database.

Transient indexes and materializations of views and subqueries are not
encrypted.  I recommend you set "PRAGMA temp_store=MEMORY" so that
those objects are never written to disk.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

wmertens
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 <[hidden email]> wrote:

> On 6/8/17, Karl Sanders <[hidden email]> 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 materializations of views and subqueries?
> >
>
> The database file and rollback journal or WAL file are all encrypted.
> Actually, in the rollback journal and WAL file, the meta-data is not
> encrypted, just the page images that will be written back into the
> database.
>
> Transient indexes and materializations of views and subqueries are not
> encrypted.  I recommend you set "PRAGMA temp_store=MEMORY" so that
> those objects are never written to disk.
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Richard Hipp-3
On 6/8/17, Wout Mertens <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

wmertens
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 <[hidden email]> wrote:

> On 6/8/17, Wout Mertens <[hidden email]> 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
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Simon Slavin-3


On 8 Jun 2017, at 11:13pm, Wout Mertens <[hidden email]> 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).

Your hope is that the database is held on a server but the decryption key is on the computers users type on.  Or if you have a web-facing setup with multiple servers, your database is on the database computer running PHP and the key is in the JavaScript files on the web server.

But in the long run, physical possession always trumps encryption.  Once they’re in a situation where they can try keys endlessly it’s just a case of how much time and money they’re willing to spend to get access to your data.  Are you a target of the CIA ?  Don’t rely on encryption.  If you’re someone with no money and no interest in politics ?  Then encryption is good at preventing casual theft by bored employees and thieves of opportunity.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Eric Grange
In reply to this post by wmertens
> 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.

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 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.

Eric


On Fri, Jun 9, 2017 at 12:13 AM, Wout Mertens <[hidden email]>
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 <[hidden email]> wrote:
>
> > On 6/8/17, Wout Mertens <[hidden email]> 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
> > [hidden email]
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Questions about SQLite Encryption Extension (SEE)

wmertens
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Yuriy M. Kaminskiy
In reply to this post by Eric Grange
Eric Grange <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> > On 6/8/17, Wout Mertens <[hidden email]> 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
>> > [hidden email]

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Jens Alfke-2
In reply to this post by wmertens

> On Jun 8, 2017, at 3:13 PM, Wout Mertens <[hidden email]> 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) that use encrypted storage, the keys to which are in turn managed by a secure enclave in the CPU and/or derived from user login passphrase.

I believe (but don’t know the details) that on macOS it’s pretty difficult for a process to get access to another process’ address space, even one running as the same user. If this capability is covered by System Integrity Protection, then it would require more than just(!) root access, involving at least a reboot into system recovery mode to turn off SIP; i.e. needing physical access to the machine.

On iOS, processes are completely sandboxed from each other, most of the types of exploits used to get root are unavailable, and  getting any access to a locked or powered-down device is close to impossible, as the FBI found out in the San Bernardino case last year.

In any case, regardless of the technical benefits, there can be legal requirements for app-level encryption, for example apps storing health data which in the US fall under HIPPAA. (It’s actually a bit vague about whether encryption is strictly required, but this tends to be interpreted as “if it’s feasible, encrypt it”: https://www.sookasa.com/resources/HIPAA-encryption/ )

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Jens Alfke-2
In reply to this post by Yuriy M. Kaminskiy

> On Jun 9, 2017, at 7:30 AM, Yuriy M. Kaminskiy <[hidden email]> 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 (and, for AES, often use naive implementation without
> protection against timing/cache attacks),

Hm. The file-encryption code I’ve seen generally delegates the actual crypto primitives to either OpenSSL, libSodium, or an OS-provided subsystem like Apple’s CommonCrypto. I agree that I’d have little trust in a library like this that tried to write its own implementation of AES, etc.

> does not use protected hardware for keeping keys;

Yeah, key management is generally “left as an exercise for the app developer”, who has little knowledge of security. The problem I’ve seen on mobile devices is that app developers will often pass the buck to the user, i.e. deriving the key from a passphrase. The user then has to type the damn passphrase every time they run the app, which heavily incents them to pick something short and trivially-crackable.

This has gotten somewhat better with biometric sensors. On iOS it’s pretty easy to store a key in the Keychain protected by TouchID, which means the key itself resides in the CPU secure enclave, which will only release it when it gets a fingerprint. Not that fingerprints are massively secure, but they’re a lot better than a four-digit PIN, and require physical access to spoof.

(FYI, Apple has an excellent iOS security white-paper that covers all of this stuff in detail.)

> 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).

What do you think of SQLCipher?

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Matthias-Christian Ott
In reply to this post by wmertens
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 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.

When the discussion about DRM and Trusted Computing was more active,
this was widely discussed. Cory Doctorow gave a talk about DRM at
Microsoft that illustrates this misuse of cryptography [1]. Mark Stefik
described a scary vision of DRM over two decades ago [2]. Richard
Stallman has said and written a lot about DRM as well. So perhaps we
should not start another debate on this mailing list and read what has
already been written and said about it at great length.

My personal conclusion from the discussion about DRM and Trusted
Computing is that DRM will never work unless we don't own our computers
but someone else who controls a cryptographic chip in them does.
Unfortunately, this is reality for devices with iOS and other similar
products.

SEE only protects the database if an attacker only has access the
storage medium of the database but not the encryption key. Not more and
not less. You can of course argue about how difficult it is to obtain
the encryption key but has nothing to do with SEE. It depends only
concrete use cases, scenarios and threat models but not SEE. So can we
have the discussion about this on another mailing list?

[1] http://craphound.com/msftdrm.txt
[2]
http://www2.parc.com/istl/groups/uir/publications/items/UIR-1996-10-Stefik-InternetCommerce-IgnitingDreams.pdf
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Rowan Worth-2
In reply to this post by Yuriy M. Kaminskiy
On 9 June 2017 at 22:30, Yuriy M. Kaminskiy <[hidden email]> 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
> processes running under different users (or suid executables).
>

This is generally true, but might not be in the future. The linux kernel
does have an option to limit the processes on which ptrace is effective,
even within processes owned by a specific user. Archlinux at least enables
it by default, I guess time will tell if it sees widespread adoption. I
think it works by allowing ptrace only if invoked by root, or if the target
process is a child of the calling process. I can't find much documentation
on it but here's the arch description:
https://wiki.archlinux.org/index.php/security#ptrace_scope

-Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Yuriy M. Kaminskiy
In reply to this post by Jens Alfke-2
Jens Alfke <[hidden email]> 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).
>
> What do you think of SQLCipher?

Disclaimer: I'm not a real cryptographer ^_^, while I can notice some
outright problematic things, but easily miss others.

From quick overview:

*) they had sense to avoid self-coding crypto primitives, and use
openssl, tomscrypt or (macs?) commoncrypto;
   *) with openssl, they appear to support any cipher supported by
openssl (but they deprecated `PRAGMA cipher` in recent releases, so it
is aes-256-cbc by default);
   *) with other backends, no flexibility at all: only aes-256-cbc
supported;
*) use crypto provider's [strong] random for IV;
*) for (optional) integrity, uses HMAC-SHA1; AFAIK, while SHA1 is
getting more and more broken, HMAC-SHA1 is not broken yet; but it would
be good if they had a plan ahead.
*) don't support AEAD modes (such as AES-{GCM,CCM} or CHACHA20-POLY1305);
*) for kdf, uses PBKDF2-HMAC-SHA1 by default (same: it is not broken
yet, but).
*) don't appear to be able to keep key in system-provided secure
device/enclave;
*) don't appear to be able to easily change passphrase (only by
re-encrypting whole database) or use several passphrases (see LUKS for
comparison).
*) nitpick, but I don't like how they love to constantly re-init cipher
(and hmac) context on reading/writing each page (key setup is not
exactly inexpensive thing; with some cipher [e.g. blowfish], it is
outright SLOW). (And slow crypto is *also* a security problem: if crypto
is expensive, people tends to avoid it).
*) error handling looks problematic in a lot of places (no error
checks, there are memory/resource leaks on error paths).

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Jens Alfke-2

> On Jun 17, 2017, at 7:02 AM, Yuriy M. Kaminskiy <[hidden email]> 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 this on different platforms, and different valid choices even on one platform. So I see this more as an application responsibility.

For example, on iOS you could store the key as a normal Keychain item or put it under Touch ID control, or make the user enter a passphrase. Storing or accessing the key may require user interaction, which means UI code that likely needs to be customized to the application. In some environments you might need to request the key from a key-server. Etc.

> *) error handling looks problematic in a lot of places (no error
> checks, there are memory/resource leaks on error paths).

If you have notes on those, could you share them? It would be good to get those cleaned up. (I don’t work on SQLCipher, but I do work on a library that uses it in some configurations.)

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Questions about SQLite Encryption Extension (SEE)

Yuriy M. Kaminskiy
Jens Alfke <[hidden email]> writes:

>> On Jun 17, 2017, at 7:02 AM, Yuriy M. Kaminskiy <[hidden email]> 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 this on
> different platforms, and different valid choices even on one
> platform.

Sure, this feature is very unlikely to be present for /any/ user-level
file/db encryption.
But totally within scope for system-wide full-disk encryption.

> So I see this more as an application responsibility.
I'm not sure application can do a lot here: if you are going to
perform encryption on user-level, key will be in application memory,
not in security enclave.

[...]
>> *) error handling looks problematic in a lot of places (no error
>> checks, there are memory/resource leaks on error paths).
>
> If you have notes on those, could you share them? It would be good to

Take any openssl function that can return error (e.g. if you specify
PRAGMA cipher=aes-128-gcm, EVP_CipherFinal is expected to always return
error on decryption, as sqlcipher does not provide correct tag [or, more
precisely, *any* tag]).
There are no check for this error.

Take sqlcipher_codec_ctx_init:

  if((rc = sqlcipher_cipher_ctx_init(&ctx->read_ctx)) != SQLITE_OK) return rc;
  if((rc = sqlcipher_cipher_ctx_init(&ctx->write_ctx)) != SQLITE_OK) return rc;
 
Suppose, first sqlcipher_cipher_ctx_init succeed, but second failed.
Who is going to release ctx->read_ctx (and ctx itself)?
And a lot more similar things.

Sure, nothing *terrible serious* (it is leak on error path, likely only
possible on OOM, so program state is rather fragile and most likely will
crash or terminate anyway), but still shows that hardly anyone seriously
reviewed code.

> get those cleaned up. (I don’t work on SQLCipher, but I do work on a
> library that uses it in some configurations.)

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...