theupdateframework
Consider migrating signing to signatory
We are writing our own wrapper around boringssl instead of using ring, so it'd be nice to use our library for signing. One way to implementing this without forcing everyone to use the same crypto library would be to use signatory, which abstracts over a number of different libraries.
Note that Signatory presently supports Ed25519 and ECDSA with NIST P-256 or secp256k1. I'm open to adding other constructions/curves if need be.
I think this is reasonable, but we already have a lot of PRs open for restructuring. You can submit one, but there might be a lot of rebasing. Idk if you want to wait until some of this flurry calms down some.
We are writing our own wrapper around boringssl instead of using ring, so it'd be nice to use our library for signing.
Aren't we using ring already? What is "our library" at the moment?
One way to implementing this without forcing everyone to use the same crypto library would be to use signatory, which abstracts over a number of different libraries.
I'm totally lost, is this proposing to use signatory and get rid of anything that we are doing on our own about signing?
I'm totally new to this code base and struggling a bit around keys and signatures, given that it's not the core business of this project I would expect that it's entirely reusing some other solution. So if this is the proposal, I cannot agree more.
Happy to help with Signatory support. Also note that in addition to YubiHSM2s as hardware-backed key storage, we're working on support for regular YubiKeys here (WIP):
https://github.com/iqlusioninc/yubikey-piv.rs