Re: Random Unique alphanumeric generator using Java
On Mon, 6 Dec 2010, Martin Gregorie wrote:
On Mon, 06 Dec 2010 16:26:10 +0000, rossum wrote:
On Mon, 6 Dec 2010 07:41:05 -0800 (PST), Jean-Baptiste Nizet
<jnizet@gmail.com> wrote:
If it's centralized, a random number associated with the sequence number
and stored in database is sufficient for the verification, and safer
than symmetric encryption, since no secret key might be compromized.
Not a random number. You cannot guarantee uniqueness with a random
number. A block cypher is a permutation and so can guarantee uniqueness
for unique inputs. By all means include a random salt in the system
somewhere but it must not affect the uniqueness requirement.
In this case a non-duplicated random number would be good enough provided
that the random number is significantly larger than the sequence number
range it validates.
It would. Both of those approaches are equally good in practice, really.
The counter + cipher approach is more elegant, because it guarantees
non-collision by design, and only requires a single number be stored, not
all the numbers generated so far. I does, however, require more - gasp! -
programming.
Unless you're working in java and trust me, in which case you can just
steal it (see HastyPuddingDemo.java in particular):
http://urchin.earth.li/~twic/Code/HastyPudding/
I'd also consider using Date.getTime() with an added sequence number and
a Luhn check digit as the ticket number. If sale volumes are low enough
to be certain that multiple tickets never be sold with identical Date
values then the sequence number can be omitted. If Luhn check digits are
good enough for credit card account numbers
There are better algorithms:
http://en.wikipedia.org/wiki/Verhoeff_algorithm
I don't know why cards use Luhn instead of Verhoeff (maybe the standard
comes from before it was invented or widely known, or maybe its authors
felt the checksum should be calculable by hand), but there's no reason for
anyone else to do the same.
To be honest, if you're going to compute, you might as well look into
using a 4-bit CRC, and encoding the result in a hex digit. I don't know
that this gives better protection against human error than a Verhoeff
checksum, though.
tom
--
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming