Hacker News Reader

Comment by outsb | Hacker News Reader

Signal's insistence on doing the wrong thing for 99% of users (storing media blobs in SQLite) drives me crazy. Protect our metadata over the wire, fine, but there is almost no additional protective benefit whatsoever by storing the files inside SQLCipher when the user's fingers can be broken one-by-one until they unlock their phone.

Meanwhile it causes issues just like this, not to mention broken integration with every audio/gallery/video app on the device.

View on HN

Accusing them of doing the "wrong thing for 99% of their users" is pretty hyperbolic. They've managed the feat of offering simple, easy E2EE for messages, audio and video calls for one-to-one and groups, without charging anyone a penny for it. Their protocol is so successful it's been adopted by others and is often considered a gold standard.

Having used SQLCipher myself for an app I created, I've often thought about the tradeoffs between security and convenience. I struggle to see how the only benefit to using SQLCipher to encrypt the stored data is to try to protect against someone breaking someone's fingers and forcing someone to give up their password.

Do you not think there are other, much less violent, ways for someone to read an unencrypted database on a phone?

The files on disk are already encrypted (or at least are encryptable: there is a flag the developer can technically turn off), remember, by iOS itself; this is an additional layer of what I'd think really amounts to nothing more than "obfuscation" added by the application (unless the app itself has to be separately unlocked each time you use it--to prevent this key from being stored on disk--which I don't think is true of Signal? or, if it is, is not how that user is clearly using it). The concept of SQLCipher makes the most sense as part of some (evil) defense-in-depth DRM scheme, with the goal of preventing the owner of the phone from getting access to data that is "for developer eyes only", which is how I swear I most often had seen it used. (It is also fine for encrypting data files in transit, or putting passwords on specific files; which, of course, fits perfectly with sqlite being used as an app-specific file format, but that definitely isn't the case for here.)

> The files on disk are already encrypted (or at least are encryptable: there is a flag the developer can technically turn off), remember, by iOS itself;

Just to clarify on this, I had been thinking that the user had to opt into full disk encryption on iOS, does it come enabled by default?

> (unless the app itself has to be separately unlocked each time you use it--to prevent this key from being stored on disk--which I don't think is true of Signal? or, if it is, is not how that user is clearly using it)

At least for the way I use Signal on iOS, the screen can lock and be unlocked by Face ID, but yes, no separate key I have to enter to unlock the SQLCipher database.

So yeah, maybe it doesn't add too much to the current implementation, especially if files are encrypted by default by iOS. If not, then I can see the benefit in adding the "well the device isn't encrypted but at least the Signal files are."

For my case, it was more like this:

> or putting passwords on specific files; which, of course, fits perfectly with sqlite being used as an app-specific file format, but that definitely isn't the case for here.

I built an app for micro-journaling about how I was feeling and I wanted it to be super private, so, at the time, it was local-only and stored the data in a SQLCipher database. The user had to enter a password each time to enter the app and unlock the database, AFAIK, I coded it so the password wasn't stored anywhere.

Yes, the idea was defense in depth, maybe too intense at the time and maybe even less necessary now that more phones seem to have full encryption than they did in 2012-14 when I was making this.

Anyway, I'm grateful for your insight—thank you!

> I had been thinking that the user had to opt into full disk encryption on iOS, does it come enabled by default?

Full disk encryption (called Data Protection on iOS) is enabled as long as a passcode is set. This has been the case since what, iOS 4?

AFAIK the storage is encrypted using (a key derived from) a unique device key in the secure enclave and thus the storage is tied to the physical device. Further keys are generated using the Passphrase and the unique device key, so they are tied to the user and the device.

The application can chose per file:

* Encrypted when locked: NSFileProtectionComplete

* Encrypted until first unlock: NSFileProtectionCompleteUntilFirstUserAuthentication

* Encrypted unless used by the applications background tasks: NSFileProtectionCompleteUnlessOpen

I think the keys used for file encryption are unique per application and then again per file, but I didn’t find information on this.

I appreciate you both providing more info on this. It seems iOS is much more encrypted than I had thought it was. Still, if I resurrect the micro-journaling app, I'll probably keep an app-specific password and SQLCipher to add that extra layer of protection.

Reply on news.ycombinator.com