Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

First, I am no crypto expert although I am doing the MOOC.

I have an item which has as id: uuidv4

When I create this item:

  1. I create a new uuidv4
  2. check if it already exists
  3. and if not, I store it in the db.

Now this item can be deleted. So lets say that there could be a conversation 'about' this item. And in that conversation is stored the id of the-just-deleted-item. After the item has been deleted, the conversation is not automatically deleted. If some user now creates a new item (get new uuidv4) and passes the check-if-already-exists test, it could still reference an already existent conversation. THAT'S WRONG

To battle this, I was thinking of appending a UNIX timestamp (in secs) to the uuidv4 when it is created, then hash that, then store the hash. so the same uuid later on will have a different timestamp, and thus be different!

Question(s): Which hashing algorithm to use?

Or maybe just concatenate the uuidv4 + UNIX timestamp (in secs)?

share|improve this question
up vote 1 down vote accepted

You know, technically an uuidv4 is already designed to be unique. That's what it's for. In other words, the probability of you generating the same uuidv4 is supposed to be virtually zero. So why are you checking for duplicates?

The whole point of uuid's is to make sure nobody ever gets assigned the same one even if they all do their own separate thing without going through a central authority which keeps track of where each uuid is. So if you're using an uuid, it's questionable to expect that you will ever generate the same one twice.

Which leads me to believe that you haven't correctly identified your actual need. Do you need to bind this uuid of the item to the conversation somehow? If so, you want something similar to a deterministic hash of the item name, which will make sure that if you ever delete, say, "Item57", and then eventually add "Item57" back, you will still know which conversations are associated with this item (and no other). This way every item references only the conversations concerning it, even after they are deleted.

If you just need uniqueness and don't want (or care about) dangling references then uuidv4 already provides that, you should trust it rather than cobbling together your own scheme. If you don't trust proven algorithms, how can you ever trust your own?

Briefly, what are you trying to battle against, exactly, from a high level point of view?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.