You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Sunitha Kambhampati <sk...@Yngvi.Org> on 2004/10/19 00:36:00 UTC
Regarding Derby42 : Do not store the encryption key length and the
encryption block size in service.properties:
Do not store the encryption key length and the encryption block size in
service.properties for encrypted database when external key is used.
Regarding fix for derby 42
(http://nagoya.apache.org/jira/browse/DERBY-42 ):
1)The encryption key length is used only for error checking and the fix
to not store this information is OK and simple. Also attached is patch
to fix this first part .
2)However removing the encryption block size property is little more
involved:
Currently, the encryption block size is obtained during creation of the
encrypted database and stored in service.properties. On subsequent
connections, this stored value is used for padding of logs.
One of the reason for storing this block size is because Cipher class
description suggests that the getBlockSize() returns the default block
size. Thus it is likely that the blocksize returned from this api might
change and hence for subsequent connections, the logging system uses the
stored encryption block size to do padding.
But in case of *external key*, if it is decided to remove storing the
encryption block size, then
a) database created with previous versions ( ie before this fix) will
work OK with this fix. No issue with upgrade.
b) database *created* with version that has this fix will not work with
previous versions since the previous version will try to get the
encryption block size from the service.properties and will not find it.
So, because of (b), the fix to remove encryption block size from
service.properties will require the versioning numbers to change, is
that right (?).
Any thoughts/comments
Thanks.
Sunitha.
ps: attached patch fixes the first part of derby42 - do not store the
encryption key length in service properties when external key is used
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Ron Reuben <rr...@Sourcery.Org>.
Samuel Andrew McIntyre wrote:
> Correct, this would be appropriate for a 10.1 or 11.0 release,
> whichever is next for us. I suppose we may want to have a vote on that.
>
> Ron, can we get additional version numbers for targeting bugs in Jira?
> e.g. 10.0.2.1, 10.0.2.2, 10.1.0.0, 11.0.0.0
>
> Thanks,
> andrew
I can definitely add 10.1.0.0 and 11.0.0.0 into Jira and do a "merge" of
bugs once the decision is made. However, in the interest of making it
easy for the user to file a bug, I suggest we first have a vote to
decide the version number.
Also, please provide descriptions for the 10.0.2.1 and 10.0.2.2
releases. I may be able to annotate the version in Jira to avoid user
confusion. If not, I may include these descriptions in the document I
am writing, which explains how to file "good/useful" bugs against Derby.
Thanks.
Ron
Re: Regarding Derby42 : Do not store the encryption key length and the encryption block size in service.properties:
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Oct 18, 2004, at 3:36 PM, Sunitha Kambhampati wrote:
> b) database *created* with version that has this fix will not work
> with previous versions since the previous version will try to get the
> encryption block size from the service.properties and will not find
> it.
>
> So, because of (b), the fix to remove encryption block size from
> service.properties will require the versioning numbers to change, is
> that right (?).
Correct, this would be appropriate for a 10.1 or 11.0 release,
whichever is next for us. I suppose we may want to have a vote on that.
Ron, can we get additional version numbers for targeting bugs in Jira?
e.g. 10.0.2.1, 10.0.2.2, 10.1.0.0, 11.0.0.0
Thanks,
andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBd/kcDfB0XauCH7wRAkYbAKCciz4rLvL5I31TvLt8dL4G/voCNgCeIRdg
SDlI6MUs0+7j/fcTfLH5K38=
=ZYEg
-----END PGP SIGNATURE-----
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Jan Hlavatý <hl...@code.cz>.
> Then maybe a separate issue for handling the block size. There are two
> issues I see for block size.
Yes, these are separate issues.
> 1) Does having the block size in service.properties compromise the
> security of an ecrypted database in any way? E.g. does it give a clue to
> the key length or algorithm?
Remember that whole security of any secure cryptographic algoritm
lies in the key and the key only. Obscuring algorithm used will not
improve security at all unless you choose a known insecure algorithm.
So, no harm done in showing block size, or even the algorithm type itself.
Block size is completely unrelated to key size.
It is a property of block cipher algorithm itself.
Block sizes are not generally a parameter of the algorithm - they affect
the computation and thus the algoritm itself. You change block size, you get
different algorithm. I'm not aware of any algoritm that would have
several variants with different block sizes referred to with the same name.
It is hard to keep an algorithm secure with variable block size, as the
cryptographic strength of the algorithm may vary with it. So the algorithm
designers prefer to stick to one well tested block size.
> 2) Since default block size is provider specific (from Javadoc for
> Cipher), what does the Derby code do with the block size when an
> encrypted database is booted? Does it request an algorithm with that
> block size?
My Javadoc (JDK5.0) does not say that, and it would not make much sense anyway.
It would mean that different providers would implement different incompatible
algorithms with the same name, which would be a disaster.
Arent you mistaking it with default key size?
>> Currently the java API does not allow a way to request an algorithm
>> with a particular block size.
And for a good reason. There is no such thing.
Jan
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Sunitha Kambhampati <sk...@Yngvi.Org>.
> block size is an inherent value of the
>algorithm, thus if that is true, Derby does not need to store the block
>size at all. Just fetch it each time from the Cipher.getBlockSize() method.
>
>
Thanks Jan and Dan for your input on encryption block size.
This fix for Derby46 removes code to store encryption block size in
service.properties and instead obtains the encryption block size from
Cipher.getBlockSize() for padding purposes.
Although with this fix, there are no upgrade issues; there is a problem
with downgrade of a database created with version that has this fix.
If we take this fix, what this means is-
1) No upgrade problems, so a database *created* with previous versions (
ie before this fix) will work OK with this fix.
2) Downgrade problem: Create a database with version that has this fix
and the encryption block size will not be stored in service.properties.
But a previous engine expects to read the encryption block size from
the service.properties and if it doesnt find the encryption block size
property, defaults to 8 bytes and uses this to do appropriate padding.
Thus a database created with this fix will not necessarily work with
previous engines.
Sunitha.
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sunitha Kambhampati wrote:
>> 2) Since default block size is provider specific (from Javadoc for
>> Cipher), what does the Derby code do with the block size when an
>> encrypted database is booted? Does it request an algorithm with that
>> block size?
Sorry, I was wrong on the provider specific block size, I was confusing
the block size with the processing size in bits talked about in the
overview of the Javadoc for Cipher.
According to this thread, block size is an inherent value of the
algorithm, thus if that is true, Derby does not need to store the block
size at all. Just fetch it each time from the Cipher.getBlockSize() method.
http://forum.java.sun.com/thread.jsp?forum=9&thread=281987
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBdW4IIv0S4qsbfuQRAnlBAJ9b/nDabeE4c5omRGeClPUZ0oIwiQCfRQBt
aK+EI34War6DTd4jWVd+8k4=
=dDd7
-----END PGP SIGNATURE-----
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Sunitha Kambhampati <sk...@Yngvi.Org>.
Daniel John Debrunner wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Sunitha Kambhampati wrote:
>
>
>
>>Do not store the encryption key length and the encryption block size in
>>service.properties for encrypted database when external key is used.
>>
>>Regarding fix for derby 42
>>(http://nagoya.apache.org/jira/browse/DERBY-42 ):
>>1)The encryption key length is used only for error checking and the fix
>>to not store this information is OK and simple. Also attached is patch
>>to fix this first part .
>>
>>2)However removing the encryption block size property is little more
>>involved:
>>Currently, the encryption block size is obtained during creation of the
>>encrypted database and stored in service.properties. On subsequent
>>connections, this stored value is used for padding of logs.
>>
>>
>
>I think that Derby-42 should be just be for removing the key length from
>service.properties. That would then be fixed with your patch.
>
>
>
I agree.
>Then maybe a separate issue for handling the block size. There are two
>issues I see for block size.
>
>1) Does having the block size in service.properties compromise the
>security of an ecrypted database in any way? E.g. does it give a clue to
>the key length or algorithm?
>
>
>
Derby supports block cipher algorithms.
An encryption algorithm is specified as
algorithmName/feedbackMode/Padding.
Having the encryption block size in service.properties does not for sure
indicate the entire algorithm that was used. But it will give hint
towards the algorithm name or atleast to the set of algorithms that
could probably have been used.
As an example : currently Sun JCE implementation of DES , Triple DES,
Blowfish support block sizes of 8 bytes whereas AES requires 16 bytes.
Thus, if an encryption block size stored in service.properties is 8
bytes , then it gives hint that the encryption algorithm is one of the
three (DES or TripleDES or Blowfish).
I am aware of AES algorithm implementations of Sun, that supports 16
bytes block size. Thus if the encryption block size stored is 16, it
gives an hint that the encryption algorithm used was probably AES.
Note, that it still does not give any hints to the entire algorithm used
(ie the feedback mode etc) and also does not give information about the
key length that was used. .
I have tested with Sun JCE and IBM JCE implementations, and the
information above is based on that. If anyone has tested or is aware of
any other implementation of the agorithms, please post to the list.
>2) Since default block size is provider specific (from Javadoc for
>Cipher), what does the Derby code do with the block size when an
>encrypted database is booted? Does it request an algorithm with that
>block size?
>
>
>
Currently the java API does not allow a way to request an algorithm
with a particular block size.
The way the derby code works right now is :
1) on creation of database, the block size is obtained from
Cipher.getBlockSize() and this block size is used for padding purposes.
This block size is then stored in the service.properties.
2) on subsequent boots, the block size that was stored in the
service.properties is used for decrypting as well as encrypting
purposes. This works under the assumption that
* the algorithm implementation will continue to support the block size
that was used when creating the database or else it will throw an
IllegalBlockSizeException exception that will be wrapped in a
StandardException with SQLState.CRYPTO_EXCEPTION.
If in the future, the java api supports a way of requesting an
algorithm with a specific block size, then that code can be added in
derby to request it and use it accordingly.
Sunitha.
>Dan.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.5 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFBdUwcIv0S4qsbfuQRAqNOAJ9vVFnEnMAtRfmeteQupGtA1vLHBACg5kLT
>BAx3mcNhe0md0JvwViIvgO4=
>=qhI3
>-----END PGP SIGNATURE-----
>
>
>
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sunitha Kambhampati wrote:
> Do not store the encryption key length and the encryption block size in
> service.properties for encrypted database when external key is used.
>
> Regarding fix for derby 42
> (http://nagoya.apache.org/jira/browse/DERBY-42 ):
> 1)The encryption key length is used only for error checking and the fix
> to not store this information is OK and simple. Also attached is patch
> to fix this first part .
>
> 2)However removing the encryption block size property is little more
> involved:
> Currently, the encryption block size is obtained during creation of the
> encrypted database and stored in service.properties. On subsequent
> connections, this stored value is used for padding of logs.
I think that Derby-42 should be just be for removing the key length from
service.properties. That would then be fixed with your patch.
Then maybe a separate issue for handling the block size. There are two
issues I see for block size.
1) Does having the block size in service.properties compromise the
security of an ecrypted database in any way? E.g. does it give a clue to
the key length or algorithm?
2) Since default block size is provider specific (from Javadoc for
Cipher), what does the Derby code do with the block size when an
encrypted database is booted? Does it request an algorithm with that
block size?
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBdUwcIv0S4qsbfuQRAqNOAJ9vVFnEnMAtRfmeteQupGtA1vLHBACg5kLT
BAx3mcNhe0md0JvwViIvgO4=
=qhI3
-----END PGP SIGNATURE-----
Re: Regarding Derby42 : Do not store the encryption key length and
the encryption block size in service.properties:
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sunitha Kambhampati wrote:
> Do not store the encryption key length and the encryption block size in
> service.properties for encrypted database when external key is used.
>
> Regarding fix for derby 42
> (http://nagoya.apache.org/jira/browse/DERBY-42 ):
> 1)The encryption key length is used only for error checking and the fix
> to not store this information is OK and simple. Also attached is patch
> to fix this first part .
Patch applied as
Sending
java\engine\org\apache\derby\impl\services\jce\JCECipherFactory.java
Transmitting file data .
Committed revision 55231.
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBd+0PIv0S4qsbfuQRAsEEAKDcHdMXpiaMa0I/tNF4OYWX5+FP4wCg0D/l
+pFW7Su2YN5TUFa+M2MQsII=
=YIcx
-----END PGP SIGNATURE-----