When we use the password, does that actually result in a truly encrypted database? Or are we just relying on programs not peeking past the gate, so to speak, when a password is incorrect?
It’s really encrypted. You can test it. Create a small db, insert a text like “I see a password” then look for this text in the DB binary file. Then encrypt it. It should vanish.
1 Like
Outstanding. That’s exactly what I needed to know. Thank you VERY much.
1 Like
If you information is highly secretive, may I suggest encrypting sensitive fields in your database, including the SQLite encryption key itself, as I assume all TLA (three-letter-agencies) can decrypt an encrypted Sqlite database.
1 Like
If they have the technology to decrypt the database I imagine they will be able to decrypt the sensitive fields inside it.
1 Like
The encryption method used within SQLite is a known and unchanging commodity.
How you choose to encrypt your sensitive fields could be one of hundreds of techniques with an unlimited number of pass keys, loops and hashes. So in my experience encrypting fields is way more important than encrypting the file, but do both!
1 Like
SQLite itself doesn’t come with any encryption. That’s either a paid extra (see the SQLite web site), or perhaps Xojo rolled its own.
The Xojo SQLiteDatabase and MBS Xojo SQL Plugin both use SQLite with the official SQLite Encryption Extension (SEE).
1 Like
Var db As New SQLiteDatabase
db.DatabaseFile = SpecialFolder.Desktop.Child("test").Child("plain.sqlite")
db.CreateDatabase
db.ExecuteSQL("CREATE TABLE some_text (pass TEXT); INSERT INTO some_text VALUES ('sensitive data you should not see');")
db.Close
db.DatabaseFile = SpecialFolder.Desktop.Child("test").Child("encrypted.sqlite")
db.EncryptionKey = "locked123"
db.CreateDatabase
db.ExecuteSQL("CREATE TABLE some_text (pass TEXT); INSERT INTO some_text VALUES ('sensitive data you should not see');")
db.Close
Quit
2 Likes
Yes, we use the official SEE extension.
Xojo uses AES-128 encryption by default, but optionally can use AES-256.
A higher grade means a little bit slower access.
https://documentation.xojo.com/api/databases/sqlitedatabase.html#sqlitedatabase-encryptionkey
1 Like
None of what I am dealing with is sensitive enough to warrant very heavy encryption.
I’m pretty sure they could snatch that data in minutes if they absolutely needed to.
My issue is that encryption is very difficult to use for actual files.
So I was thinking BLOB-filled databases could be used to transmit packages of case files.
Not sure about what you want, but…
If your intention is just transmit “a pack of files not easily decrypted” you could just use the new FolderItem.Zip() option the compress and lock with password a zip file containing one or several files. Just use a long password for better locking results ( takes more time from the hackers 
)
1 Like
That’s one option. I like the SQLite option because I can rename it to a custom file type and have the data all split into chunks as BLOB so that people can’t just decrypt. It prevents some file services from discriminating against file types, and is one way around Google’s 400,000 file limit for Drive accounts.
If they could decrypt AES-256, they would. There have been lawsuits over this. That said, when it comes to a SQLite database, the key would need to be stored somewhere in your app. Getting to that key would be significantly more possible than breaking the encryption.
The key itself needs to be encrypted and stored on a server, not with the App. Thus to break your encryption the hacker would need to:
- Break SQLite’s 128 Bit encryption standard
- Read each chunk of your data
- Break into your host database (hard if you’re using a RESTful database so your hosted database is not directly accessible)
- Find the encrypted Key for your file
- Work out what method you encrypted the Key with and use it
- Work out what method you encrypted the SQLite chunk of your data with and use it
- Merge the chunks of your data back into one file
Good luck with that - that’s much harder than sending around some thugs (mafia-style) or threaten to tax-audit you (government-style)!
I am assuming the agency is able to run your software. So pulling the decrypted key from memory would be trivial.
2 Likes
Yes, the downfall of all encryption methods. You can’t stop them, but you don’t have to make it easy!