Issue 115454 - Create encrypted database
Summary: Create encrypted database
Status: UNCONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: DEV300m89
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-07 09:54 UTC by r4zoli
Modified: 2013-02-07 22:36 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description r4zoli 2010-11-07 09:54:51 UTC
After implementing cws hsqldb19, which is changes built-in database hsqldb 1.8.
to 2.0. will became possible to create encrypted database.

I submitted this issue to start discussion, it worth the effort or not.

Some users, raise the encrypted database question, time to time on users forum. 

Details in HSQLDB documentation:
http://hsqldb.org/doc/2.0/guide/guide.html#N13DD7

HyperSQL supports encrypted databases. Encryption services use the Java
Cryptography Extensions (JCE) and uses the ciphers installed with the JRE.
HyperSQL itself does not contain any cryptography code.

Three elements are involved in specifying the encryption method and key. A
cipher, together with its configuration is identified by a string which includes
the name of the cipher and optional parameters. A provider is the fully
qualified class name of the cipher provider. A key is represented as a
hexadecimal string.
Creating and Accessing an Encrypted Database

First, a key must be created for the desired cipher and configuration. This is
done by calling the function CRYPT_KEY(<cipher spec>, <provider>). If the
default provider (the built-in JVM ciphers) is used, then NULL should be
specified as the provider. The CRYPT_KEY function returns a hexadecimal key. The
function call can be made in any HyperSQL database, so long as the provider
class is on the classpath. This key can be used to create a new encrypted
database. Calls to this function always return different keys, based on a
generated random values.

As an example, a call to CRYPT_KEY('Blowfish', null) returned the string,
'604a6105889da65326bf35790a923932'. To create a new database, the URL below is used:

jdbc:hsqldb:file:<database
path>;crypt_key=604a6105889da65326bf35790a923932;crypt_type=blowfish

The third property name is crypt_provider. This is specified only when the
provider is not the default provider.

HyperSQL works with any symmetric cipher that may be available from the JVM.

The files that are encrypted include the .script, .data, .backup and .log files.
The .lobs file is not encrypted by default. The property crypt_lobs=true must be
specified to encrypt the .lobs file.
Speed Considerations

General operations on an encrypted database are performed the same as with any
database. However, some operations are significantly slower than with the
equivalent cleartext database. With MEMORY tables, there is no difference to the
speed of SELECT statements, but data change statements are slower. With CACHED
tables, the speed of all statements is slower.

Security Considerations

Security considerations for encrypted databases have been discussed at length in
HSQLDB discussion groups. Development team members have commented that
encryption is not a panacea for all security needs. The following issues should
be taken into account:

    * Encrypted files are relatively safe in transport, but because databases
contain many repeated values and words, especially known tokens such as CREATE,
INSERT, etc., breaking the encryption of a database may be simpler than an
unknown file.
    * Only the files are encrypted, not the memory image. Poking into computer
memory, while the database is open, will expose the contents of the database.
    * HyperSQL is open source. Someone who has the key, can compile and use a
modified version of the program that saves a full cleartext dump of an encrypted
database

Therefore encryption is generally effective only when the users who have access
to the crypt key are trusted.