On Sat, 11 Jan 2003, Phil Steitz wrote:
> Sorry, missed that. You are correct (also about hashing being a cheap
> way to get randomization).
No, no; just unpredictability.
> An interesting challenge is how to keep the "uniqueness bits" either
> short enough so that the "random bits" give strong unpredictability by
> themselves; or to let the uniqueness bits somehow "contribute" to the
> unpredictability.
Ack; by feeding it into a cryptographic one way function which has a large
enough space; as surmized; 128 bits is propably enough.
> protection" and security. My personal opinion is that the best approach
> is to leave the keys "purely random" and to leave the recently added
> patch to test for duplicates in place.
Ack. In addition I personlly like the scheme where you can 'check' the ID
for validness; i.e. the scheme where you use
ID=hash( counter + secret + hisip ).counter
so you can short circuit naughty people if the hash does not match. As
I've seen many an abuse of this test of duplicates and seen it turned into
a DOS due to too much expensive database work at the back. You can
augement the above by adding the time of issuance, etc.
Dw.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
