Lookups of specific keys are too slow #680
Comments
|
For normal key access it will take 4-5 seconds because it does a lookup by ID for the private key and then for the public key. |
nomis
added a commit
to nomis/SoftHSMv2
that referenced
this issue
Aug 16, 2022
The "true" in the call to Generation::create() in OSToken::OSToken() is used as the umask when it's supposed to be the isToken value (opendnssec#566). Remove the default value from isToken because it's dangerous and there are only two callers. Explicitly pass "true" and "false" for isToken. Failing to consider this a token generation file means that the value is never refreshed for read-only operations. All objects are reloaded from disk every time one of them is refreshed. List operations take a long time because all of the objects are re-read for each object. Fixes opendnssec#680.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The OpenDNSSEC
ods-hsmutil listcommand is extremely slow.First it does a lookup of all private keys using
C_FindObjects*which takes 2-3 seconds because there are over 300 of them.Then it does a lookup of the public key corresponding to each private key using
C_FindObjects*which takes 2-3 seconds per key because it goes through all of the keys again.There doesn't appear to be a better PKCS#11 API for doing this so HSMs must be expected to have faster lookup processes, at least when a specific key ID is provided.
The list command can be improved but key access shouldn't take 2+ seconds.
The text was updated successfully, but these errors were encountered: