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