1
$\begingroup$

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.

$\endgroup$
7
  • $\begingroup$ Welcome to Cryptography.SE. What is the input space of the hash function?, i.e. the ID space. As far as I can see, the collision has no place here so you can use MD5, too. $\endgroup$ – kelalaka May 19 at 19:26
  • $\begingroup$ @kel The input space is 20 base-62 characters, so by my reckoning MD5 would barely be sufficient (by a factor of about ~483). $\endgroup$ – oobayly May 19 at 20:44
  • 1
    $\begingroup$ Well, saying SHA1 is cryptographically insecure is not totally correct. What you need from a hash function is important. For example, the collision has no place for password hashing so one can use SHA-1 there, though there are better alternatives. Why I've asked the input space is due to the short input space is really problematic when using hash functions. If there is no short input space, then the attacker has only the generic pre-image search. $\endgroup$ – kelalaka May 19 at 21:20
  • $\begingroup$ I don't fully understand what your use case is, but it sounds like what you want is to just use the fastest one and truncate it to the length you need. You might be interested in using a non-cryptographic hash; they could be faster. $\endgroup$ – Aman Grewal May 19 at 23:14
  • 2
    $\begingroup$ I'd be careful with a noncryptographical hash function, as that might be weak. To take an extreme, you really wouldn't want to use CRC-128, as it would be fairly easy to rederive the short input from the output. $\endgroup$ – poncho May 20 at 14:01
2
$\begingroup$

(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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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