SQLite JDBC Driver

This is a library for accessing and creating SQLite database files in Java.

This SQLiteJDBC library requires no configuration since native libraries for major OSs, including Windows, Mac OS X, Linux etc., are assembled into a single JAR (Java Archive) file (the native library is provided by Utelle as part of the SQLite3MultipleCiphers project.

The usage is quite simple; Download the sqlite-jdbc library from Maven Central or from Github Release, then append the library (JAR file) to your class path or use Maven, Gradle.

Table of content

SQLite JDBC Driver

Setup

Supported Operating Systems

The native Sqlite library is compiled and automaticaly tested for the following platforms and OSs:

Operating System / Architecture	x86	x86_64	arm	armv6	armv7	arm64	ppc64
Windows	✅	✅	❌	❌	✅	✅	❌
Mac Os X	❌	✅	❌	❌	❌	❌	❌
Linux Generic	✅	✅	✅	✅	✅	✅	✅
Android	✅	✅	✅	✅	✅	✅	✅

If your os is not listed and you want to use the native library for your OS, build the source from scratch (see the build from scratch section).

Manual Download

Download the latest version of SQLiteJDBC from the Maven Central or from Github Release
Add the downloaded jar to your Java classpath

Maven

If you are familiar with Maven, add the following XML fragments into your pom.xml file. With those settings, your Maven will automatically download our SQLiteJDBC library into your local Maven repository, since our sqlite-jdbc libraries are synchronized with the Maven's central repository.

    <dependency>
      <groupId>io.github.willena</groupId>
      <artifactId>sqlite-jdbc</artifactId>
      <version> version_number </version>
    </dependency>

Gradle

If you are familiar with Gradle, use the following line. This will automatically download the SQLiteJDBC library into your project.

    implementation 'io.github.willena:sqlite-jdbc:version_number'

Configuration

This library is very limited in global configuration settings. You only need to know that it will extracts the native library for your OS to the directory specified by java.io.tmpdir JVM property.

To use another directory, set org.sqlite.tmpdir JVM property to your favorite path.

Build from scratch

See README_BUILD.md file

Usage and examples

Basic usage

Simple example

To open an SQLite database connection from your code, here is an example.

Sample.java

    import java.sql.Connection;
    import java.sql.DriverManager;
    import java.sql.ResultSet;
    import java.sql.SQLException;
    import java.sql.Statement;

    public class Sample
    {
      public static void main(String[] args)
      {
        Connection connection = null;
        try
        {
          // create a database connection
          connection = DriverManager.getConnection("jdbc:sqlite:sample.db");
          Statement statement = connection.createStatement();
          statement.setQueryTimeout(30);  // set timeout to 30 sec.

          statement.executeUpdate("drop table if exists person");
          statement.executeUpdate("create table person (id integer, name string)");
          statement.executeUpdate("insert into person values(1, 'leo')");
          statement.executeUpdate("insert into person values(2, 'yui')");
          ResultSet rs = statement.executeQuery("select * from person");
          while(rs.next())
          {
            // read the result set
            System.out.println("name = " + rs.getString("name"));
            System.out.println("id = " + rs.getInt("id"));
          }
        }
        catch(SQLException e)
        {
          // if the error message is "out of memory",
          // it probably means no database file is found
          System.err.println(e.getMessage());
        }
        finally
        {
          try
          {
            if(connection != null)
              connection.close();
          }
          catch(SQLException e)
          {
            // connection close failed.
            System.err.println(e.getMessage());
          }
        }
      }
    }

Specify database file

Here is an example to establishing a connection to a database file C:\work\mydatabase.db (in Windows)

Connection connection = DriverManager.getConnection("jdbc:sqlite:C:/work/mydatabase.db");

Opening a UNIX (Linux, Mac OS X, etc.) file /home/leo/work/mydatabase.db

Connection connection = DriverManager.getConnection("jdbc:sqlite:/home/leo/work/mydatabase.db");

Special database access

Database files in classpaths or network

To load db files that can be found from the class loader (e.g., db files inside a jar file in the classpath), use jdbc:sqlite::resource: prefix.

For example, here is an example to access an SQLite DB file, sample.db in a Java package org.yourdomain:

Connection conn = DriverManager.getConnection("jdbc:sqlite::resource:org/yourdomain/sample.db");

In addition, external DB resources can be used as follows:

Connection conn = DriverManager.getConnection("jdbc:sqlite::resource:http://www.xerial.org/svn/project/XerialJ/trunk/sqlite-jdbc/src/test/java/org/sqlite/sample.db");

To access db files inside some specific jar file (in local or remote), use the JAR URL:

Connection conn = DriverManager.getConnection("jdbc:sqlite::resource:jar:http://www.xerial.org/svn/project/XerialJ/trunk/sqlite-jdbc/src/test/resources/testdb.jar!/sample.db");

DB files will be extracted to a temporary folder specified in System.getProperty("java.io.tmpdir").

In-memory databases

SQLite supports on-memory database management, which does not create any database files. To use a memory database in your Java code, get the database connection as follows:

Connection connection = DriverManager.getConnection("jdbc:sqlite::memory:");

And also, you can create memory database as follows:

Connection connection = DriverManager.getConnection("jdbc:sqlite:");

Using the restore feature

Take a backup of the whole database to backup.db file:

// Create a memory database
Connection conn = DriverManager.getConnection("jdbc:sqlite:");
Statement stmt = conn.createStatement();
// Do some updates
stmt.executeUpdate("create table sample(id, name)");
stmt.executeUpdate("insert into sample values(1, \"leo\")");
stmt.executeUpdate("insert into sample values(2, \"yui\")");
// Dump the database contents to a file
stmt.executeUpdate("backup to backup.db");
Restore the database from a backup file:
// Create a memory database
Connection conn = DriverManager.getConnection("jdbc:sqlite:");
// Restore the database from a backup file
Statement stat = conn.createStatement();
stat.executeUpdate("restore from backup.db");

Using the Blob datatype

Create a table with a column of blob type: create table T (id integer, data blob)
Create a prepared statement with ? symbol: insert into T values(1, ?)
Prepare a blob data in byte array (e.g., byte[] data = ...)
preparedStatement.setBytes(1, data)
preparedStatement.execute()...

Connection configuration

Using the SQLiteConfig you can configure a number of things. Here is an example.

SQLiteConfig config = new SQLiteConfig();
// config.setReadOnly(true);   
config.setSharedCache(true);
config.recursiveTriggers(true);
// ... other configuration can be set via SQLiteConfig object
Connection conn = DriverManager.getConnection("jdbc:sqlite:sample.db", config.toProperties());

Get started with encryption

The main goal of this library is to allow users to encrypt databases they are producing. In this section we will walk through the main aspect to understand to make this library work correctly with your requierements.

The content of this section is maintly extracted from the WxSQLite3 repository.

Introduction

This library is compiled with a modified SQLite native library that support multiple cipher schemes. In order to be used the user must choose a cipher scheme manually. If not using the default one (at the moment the default cipher is CHACHA20) is applied.

Before applying a configuration, choose the encryption scheme you would like to use in the supported cipher list.

Supported ciphers

Introduction

The following ciphers are currently supported by wxSQLite3:

Full Name	SQL/URI interface name
AES 128 Bit CBC - No HMAC (wxSQLite3)	aes128cbc
AES 256 Bit CBC - No HMAC (wxSQLite3)	aes256cbc
ChaCha20 - Poly1305 HMAC (sqleet)	chacha20
AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC (SQLCipher)	sqlcipher

Definition of abbreviations:

AES = Advanced Encryption Standard (Rijndael algorithm)
CBC = Cipher Block Chaining mode
HMAC = Hash Message Authentication Code
ChaCha20 = symmetric stream cipher developed by Daniel J. Bernstein
Poly1305 = cryptographic message authentication code (MAC) developed by Daniel J. Bernstein
SHA1 = Secure Hash Algorithm 1
SHA256 = Secure Hash Algorithm 2 (256 bit hash)
SHA512 = Secure Hash Algorithm 2 (512 bit hash)

Each of these algorithms can be used with default configuration or configured. Configuration parameters are given below.

AES 128 Bit CBC - No HMAC (wxSQLite3)

This cipher was added to wxSQLite3 in 2007 as the first supported encryption scheme. It is a 128 bit AES encryption in CBC mode.

The encryption key is derived from the passphrase according to the algorithm described in the PDF specification (using the MD5 hash function and the RC4 algorithm).

The initial vector for the encryption of each database page is derived from the page number.

The cipher does not use a HMAC, and requires therefore no reserved bytes per database page.

The following table lists all parameters related to this cipher that can be set before activating database encryption.

Parameter	Default	Min	Max	Description
`legacy`	0	0	1	Boolean flag whether the legacy mode should be used
`legacy_page_size`	0	0	65536	Page size to use in legacy mode, 0 = default SQLite page size

Note: It is not recommended to use legacy mode for encrypting new databases. It is supported for compatibility reasons only, so that databases that were encrypted in legacy mode can be accessed.

AES 256 Bit CBC - No HMAC (wxSQLite3)

This cipher was added to wxSQLite3 in 2010. It is a 256 bit AES encryption in CBC mode.

The encryption key is derived from the passphrase using an SHA256 hash function.

The initial vector for the encryption of each database page is derived from the page number.

The cipher does not use a Hash Message Authentication Code (HMAC), and requires therefore no reserved bytes per database page.

The following table lists all parameters related to this cipher that can be set before activating database encryption.

Parameter	Default	Min	Max	Description
`kdf_iter`	4001	1		Number of iterations for the key derivation function
`legacy`	0	0	1	Boolean flag whether the legacy mode should be used
`legacy_page_size`	0	0	65536	Page size to use in legacy mode, 0 = default SQLite page size

Note: It is not recommended to use legacy mode for encrypting new databases. It is supported for compatibility reasons only, so that databases that were encrypted in legacy mode can be accessed.

ChaCha20 - Poly1305 HMAC (sqleet)

This cipher was introduced for SQLite database encryption by the project sqleet in 2017.

The Internet Engineering Task Force (IETF) officially standardized the cipher algorithm ChaCha20 and the message authentication code Poly1305 in RFC 7905 for Transport Layer Security (TLS).

The new default wxSQLite3 cipher is ChaCha20 - Poly1305.

The encryption key is derived from the passphrase using a random salt (stored in the first 16 bytes of the database file) and the standardized PBKDF2 algorithm with an SHA256 hash function.

One-time keys per database page are derived from the encryption key, the page number, and a 16 bytes nonce. Additionally, a 16 bytes Poly1305 authentication tag per database page is calculated. Therefore this cipher requires 32 reserved bytes per database page.

The following table lists all parameters related to this cipher that can be set before activating database encryption.

Parameter	Default	sqleet	Min	Max	Description
`kdf_iter`	64007	12345	1		Number of iterations for the key derivation function
`legacy`	0	1	0	1	Boolean flag whether the legacy mode should be used
`legacy_page_size`	4096	4096	0	65536	Page size to use in legacy mode, 0 = default SQLite page size

Note: It is not recommended to use legacy mode for encrypting new databases. It is supported for compatibility reasons only, so that databases that were encrypted in legacy mode can be accessed.

AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC (SQLCipher)

SQLCipher was developed by Zetetic LLC and initially released in 2008. It is a 256 bit AES encryption in CBC mode.

The encryption key is derived from the passphrase using a random salt (stored in the first 16 bytes of the database file) and the standardized PBKDF2 algorithm with an SHA1, SHA256, or SHA512 hash function.

A random 16 bytes initial vector (nonce) for the encryption of each database page is used for the AES algorithm. Additionally, an authentication tag per database page is calculated. SQLCipher version 1 used no tag; SQLCipher version 2 to 3 used a 20 bytes SHA1 tag; SQLCipher version 4 uses a 64 bytes SHA512 tag, allowing to optionally choose a 32 bytes SHA256 tag instead. Therefore this cipher requires 16, 48 or 80 reserved bytes per database page (since the number of reserved bytes is rounded to the next multiple of the AES block size of 16 bytes).

The following table lists all parameters related to this cipher that can be set before activating database encryption. The columns labelled v4, v3, v2, and v1 show the parameter values used in legacy SQLCipher versions 3, 2, and 1 respectively. To access databases encrypted with the respective SQLCipher version the listed parameters have to be set explicitly.

Parameter	Default	v4	v3	v2	v1	Min	Max	Description
`kdf_iter`	256000	256000	64000	4000	4000	1		Number of iterations for key derivation
`fast_kdf_iter`	2	2	2	2	2	1		Number of iterations for HMAC key derivation
`hmac_use`	1	1	1	1	0	0	1	Flag whether a HMAC should be used
`hmac_pgno`	1	1	1	1	n/a	0	2	Storage type for page number in HMAC: 0 = native, 1 = little endian, 2 = big endian
`hmac_salt_mask`	0x3a	0x3a	0x3a	0x3a	n/a	0	255	Mask byte for HMAC salt
`legacy`	0	4	3	2	1	0	4	SQLCipher version to be used in legacy mode
`legacy_page_size`	4096	4096	1024	1024	1024	0	65536	Page size to use in legacy mode, 0 = default SQLite page size
`kdf_algorithm`	2	2	0	0	0	0	2	Hash algoritm for key derivation function 0 = SHA1, 1 = SHA256, 2 = SHA512
`hmac_algorithm`	2	2	0	0	0	0	2	Hash algoritm for HMAC calculation 0 = SHA1, 1 = SHA256, 2 = SHA512
`plaintext_header_size`	0	0	n/a	n/a	n/a	0	100	Size of plaintext database header must be multiple of 16, i.e. 32

Note: It is not recommended to use legacy mode for encrypting new databases. It is supported for compatibility reasons only, so that databases that were encrypted in legacy mode can be accessed. However, the default legacy mode for the various SQLCipher versions can be easily set using just the parameter legacy set to the requested version number. That is, all other parameters have to be specified only, if their requested value deviates from the default value.

Note: Version 4 of SQLCipher introduces a new parameter plain_text_header_size to overcome an issue with shared encrypted databases under iOS. If this parameter is set to a non-zero value (like 16 or 32), the corresponding number of bytes at the beginning of the database header are not encrypted allowing iOS to identify the file as a SQLite database file. The drawback of this approach is that the cipher salt used for the key derivation can't be stored in the database header any longer. Therefore it is necessary to retrieve the cipher salt on creating a new database, and to specify the salt on opening an existing database. The cipher salt can be retrieved with the function wxsqlite3_codec_data using parameter cipher_salt, and has to be supplied on opening a database via the database URI parameter cipher_salt.

Configuration methods

Configure using SQLiteMCConfig objects

Starting with version 3.32.0 the java implementation has a new configuration object called SQLiteMCConfig that can hold the cipher configuration. The interface allows for very simple and quick configuration of the choosen cipher algorithm.

For each cipher supported a ready to use and a customizable object is present. If you want to go completely custom it is also possible. All parameters are available through setters.

Each conbinaison of paramters presented in previous section are implemented as getDefault (SQLiteMC default) or getDefautls (ex: getV2Defaults() for SQLCipher))

The object names are :

SQLiteMCConfig; //Super class

SQLiteMCConfig.Builder; Use this to build a configuration object from scratch
    
SQLiteMCSqlCipherConfig; // Generate a configuration for SQLCipher
SQLiteMCChacha20Config; // Generate a configuration for Chacha20
SQLiteMCWxAES256Config; // Generate a configuration for legacy AES 256 WxSQLite3
SQLiteMCWxAES128Config; // Generate a configuration for legacy AES 128 WxSQLite3
SQLiteMCRC4Config; // Generate a configuration for System.Data.SQLite

To specify the key you just need to use the withKey(String Key) of any of the configuration object. To create the connection it is now very simple:

//Using the SQLiteMC default parameters
Connection connection = DriverManager.getConnection("jdbc:sqlite:file:file.db", new SQLiteMCConfig().withKey("Key").toProperties());
Connection connection = new SQLiteMCConfig().withKey("Key").createConnection("jdbc:sqlite:file:file.db");

//Using Chacha20
Connection connection = DriverManager.getConnection("jdbc:sqlite:file:file.db", SQLiteMCChacha20Config.getDefault().withKey("Key").toProperties());
Connection connection = SQLiteMCChacha20Config.getDefault().withKey("Key").createConnection("jdbc:sqlite:file:file.db");

