Lower PBKDF2 password iterations and add delay on bad PIN.

Consistent user complaints about HSM login taking too long.
Underlying issue has both superficial and fundamental causes.

Superficial: Our PBKDF2 implementation is slow.  We could almost
certainly make it faster by taking advantage of partial
pre-calculation (see notes in code) and by reenabling use of FPGA hash
cores when when checking passwords (which mgiht require linking the
bootloader against a separate libhal build to avoid chicken-and-egg
problem of needing FPGA to log into console to configure FPGA).

Fundamental: The PBKDF2 iteration counts we used to use (10,000
minimum, 20,000 default) are in line with current NIST
recommendations.  The new, faster values (1,000 and 2,000,
respectively) are not, or, rather, they're in line with what NIST
recommended a decade ago.  Well, OK, maybe the Coretex M4 is so slow
that it's living in the past, but still.  The fundamental issue is
that anybody who can capture the encoded PIN can mount an offline
dictionary attack on it, so we'd like to make that expensive.

But the users are unhappy with the current behavior, so this change
falls back to the ancient technique of adding a delay (currently five
seconds, configurable at compile time) after a bad PIN, which makes it
painful to use the login function as an oracle but does nothing about
the offline dictionary attack problem.

Feh.

Note that users can still choose a higher iteration count, by setting
the iteration count via the console.  It's just not the default out of
the box anymore.

0 files changed, 0 insertions, 0 deletions