Orbeon Forms community mailing list

Making the uuid more uu

Classic

List

Threaded

3 messages Options

sodastream

Making the uuid more uu

Hi, please correct me if I'm wrong, but it seems the uuid (32-digit hex string) assigned to various items is generated by taking a digest of a 64-bit random number. Occurs in several places, for instance in: src/resources/apps/fr/includes/persistence/persistence-model.xml

This is just a minor detail, but it's been nagging me since I saw it. The digest does not add any randomness to the 64 bits offered by the random number. It's just an expensive way of padding out the random number to 128 bits (32 hex chars). You could pad 16 zeroes and have the same degree of randomness without the digest.

How about throwing in a timestamp before doing the digest? For instance, milliseconds since the epoch. It would make the apparent randomness real.

/Hakan

P.S. It's important that the added quantity is completely independent of the random number.

Erik Bruchez

Re: Making the uuid more uu

Administrator

Hakan,

Are you using 3.9 or 4.x? For reference, you can see the current code
(in 4.x) here under `randomHexId`:

https://github.com/orbeon/orbeon-forms/blob/ef8d24e18390c19687a0b66223173332b28c9ebe/src/main/scala/org/orbeon/oxf/util/SecureUtils.scala#L186

What it does is use Java's `SecureRandom` to get 16 random bytes (128
bits), then hashes that with, by default, SHA1, which takes the size
to 160 bits. Converted to hex, that's in the end 40 characters. We
hash just as an added precaution but `SecureRandom` should be enough
in the first place.

Maybe we should truncate the hashed value to 32 hex characters in all cases.

Does this change anything to your analysis?

-Erik

On Tue, May 21, 2013 at 6:12 AM, sodastream
<[hidden email]> wrote:

> Hi, please correct me if I'm wrong, but it seems the uuid (32-digit hex
> string) assigned to various items is generated by taking a digest of a
> 64-bit random number. Occurs in several places, for instance in:
> src/resources/apps/fr/includes/persistence/persistence-model.xml
>
> This is just a minor detail, but it's been nagging me since I saw it. The
> digest does not add any randomness to the 64 bits offered by the random
> number. It's just an expensive way of padding out the random number to 128
> bits (32 hex chars). You could pad 16 zeroes and have the same degree of
> randomness without the digest.
>
> How about throwing in a timestamp before doing the digest? For instance,
> milliseconds since the epoch. It would make the apparent randomness real.
>
> /Hakan
>
> P.S. It's important that the added quantity is completely independent of the
> random number.
>
> --
> View this message in context: http://discuss.orbeon.com/Making-the-uuid-more-uu-tp4656801.html
> Sent from the Orbeon Forms community mailing list mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].
>
>

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

sodastream

Re: Making the uuid more uu

Hi Erik, it's 3.9, I didn't check 4.x (blush). Of course that's a very adequate solution, happy you took the trouble.

For other people straying into this thread: uuids in 3.9 are very random, in 4.x extremely random. Every grain of sand on the earth could have like billions each and still be unique.

/Hakan

P.S. If you decide to truncate, I think it's best not to do a digest. The digest doesn't add randomness, it's a deterministic calculation. If you truncate the digest you actually take away some of the randomness. At least on Linux SecureRandom uses the OS-provided entropy source /dev/[u]random (by default) and should be quite safe as-is.