Configure using SQL specific SQL functions

wxSQLite3 additionally defines the sqlite3mc_config() SQL function which can be used to get or set encryption parameters by using SQL queries.

SQL function	Description
`sqlite3mc_config(paramName TEXT)`	Get value of database encryption parameter `paramName`
`sqlite3mc_config(paramName TEXT, newValue)`	Set value of database encryption parameter `paramName` to `newValue`
`sqlite3mc_config(cipherName TEXT, paramName TEXT)`	Get value of cipher `cipherName` encryption parameter `paramName`
`sqlite3mc_config(cipherName TEXT, paramName TEXT, newValue)`	Set value of cipher `cipherName` encryption parameter `paramName` to `newValue`
`sqlite3mc_codec_data(paramName TEXT)`	Get value of parameter `paramName`
`sqlite3mc_codec_data(paramName TEXT, schemaName TEXT)`	Get value of parameter `paramName` from schema `schemaName`

Note: See the supported cipher the list of possible cipherNames.

Note: Calling the configuration functions, the paramName can have a prefix as decribed bellow. sqlite3mc_config() gets or sets encryption parameters which are relevant for the entire database instance. paramName is the name of the parameter which should be get or set. To set a parameter, pass the new parameter value as newValue. To get the current parameter value, pass -1 as newValue.

