On Thu, Jun 28, 2001 at 08:38:53AM -0400, Michael Bilow wrote:
> On 2001-06-27 at 15:24 +0200, Philipp Meier wrote:
>
> > On Tue, Jun 26, 2001 at 04:14:43PM -0400, Michael Bilow wrote:
>
> I am not sure I understand you at all. If you mean to suggest that the
> primary key could be constructed by concatenating a 64-bit timestamp with
> a 128-bit hash, I suppose that is actually true. However, this would have
> the side effect of making primary keys 196 bits long. Another possibility
> to keep the key at 128 bits would be to use some arbitrary part of the
> hash output, choosing 64 bits of the hash to concatenate with the 64-bit
> timestamp. This, however, would likely INCREASE the probability of
> collision significantly while introducing platform dependence.
Sorry, I re-read my message and think I must have been heavily confused when
I wrote it.
> If, on the other hand, you mean to concatenate the timestamp with the seed
> for the hash, this makes no mathematical difference in the probability of
> collision. The main design goal of a hash, especially a cryptographic
> hash, it to provide fairly wide distribution of outputs with minimally
> different inputs, so there will be essentially no correlation between the
> seeds or initializers and the hash output.
I proposed to concatenate a time stamp and a random pad. Even when the time
resolution java provides is 10ms then the collision probability is reduced
from "probability for 128-Bit id clash in system lifetime" to "probability
for 128-Bit id clash in 10ms".
-billy.
--
Philipp Meier o-matic GmbH
Geschäftsführer Pfarrer-Weiß-Weg 16-18
Tel.: +49-(0)700-66284236 89077 Ulm
PGP signature
