| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
can find tfm.h again.
|
|
control over iterations.
|
|
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.
|
|
|
|
|
|
|
|
|
|
This will need refactoring once we have a proper test for whether the
HSM is initializing after receiving a fresh software load.
|
|
|
|
The KEK (Key Encryption Key) is first fetched from the FPGA that gets it
from the volatile Master Key Memory (that in theory has tamper*kek_len =
len protection with wiping), and secondly from flash.
The flash option is meant for development/evaluation use using an Alpha
board where the Master Key Memory is not battery backed. For any serious
use of an Alpha, an option is to enter the master key into the volatile
MKM on each power-on as a way to unlock the keystore.
|
|
|
|
server library, even if the old makefile (sometimes) did do that.
|
|
|
|
setting.
|
|
|
|
|
|
sizes hsmbully tries.
|
|
store unencrypted public keys (we don't allow this for private keys).
Yet another screwball feature to support PKCS #11, sigh. Anyway,
with this change, mixed-mode builds should work again.
|
|
|
|
|
|
|
|
|
|
|
|
Thanks Rob!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that mixed mode doesn't actually work, because aes_keywrap tries to
hal_io_write to the AES core.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
opcode right.
|
|
|
|
|