Parameter names use the following prefixes:

Prefix	Description
no prefix	Get or set the transient parameter value. Transient values are only used once for the next usage of the `key` . Afterwards, the permanent default values will be used again.
`default:`	Get or set the permanent default parameter value. Permanent values will be used during the entire lifetime of the `db` database instance, unless explicitly overridden by a transient value. The initial values for the permanent default values are the compile-time default values.
`min:`	Get the lower bound of the valid parameter value range. This is read-only.
`max:`	Get the upper bound of the valid parameter value range. This is read-only.

The following parameter names are supported for paramName:

Parameter name	Description	Possible values
`cipher`	The cipher to be used for encrypting the database.	`aes128cbc` `aes256cbc` `chacha20` `sqlcipher`
`hmac_check`	Boolean flag whether the HMAC should be validated on read operations for encryption schemes using HMACs	`0` `1`

The return value always is the current parameter value on success, or -1 on failure.

Note: Checking the HMAC on read operations is active by default. With the parameter hmac_check the HMAC check can be disabled in case of trying to recover a corrupted database. It is not recommended to deactivate the HMAC check for regular database operation. Therefore the default can not be changed.

Examples:

-- Get cipher used for the next key or rekey operation
SELECT sqlite3mc_config('cipher');

-- Set cipher used by default for all key and rekey operations
SELECT sqlite3mc_config('default:cipher', 'sqlcipher');

