At Fri, 23 Dec 2016 22:27:49 +0100, Yuri Schaeffer wrote: > > While having 68 keys 'keystore show keys' enumerates the keys except > after 49 it wraps to 0 again. (But yay for more than 10 objects! which > was kind of a blocker)
Silly bug in show_keys() (code displays index of inner loop instead of a separate "key number" counter -- guess how many blocks of key meta-data the inner loop retrieves at a time?). > The enforcer daemon will not start (blocks, presumably on opening the > HSM) when the signer daemon is running and the other way around. That would be this change: https://wiki.cryptech.is/changeset/0166b1b370862ab34335af3d5710304dc3546499/sw/libhal The RPC mechanism is designed to allow multiplexing of many clients over the same RPC connection, but having multiple clients trying to read and write the same UART without talking to each other ends badly for all concerned. We actually wrote the multiplexer daemon for this before the Berlin workshop, but ended up disabling it because it doesn't run on OSX (it uses PF_UNIX SOCK_SEQPACKET, which OSX doesn't support). Sounds like we ought to dust that off and get it running. > Generating RSA keys works but neither daemon is able to later retrieve > the objects using their locator. So I can't get to the signing part yet. That's surprising. I would have expected something like that to show up in the PKCS #11 unit tests. More details, please, when convenient. > And it seems that every interaction OpenDNSSEC has with the HSM is super > slow. Logging in to the mgmt console is also slow. Like a 10 second > pause after typing in your password. I feel these two are probably related? C_Login() (and the underlying hal_rpc_login() which implements it) are slow, to make brute force attacks on PINs unproductive. Exactly how slow login should be is a good question. The assumption (perhaps incorrect) was that an application logs in once then performs a lot of operations; it sounds like OpenDNSSEC is doing more of a log in once per operation. Advice welcome (hi, Jakob...). > As said, nothing in depth till the new year. But at least some feedback > from me for 2016. Yup. Thanks! _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech