[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