-- Get number of KDF iterations for the AES-256 cipher
SELECT sqlite3mc_config('aes256cbc', 'kdf_iter');

-- Set number of KDF iterations for the AES-256 cipher to 54321
SELECT sqlite3mc_config('aes256cbc', 'kdf_iter', 54321);

-- Activate SQLCipher version 1 encryption scheme for the subsequent key PRAGMA
SELECT sqlite3mc_config('cipher', 'sqlcipher');
SELECT sqlite3mc_config('sqlcipher', 'kdf_iter', 4000);
SELECT sqlite3mc_config('sqlcipher', 'fast_kdf_iter', 2);
SELECT sqlite3mc_config('sqlcipher', 'hmac_use', 0);
SELECT sqlite3mc_config('sqlcipher', 'legacy', 1);
SELECT sqlite3mc_config('sqlcipher', 'legacy_page_size', 1024);
PRAGMA key='<passphrase>';

-- Get the random key salt as a hexadecimal encoded string (if database is encrypted and uses key salt)
SELECT sqlite3mc_codec_data('salt');

Configure using URI

SQLite3 allows to specify database file names as SQLite Uniform Resource Identifiers on opening or attaching databases. The advantage of using a URI file name is that query parameters on the URI can be used to control details of the newly created database connection. The sqlite3mc encryption extension now allows to configure the encryption cipher via URI query parameters.

