Using SHA1 to obfuscate published resource IDs

Question

First off, yes I do know that SHA1 is cryptographically insecure (and has been for a long time). So this question is more academic than anything. It's also very contrived, but bear with me.

I want to publish a table of string IDs with timestamps, but at the same time I don't want somebody to be able to look at the table and use it to enumerate all the resources available.

TmQ5YqqOOPPiEewdntZx  2021-05-05 13:26:38
SVQBu941OWIyDXzSgo2F  2021-05-05 13:26:44
gkxMiz6hEPqV36TidyeG  2021-05-07 09:56:43
vU2OxFFQ4I0gXHGofL8A  2021-05-07 09:56:43

So I can hash the IDs in the table (HMAC is pointless, as the client would need to be aware of the secret used by the table generator):

d3399d662fc58daf44647f188cb6ef30bf76938c    2021-05-05 13:26:38
fc95d2f3af27034ff5a991d5b9a0080cbf45d007    2021-05-05 13:26:44
cd982afcff4ae5e907960f51ae1504a38f4665d1    2021-05-05 13:53:42
e0f31185494f54a3a16ac3483572989f98850c36    2021-05-07 09:56:43

A client, who already knows an ID can hash it, look it up in the public table and check the timestamp. The table should be useless for anyone who doesn't already know an ID.

My thoughts are:

• Even though SHA1 is cryptographically insecure, I'm not using it for verifying the ID, but using it for obfuscation
• Even if somebody can generate a collision, it doesn't give them the ID needed to request the resource
• I don't want to use SHA2 as the shortest hash I can generate is 256 bits, which consumes 60% more storage (imagine I have a lot of them, and I'm very cheap!).

Obvious response will be:

1. Just use SHA2, and it's a valid response. I could just truncate the hash if I'm that concerned about storage space and transfer costs. 160-bits is still a larger address space than 62^20, so collisions are unlikely
2. Just SHA2, it's faster than SHA1. Yes it is, and actually SHA512 is faster than SHA256 (in .Net anyway)
3. Use something else.

If #3, please let me know.

Obviously, I'm going to use SHA2, but is there a cryptographic reason for not using SHA1 (or even MD5 if I was feeling really retro) in this instance. Like I said, the question is mainly academic.

Answer 1

(should I) use something else (than SHA-1)?

Yes. That seems to be a good application of purposely slow hashes intended for password hashing, like Argon2id, or it's ancestor scrypt, or (if all else are unobtainium in the context) SHA-2 followed by bcrypt (don't even google PBKDF2-HMAC-SHA-1, which is obsolete).

These are like SHA-1, less cryptographic break of it's resistance to collision, plus an output size parameter, a plethora of extra inputs for key as HMAC or/and other salt/associated data should that be needed. And most importantly parameters to tune the execution speed; with the whole thing crafted in a way such that adversaries using GPUs or ASICs for brute force search of valid string won't gain so much advantage over using a CPU, as legitimate users do.

This will let you increase security significantly at equal size and number of IDs, or/and safely reduce size of IDs. Just tune the parallelism parameter to the minimum number of physical threads on all platforms using the system (perhaps less 1 or 2 to keep the thing user-responsive, but with a minimum of 1; use 1 if in doubt); memorySizeKB to the lowest free RAM available on all platforms (for all threads, less a fair safety cushion, including for launching the stated number of threads/processes); then up iterations to what's tolerable on all platforms.