Check out MAXDB [1] (no it's has nothing to do with the regular MySQL stuff - except the name - the engineers are payed by SAP and sit in Berlin). It is solid, scalable, has a decent speed. It has all the enterprise features like triggers etc. and is very easy to administrate and use. It has some nice features like no need for reorgs, no tablespaces (just data files/raw devices in which the tables are stored in) etc.
But I think you can't compare (i) the stacking of encryption algorithms into each other [1] / the iterative usage of encryption algorithms [2] with (ii) the approach of using multiple hash functions independently on the same input [3].
The first two are based on the feeding the output of an algorithm back as input and this might bring side-effects.
But given that [3] uses the algorithms indepdently from each other, I think you have a pretty good chance to lower the risk of collisions (especially if the hashing algorithms you are using are based on different families). Actually even adding algorithms which are weak on their own might nevertheless be beneficial in this combination scheme.
I'am not shure if the paper you are referring to is about the same topic. Actually what jacksonj04 is proposing is to use multiple hash functions independently. This is based on the assumption that it is harder to find a collision that hits for every hash function at the same time *.
Slashdot Mirror
Check out MAXDB [1] (no it's has nothing to do with the regular MySQL stuff - except the name - the engineers are payed by SAP and sit in Berlin). It is solid, scalable, has a decent speed. It has all the enterprise features like triggers etc. and is very easy to administrate and use. It has some nice features like no need for reorgs, no tablespaces (just data files/raw devices in which the tables are stored in) etc.
It is out there as open sources (GPL) since 2000.
[1] http://www.mysql.com/products/maxdb/
But I think you can't compare (i) the stacking of encryption algorithms into each other [1] / the iterative usage of encryption algorithms [2] with (ii) the approach of using multiple hash functions independently on the same input [3].
...
The first two are based on the feeding the output of an algorithm back as input and this might bring side-effects.
But given that [3] uses the algorithms indepdently from each other, I think you have a pretty good chance to lower the risk of collisions (especially if the hashing algorithms you are using are based on different families). Actually even adding algorithms which are weak on their own might nevertheless be beneficial in this combination scheme.
JM2C
[1] Standing for:
ciphertext1 = algorithm2( algorithm1( plaintext1 ) )
[2] Standing for:
ciphertext1 = algorithm1( algorithm1( plaintext1 ) )
[3] Standing for:
hashkey1 = algorithm1( input1 )
hashkey2 = algorithm2( input1 )
I'am not shure if the paper you are referring to is about the same topic. Actually what jacksonj04 is proposing is to use multiple hash functions independently. This is based on the assumption that it is harder to find a collision that hits for every hash function at the same time *.
* standing for:
md5(input1) == md5(input2) && sha1(input1) == sha1(input2)