URI Parameter	Description
`cipher`=cipher name	The `cipher` query parameter specifies which cipher should be used. It has to be the identifier name of one of the supported ciphers.
`key`=passphrase	The `key` query parameter allows to specify the passphrase used to initialize the encryption extension for the database connection. If the query string does not contain a `cipher` parameter, the default cipher selected at compile time is used.
`hexkey`=hex-passphrase	The `hexkey` query parameter allows to specify a hexadecimal encoded passphrase used to initialize the encryption extension for the database connection. If the query string does not contain a `cipher` parameter, the default cipher selected at compile time is used.

Note 1: The URI query parameters key and hexkey are detected and applied by the SQLite3 library itself. If one of them is used and if it is not intended to use the default cipher, then the cipher query parameter and optionally further cipher configuration parameters have to be given in the URI query string as well.

Note 2: The URI query parameters key and hexkey are only respected by SQLite3 on opening a database, but not on attaching a database. To specify the passphrase on attaching a database the keyword KEY of the SQL command ATTACH has to be used.

Depending on the cipher selected via the cipher parameter, additional query parameters can be used to configure the encryption extension. All parameters as described for each supported cipher (like legacy, kdf_iter, and so on) can be used to modify the cipher configuration. Default values are used for all cipher parameters which are not explicitly added to the URI query string. Misspelled parameters are silently ignored.

Note 3: The cipher query parameter is always required, if further query parameters should be used to configure the encryption extension. If this parameter is missing or specifies an unknown cipher, all other cipher configuration parameters are silently ignored, and the default cipher as selected at compile time will be used.

Note 4: On opening a database all cipher configuration parameters given in the URI query string are used to set the default cipher configuration of the database connection. On attaching a database the cipher configuration parameters given in the URI query string will be used for the attached database, but will not change the defaults of the database connection.

Example: URI query string to select the legacy SQLCipher Version 2 encryption scheme:

file:databasefile?cipher=sqlcipher&legacy=1&kdf_iter=4000

Using an encryption key

ASCII

Passing the key to SQLite in order to decrypt the database is quite simple. It can be done using either the SQL syntax or the URI syntax.

Keep in mind that you always need to configure the cipher algorithm before applying the key ! If your key is an ASCII key you can provide it using

PRAGMA key='mykey';

or

file:databasefile?cipher=sqlcipher&legacy=1&kdf_iter=4000&key=mykey

Hex

