I'm confused about when the encryptionAlgorithm value is stored
in service.properties, and when it is not.
I did some simple experimentation, and it seems that:
- if I encrypt a database using bootPassword, the value IS
stored in service.properties
- if I encrypt a database using encryptionKey, the value is NOT
stored in service.properties
It also seems that if the value is stored in service.properties,
then I don't have to provide it as an attribute when connecting,
but if the value is not stored in service.properties, then I do
have to provide it as an attribute when connecting.
Furthermore, if the value IS stored in service.properties, and
then I provide a different value for encryptionAlgorithm when
connecting, the database uses the value from service.properties,
NOT the value from the connection URL attributes, which is
confusing (see DERBY-4493).
Further-further-more, it appears that I can add or remove the
value of encryptionAlgorithm to service.properties after the fact.
Here are a few scenarios, with some notes:
a) create with
jdbc:derby:encDB;create=true;dataEncryption=true;
encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768
- encryptionAlgorithm is NOT stored in service.properties
- connect with jdbc:derby:encDB;encryptionKey=6162636465666768
works because encryptionAlgorithm is the default algorithm
- connect with jdbc:derby:encDB;encryptionAlgorithm=Blowfish/CBC/NoPadding;
encryptionKey=6162636465666768 fails because the algorithm is a
mismatch, but the error message says "the given encryption key
does not match the encryption key used when creating the database"
b) create with
jdbc:derby:testdb;create=true;dataEncryption=true;
encryptionAlgorithm=Blowfish/ECB/NoPadding;bootpassword=$ecu...@decanbr@kE0074242
- encryptionAlgorithm IS stored in service.properties
- connect with jdbc:derby:testdb;bootpassword=$ecu...@decanbr@kE0074242
works, because encryption algorithm need not be provided.
- connect with jdbc:derby:testdb;encryptionAlgorithm=DES/CBC/NoPadding;
bootpassword=$ecu...@decanbr@kE0074242 works, which seems wrong,
because it is actually using a *different* encryption algorithm than
the one which was specified in the URL attribute.
c) create with
jdbc:derby:encDB;create=true;dataEncryption=true;
encryptionAlgorithm=Blowfish/ECB/NoPadding;
encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
- encryptionAlgorithm is NOT stored in service.properties
- connect with
jdbc:derby:encDB;encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
fails, because encryptionAlgorithm is not the default, and was not
provided.
- manually edit service.properties to contain
encryptionAlgorithm=Blowfish/ECB/NoPadding
- now connect with
jdbc:derby:encDB;encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
works fine.
d) If I create with a non-default algorithm, using bootPassword, then:
- encryptionAlgorithm is stored in service.properties
- can connect using just bootPassword on connection URL
- if I manually edit service.properties and REMOVE the encryptionAlgorithm,
then I now have to provide the encryptionAlgorithm when connecting.
I'm trying to figure out:
1: if the presence/absence of encryptionAlgorithm in service.properties
is intentional or accidental.
2: if the system intentionally ignores encryptionAlgorithm in the
connection URL when it is already present in service.properties, or
whether it is an accident
3: how best to document the requirements for providing encryptionAlgorithm
at connection time.
I see in http://db.apache.org/derby/binaries/djd_derby_security.pdf
that Dan wrote:
With external key storage no encryption information should appear in file.
But I'm not sure of the reasoning behind that behavior.
I think that the documentation should read:
If you are using a non-default encryptionAlgorithm, and if the
encryptionAlgorithm
value is not specified as a database property in the service.properties file,
then the proper encryptionAlgorithm value must be specified as an attribute
on the connection URL when connecting to the database.
I also think that the system should check if encryptionAlgorithm was provided
in BOTH the connection URL and the service.properties, and complain if they
don't match.
Thanks in advance for any comments or observations.
bryan
