2
$\begingroup$

I've been looking around for any studies done on this topic with respect to memory-hard password hashing. I'm inclined to simply impose no extra overhead by default, to be honest, but I'd really like to know what the industry standard recommendations might be.

$\endgroup$
3
$\begingroup$

If it's for a single user workload (e.g. passphrase to key derivation for encryption / cold storage of private key, local login): explore the largest that's unlikely to cause disk paging or equivalent (including memory compression) on any of the targeted platforms, divide by 2 just in case, and round down to the nearest size parameterizable.

For servers workloads, one wants to comfortably fit the largest fast cache (e.g. L3 if present, or L2) to conserve energy and CPU power; thus: take that cache size, divide by the physical number of threads sharing it (often twice the number of physical CPUs, and rarely more), divide by 2 so that some cache is left, and round down to the nearest size parameterizable. For multi-thread password hashing, that's assuming some parametrization or lock insures there's never more threads password-hashing than there are physical number of threads.

If I had to throw a reasonable number without knowing context, I'd make it 128kiB to err on the functional side (at the expense of not making use of the DRAM on many platforms, thus making security less than it could). I do NOT claim this is an industry standard in any way.

Reasons to choose less: avoid becoming intolerably slow and energy hungry on more platforms.

Reasons to choose more: increase the investment and to a degree operating cost for attackers.

$\endgroup$
1
  • $\begingroup$ Thanks! That seems like a pretty reasonable heuristic. I'll accept that. $\endgroup$ – Sir Galahad Nov 29 '20 at 17:06

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.