| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
Find a suitable core, and mark it busy. Don't forget to release it as soon
as you're done. This has a knock-on effect of un-const'ing core arguments
and struct fields in a lot of places, and it moves some core checks around.
|
|
|
|
can find tfm.h again.
|
|
I can't see protecting the well-known default password against a
brute-force attack, and 100k iterations takes almost a minute, which
makes a terrible first impression.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
whines about some platform-dependent integer size issue, it's best to
use both an explicitly sized format (eg, "%lu") and an explicit cast
(eg, "(unsigned long)") when silencing the warning, otherwise it'll
just pop up again in different form on the next platform tested.
|
|
- TRNG cores are contiguous (but they still have their own mux, so occupy
a block of 16 cores).
- Use Rob's updated libhal in my new apps.
|
|
|
|
|
|
solution is to change to bs=32.
|
|
|
|
Are we having fun yet?
|
|
|
|
utility program, based on Paul's example in the core/platform/novena
repository.
|
