Is UUID v3 insecure for generating surrogate keys for APIs since it is based on MD5?

Question

Background: I want to generate surrogate/alternate keys in my database so that I can expose them publicly as my resource identifiers in my API endpoints as follows: GET /resources/{id}

The data in question is a copy of the source-of-truth database and the only identifiers in my copy are sensitive and cannot be exposed in the URL.

So I want to generate a new but reproducible identifier from the existing data and I am considering using UUID v3. (or v5 but I don't see any Java official implementations) Reproducible in the event that my copy has to be recreated, then I can be sure I reproduce the same identifier.

In the event it matters the data is stored in a SQL Server database.

Question: Is UUID v3/5 safe to use in this way since they are based on MD5/SHA-1?

Answer 1

Version 3 is deprecated for a reason. There's no known way (other than brute force) to get from the UUID back to the name, but MD5 does have problems and attacks only get better over time. If the library you're using doesn't support version 5 yet, get one that does.

For both of them, if the amount of data going into the hash is small, then brute force may be a real concern for both versions. The answer to that is to use more input data, i.e. enough that brute force is no longer possible. The exact options will depend on what you have available and how guessable it is