Age | Commit message (Collapse) | Author |
|
This will need refactoring once we have a proper test for whether the
HSM is initializing after receiving a fresh software load.
|
|
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.
|
|
|
|
|
|
|
|
Temporary nature of null string as key name is not enforced by the
keystore code, it's just a convention to allow callers to generate a
keypair, obtain the public key, hash that to a Subject Key Identifier
(SKI), and rename the key using the SKI as the new name.
This is a compromise to let us use SKI-based key names in PKCS #11
while keeping the keystore code simple.
|
|
|
|
silliness, with a bit of PKCS #1.5 padding silliness for desert.
|
|
are secure (the one in ks_flash.c is a stub, and the others are for
cases where we have no secure hardware in which to store the KEK).
These are primarily for testing, since in the long run the entire
software implementation of AES-keywrap will be replaced by Verilog
which never lets software see the unwrapped key. Or so says current
theory. For the moment, we just need something that will let us test
the rest of the RPC and keystore mechanisms.
|
|
and dispatch.
|
|
committing now so Paul has a chance to look at the current RPC API.
|
|
|
|
public key extraction functions on hold pending ASN.1 cleanup.
|