db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Hlavatý <hla...@code.cz>
Subject Re: Regarding Derby42 : Do not store the encryption key length and the encryption block size in service.properties:
Date Tue, 19 Oct 2004 19:38:53 GMT
> 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.


View raw message