I am glad that you can open AES 128, or AES 256, and so can Xojo.
What are the settings to open a Xojo SQLite encrypted database?
Just to help you with the information that I am exploring, here are some possible settings to be considered with your response for the Cipher setting:
I am trying SQLite Studio to try and open a simple encrypted database. As an example I created a simple table with a few rows of data and created the encrypted SQLite database and saved the file as PasswordEncrypted.sqlite. The password for this test is: MyPassword, and I attempted to open it with aes-128-ofb, and below is a screen grab.
The reason I am asking is that there are many versions of encryption, types, iterations, and page sizes available, and I can’t seem to find anything on the Xojo website. The good news is that I can open the encrypted database with Xojo, but I am unable to open the database with any other editor, I have tried 5 so far.
I don’t believe that Xojo attempted to make a proprietary encryption type, so I am trying to figure out:
How to open a Xojo encrypted SQLite database in a third party SQLite editor
or create Xojo programming to create an encrypted database that is compatible with other programs, so that Xojo is not perceived to have proprietary encryption. Proprietary encryption is not welcomed by businesses.
The attached screen grab attempted AES-128-OFB, and no joy.
The two encryption systems/methods are not compatible.
SQLCipher is an open-source extension/modification to SQLite.
SEE (used by Xojo) is a proprietary extension developed by the same group that created SQLite. https://www.sqlite.org/see/doc/release/www/index.wiki
Thank you Tim. The SQLite manager program was successful at opening the encrypted database! This is great!
In my humble opinion, this is a poor decision for SQLite. When encryption is proprietary (albeit it is available for a cost) then it is not commonly implemented. This is shown by SQLite Manager appears to be one of the very few programs which implements it.
Thanks @jjr, I found this before and although it is helpful when programming a new editor or program, the low number of SQLite editors that have implemented SEE seems that this is not a common practice. Maybe SQLite is hoping that it will be a standard in the future? Not sure what to think. Is implementing SEE just a $2,000 money grab for SQLite? I doubt it, but it was just a thought that crossed my mind when I found the purchasing page here: SQLite Encryption Extension
What I find interesting is the Swift/ObjC which use an Apple supplied SQLIte framework (import SQLite3) doesn’t offer any encyption methods at all. In order to do so, you must bypass their framework and implement some 3rd party one (at the risk of imcompatibily at a later date)
Not sure what you mean by “counter-intuitive”… the included framework is super easy to use, just lacks encryption… which may or may not be considered important, since you have the ability to password secure the entire computer
I am minsunderstanding Dave. Does Swift/Obj C have the ability to natively read/write AES-128-OFB encryption? If the AES-128-OFB algorithm is built-in to Swift/Obj C then it is easy to implement.
If AES-128-OFB is just a library to be imported into Swift/Obj C then this is also easy to implement.
If there are no external libraries to implement AES-128-OFB then this is much more work to write the algorithm and test to make sure it is correct.
No… Swift/ObjC has NO Sqlite encryption methods… it would require the use of SQLCypher or something similar, and this would require either a totally new framework (replacing SQLite3 framework as supplied by Apple, and this is a Swift FRAMEWORK, not just the SQLite installed with macOS or iOS)… or it would require writing a library to use the two frameworks together. I don’t know which of those two is the easiest or most practical.
At this time I have a library based on the supplied Apple Framework that allows the use of SQLite in Swift using syntax almost 100% identical to what Xojo (API1) used