Passing the hexadecimal version of the key to SQLite in order to decrypt the database is quite simple. It is very handy in case of a binary key. It can be done using either the SQL syntax or the URI syntax.

Keep in mind that you always need to configure the cipher algorithm before applying the key ! If your key is an Hexadecimal key you can provide it using

PRAGMA key="x'myHexKey'";

or

file:databasefile?cipher=sqlcipher&legacy=1&kdf_iter=4000&hexkey=myHexKey

SQLite3 backup API and encryption

When using the SQLite3 backup API to create a backup copy of a SQLite database, the most common case is that source and target database use the same encryption cipher, if any. However, the sqlite3mc multi-cipher encryption extension allows to assign different ciphers to the source and target database.

Problems can arise from the fact that different ciphers may require a different number of reserved bytes per database page. If the number of reserved bytes for the target database is greater than that for the source database, performing a backup via the SQLite3 backup API is unfortunately not possible. In such a case the backup will be aborted.

To allow as many cipher combinations as possible the sqlite3mc multi-cipher encryption extension implements fallback solutions for the most common case where the source database is not encrypted, but a cipher usually requiring a certain number of reserved bytes per database page was selected for the target database. In this case no reserved bytes will be used by the ciphers. The drawback is that the resulting encryption is less secure and that the resulting databases will not be compatible with the corresponding legacy ciphers.

Please find below a table describing with which encryption cipher combinations the backup API can be used.

Backup To	SQLite3	sqlite3mc	sqlite3mc	sqlite3mc	SQLCipher v1	SQLCipher v2+
From	Plain	AES-128	AES-256	ChaCha20 Poly1305	AES-256	AES-256 SHA1
SQLite3 Plain	🆗	🆗	🆗	🆗 ❗	🆗 ❗	🆗 ❗
sqlite3mc AES-128	🆗	🆗	🆗	🆗 ❗	🆗 ❗	🆗 ❗
sqlite3mc AES-256	🆗	🆗	🆗	🆗 ❗	🆗 ❗	🆗 ❗
sqlite3mc ChaCha20 Poly1305	🆗 ^🔻	🆗 ^🔻	🆗 ^🔻	🆗	❌	❌
SQLCipher v1 AES-256	🆗 ^🔻	🆗 ^🔻	🆗 ^🔻	❌	🆗	❌
SQLCipher v2+ AES-256 SHA1	🆗 ^🔻	🆗 ^🔻	🆗 ^🔻	🆗 ^🔻	❌	🆗

Symbol	Description
🆗	Works
❌	Does not work
❗	Works only for non-legacy ciphers with reduced security
^🔻	Keeps reserved bytes per database page

Note: It is strongly recommended to use the same encryption cipher for source and target database.

Encryption key manipulations

Several manipulation can be very usefull when encrypting a database. For example you may want to change the password used, remove it, or encrypt a plain database.

Here is what you need to know.

Encrypt a plain database

Open the database file
Set cipher configuration
Apply the key for the first time using the PRAGMA syntax
Use as usual

Open an encrypted DB

Open the database file
set cipher configuration
Apply the corresponding key using the PRAGMA syntax
Use normally

Change the key used for a database

Open the database file
Set cipher configuration
Apply the current key using the PRAGMA key='mykey' syntax (It needs to be adapted if using an hexadecimal key)
Change the key using the PRAGMA rekey='my_new_key' syntax (It needs to be adapted if using an hexadecimal key)
Use normally

Remove the key and go back to plain

Open the database file
Set cipher configuration
Apply the current key using the PRAGMA key='mykey' syntax (It needs to be adapted if using an hexadecimal key)
Change the key to null usingPRAGMA rekey=''
Use normally

Licenses

Utelle (sqlite3mc)

This project includes parts of the sqlite3mc project witch is licenced under the following licence

Sqlite3mc is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License version 3 or later as published by the Free Software Foundation, with the wxWindows 3.1 exception.

Willena

