From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com> |
Cc: | Gevik Babakhani <pgdev(at)xs4all(dot)nl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Patch for UUID datatype (beta) |
Date: | 2006-09-18 21:38:24 |
Message-ID: | 1158615504.30652.15.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Mon, 2006-09-18 at 16:00 -0500, Jim C. Nasby wrote:
> BTW, at a former company we used SHA1s to identify files that had been
> uploaded. We were wondering on the odds of 2 different files hashing to
> the same value and found some statistical comparisons of probabilities.
> I don't recall the details, but the odds of duplicating a SHA1 (1 in
> 2^160) are so insanely small that it's hard to find anything in the
> physical world that compares. To duplicate random 256^256 numbers you'd
> probably have to search until the heat-death of the universe.
That assumes you have good random data. Usually there is some kind of
tradeoff between the randomness and the performance. If you
read /dev/random each time, that eliminates some applications that need
to generate UUIDs very quickly. If you use pseudorandom data, you are
vulnerable in the case a clock is set back or the data repeats.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Dunstan | 2006-09-18 21:42:54 | Re: OID conflicts |
Previous Message | Jim C. Nasby | 2006-09-18 21:35:08 | Re: An Idea for OID conflicts |
From | Date | Subject | |
---|---|---|---|
Next Message | Gevik Babakhani | 2006-09-18 22:27:30 | Re: Patch for UUID datatype (beta) |
Previous Message | Neil Conway | 2006-09-18 21:19:51 | Re: cosmetic change in 'drop owned' reference |