I already read that the default algorithm is 256-bit AES in CBC, but I found no list of other supported algorithms.
I have an existing encrypted database and want to make sure that the used algorithm is supported by SQLCipher before doing the work of integrating it in our project.
Thanks
Hello @Fischiii
The list of possible ciphers would depend on what crypto library was included with the version of SQLCipher you have built. SQLCipher utilizes different crypto libraries depending on the target platform (i.e., OpenSSL, CommonCrypto, libtomcrypt). AES-256 in CBC mode is available across all three of those libraries. Please keep in mind that we have deprecated support for changing ciphers, some crypto providers do not provide a mechanism to change the cipher at runtime. You might consider leaving the default unless you have a specific need to utilize an alternative.
We will use OpenSSL as crypto library. Is cipher switching with that library enabled?
EDIT: typo
@Fischiii - you can switch using openssl. However, its worth noting that the pragma used to do this, PRAMGA cipher, is deprecated. It could be removed in a future release. If I might ask, why do you want to change the cipher used?
We have to connect to an existing already encrypted database. It is aes 128 encrypted.
@Fischiii is the existing database using SQLCipher already? If so, what version? SQLCipher has never used AES-128 as a standard.
No as far as I know it was encrypted using SEE.
@fischiii - OK, thats what I was beginning to suspect. What you want to do will not work. SQLCipher is not at all compatible at a database level with SEE. That is to say, regardless of what cipher is used, you can’t open a SEE database with SQLCipher (or the other way).
Your only option is to try to use SEE to convert the database to a standard non-encrypted database, then use SQLCipher to convert it to a SQLCipher database.
In this case, we would strongly suggest that you just use the default cipher, for the aforementioned reason about the pragma being deprecated.
Thanks for that information. I understand the problem.
Just out of curiosity, what is the technical reason for that incompatibility?
Hi @Fischiii - The two are just not designed to be compatible. It’s conceptually similar to how you couldn’t open a macOS FileVault file system using Microsoft BitLocker. Even though they are both encrypted filesystems, and can both use the same AES-XTS encryption algorithm, the implementation details of the key management, metadata storage, layout, etc. are all different. As a result, while they are comparable technologies, they are not compatible implementations.
SQLCipher uses it’s own specific key derivation operations, database page structures for reserved data and HMACs, etc, as described in our design documentation.
We have never seen or worked with SEE, so I don’t have any direct knowledge of how it works. As a result, I can’t comment on any technical specifics about SEE.
Ok, thanks for making it clear.