This project includes modification done by Guillaume VILLENA (Willena) that are under the following licence.

This program follows the Apache License version 2.0 (http://www.apache.org/licenses/ ) That means:

It allows you to:

freely download and use this software, in whole or in part, for personal, company internal, or commercial purposes;
use this software in packages or distributions that you create.

It forbids you to:

redistribute any piece of our originated software without proper attribution;
use any marks owned by us in any way that might state or imply that we xerial.org endorse your distribution;
use any marks owned by us in any way that might state or imply that you created this software in question.

It requires you to:

include a copy of the license in any redistribution you may make that includes this software;
provide clear attribution to us, xerial.org for any distributions that include this software

It does not require you to:

include the source of this software itself, or of any modifications you may have made to it, in any redistribution you may assemble that includes it;
submit changes that you make to the software back to this software (though such feedback is encouraged).

See License FAQ http://www.apache.org/foundation/licence-FAQ.html for more details.

Xerial

This project is based on xerial work and is frequently synchronized with their repository. Here is their Licence.

This program follows the Apache License version 2.0 (http://www.apache.org/licenses/ ) That means:

It allows you to:

freely download and use this software, in whole or in part, for personal, company internal, or commercial purposes;
use this software in packages or distributions that you create.

It forbids you to:

redistribute any piece of our originated software without proper attribution;
use any marks owned by us in any way that might state or imply that we xerial.org endorse your distribution;
use any marks owned by us in any way that might state or imply that you created this software in question.

It requires you to:

include a copy of the license in any redistribution you may make that includes this software;
provide clear attribution to us, xerial.org for any distributions that include this software

It does not require you to:

include the source of this software itself, or of any modifications you may have made to it, in any redistribution you may assemble that includes it;
submit changes that you make to the software back to this software (though such feedback is encouraged).

See License FAQ http://www.apache.org/foundation/licence-FAQ.html for more details.

Name		Name	Last commit message	Last commit date
Latest commit History 1,433 Commits
.github/workflows		.github/workflows
.settings		.settings
archive		archive
demo		demo
docker		docker
lib		lib
scripts		scripts
src		src
.gitignore		.gitignore
.hgignore		.hgignore
LICENSE		LICENSE
LICENSE.zentus		LICENSE.zentus
Makefile		Makefile
Makefile.common		Makefile.common
NOTICE		NOTICE
README.md		README.md
README_BUILD.md		README_BUILD.md
SQLiteJDBC.wiki		SQLiteJDBC.wiki
VERSION		VERSION
amalgamation_version.sh		amalgamation_version.sh
maven-eclipse.xml		maven-eclipse.xml
pom.xml		pom.xml
settings.xml		settings.xml

License

Licenses found

cyw3/sqlite-jdbc-crypt

Folders and files

Latest commit

History

Repository files navigation

SQLite JDBC Driver

Table of content

Setup

Supported Operating Systems

Manual Download

Maven

Gradle

Configuration

Build from scratch

Usage and examples

Basic usage

Simple example

Specify database file

Special database access

Database files in classpaths or network

In-memory databases

Using the restore feature

Using the Blob datatype

Connection configuration

Get started with encryption

Introduction

Supported ciphers

Introduction

AES 128 Bit CBC - No HMAC (wxSQLite3)

AES 256 Bit CBC - No HMAC (wxSQLite3)

ChaCha20 - Poly1305 HMAC (sqleet)

AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC (SQLCipher)

Configuration methods

Configure using SQLiteMCConfig objects

Configure using SQL specific SQL functions

Configure using URI

Using an encryption key

ASCII

Hex

SQLite3 backup API and encryption

Encryption key manipulations

Encrypt a plain database

Open an encrypted DB

Change the key used for a database

Remove the key and go back to plain

Licenses

Utelle (sqlite3mc)

Willena

Xerial

About

Resources

License

Licenses found

Stars

Watchers

Forks

Releases

Packages 0

Languages

Packages