Re: Cheap and unique

[James G Smith <JG...@TAMU.Edu>]

jjore@imation.com wrote:
>I've been following this conversation and I'd like to clarify whether my 
>idea (since I and others want to do this as well) would be use an 
>incrementing counter for uniqueness. Then also store a bit of secret 
>randomness, concatenate both values together and create a digest hash. 
>That hash would be sent along with the sequence as well. This would allow 
>uniqueness and prevent guessing since the digest would have to match as 
>well. Depending on my paranoia I could either get fresh random bits each 
>time (and have a good hardware source for this then) or keep it around for 
>a bit and throw it away after a period.

I think I understand you correctly, but I'm not sure.

You mention the sequence being incremented for uniqueness and the
digest.  I think you propose to send the sequence along with the
digest (the digest containing that bit of randomness along with the
sequence), but you also mention keeping the random bits around for
only a short time, which would indicate they aren't being used to
verify the sequence, but produce the sequence via the hash.

A digest is not unique, especially with the random bit of data thrown
in.  For example, MD5 has 128 bits, but can hash any length string.
There are more than 2^128 strings that MD5 can take to 128 bits.
Therefore, MD5 does not produce a unique value, though it is a
reproducable value (the same input string will always produce the
same output string).  You can replace MD5 with MHX (my hash X) and
the number of bits with some other length and the results are still
the same -- in other words, no hash will give unique results.

The secret string concatenated with the unique number and then hashed
can be used to guarantee that the number has not been tampered with,
but the secret string would need to be constant to be able to catch
tampering.  Otherwise, how can you tell if the hash is correct?
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: Cheap and unique

[Peter Bi <mo...@att.net>]

Does the first email mean to use the incrementing numbers as seeds and then
generate "cool" random numbers from the partly ordered seeds, which will
make them more difficult to guess ?


Peter Bi

----- Original Message -----
From: "James G Smith" <JG...@TAMU.Edu>
To: <jj...@imation.com>
Cc: <mo...@apache.org>
Sent: Monday, May 06, 2002 11:45 AM
Subject: Re: Cheap and unique


> jjore@imation.com wrote:
> >I've been following this conversation and I'd like to clarify whether my
> >idea (since I and others want to do this as well) would be use an
> >incrementing counter for uniqueness. Then also store a bit of secret
> >randomness, concatenate both values together and create a digest hash.
> >That hash would be sent along with the sequence as well. This would allow
> >uniqueness and prevent guessing since the digest would have to match as
> >well. Depending on my paranoia I could either get fresh random bits each
> >time (and have a good hardware source for this then) or keep it around
for
> >a bit and throw it away after a period.
>
> I think I understand you correctly, but I'm not sure.
>
> You mention the sequence being incremented for uniqueness and the
> digest.  I think you propose to send the sequence along with the
> digest (the digest containing that bit of randomness along with the
> sequence), but you also mention keeping the random bits around for
> only a short time, which would indicate they aren't being used to
> verify the sequence, but produce the sequence via the hash.
>
> A digest is not unique, especially with the random bit of data thrown
> in.  For example, MD5 has 128 bits, but can hash any length string.
> There are more than 2^128 strings that MD5 can take to 128 bits.
> Therefore, MD5 does not produce a unique value, though it is a
> reproducable value (the same input string will always produce the
> same output string).  You can replace MD5 with MHX (my hash X) and
> the number of bits with some other length and the results are still
> the same -- in other words, no hash will give unique results.
>
> The secret string concatenated with the unique number and then hashed
> can be used to guarantee that the number has not been tampered with,
> but the secret string would need to be constant to be able to catch
> tampering.  Otherwise, how can you tell if the hash is correct?
> --
> James Smith <JG...@TAMU.Edu>, 979-862-3725
> Texas A&M CIS Operating Systems Group, Unix
>