NUT-XX - Mint Remote signer standard #250
Conversation
|
I still need to add test vectors for the key derivation |
change tittle Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
grammar correction Co-authored-by: lollerfirst <43107113+lollerfirst@users.noreply.github.com>
* WIP: Introduce a SignatoryManager service. The SignatoryManager manager provides an API to interact with keysets, private keys, and all key-related operations, offering segregation between the mint and the most sensible part of the mind: the private keys. Although the default signatory runs in memory, it is completely isolated from the rest of the system and can only be communicated through the interface offered by the signatory manager. Only messages can be sent from the mintd to the Signatory trait through the Signatory Manager. This pull request sets the foundation for eventually being able to run the Signatory and all the key-related operations in a separate service, possibly in a foreign service, to offload risks, as described in #476. The Signatory manager is concurrent and deferred any mechanism needed to handle concurrency to the Signatory trait. * Fixed missing default feature for signatory * Do not read keys from the DB * Removed KeysDatabase Trait from MintDatabase All Keys operations should be done through the signatory * Make sure signatory has all the keys in memory Drop also foreign constraints on sqlite * Fix race condition * Adding debug info to failing test * Add `sleep` in test * Fixed issue with active auth keyset * Fixed dependency * Move all keys and keysets to an ArcSwap. Since the keys and keysets exist in RAM, most wrapping functions are infallible and synchronous, improving performance and adding breaking API changes. The signatory will provide this information on the boot and update when the `rotate_keyset` is executed. Todo: Implement a subscription key to reload the keys when the GRPC server changes the keys. For the embedded mode, that makes no sense since there is a single way to rotate keys, and that bit is already covered. * Implementing cashubtc/nuts#250 * Add CLI for cdk-signatory to spawn an external signatory Add to the pipeline the external signatory * Update tests * Apply suggestions from code review Co-authored-by: ok300 <106775972+ok300@users.noreply.github.com> Co-authored-by: thesimplekid <tsk@thesimplekid.com> * Minor change * Update proto buf to use the newest format * Rename binary * Add instrumentations * Add more comments * Use a single database for the signatory Store all keys, even auth keys, in a single database. Leave the MintAuthDatabse trait implementation for the CDK but not the signagtory This commit also moves the cli mod to its own file * Update dep * Add `test_mint_keyset_gen` test --------- Co-authored-by: ok300 <106775972+ok300@users.noreply.github.com> Co-authored-by: thesimplekid <tsk@thesimplekid.com>
I don't think this is worth it because the rotation command will normally come from the mint |
|
@crodas Can you look at where cdk deviates from this and bring the two in line? Also we should use a common proto file. Think it would be best to create a cashubtc repo for the proto files and remove it from the nuts directly and instead link to it. Think @lollerfirst did one for the management rpc. |
remote-signer.proto
Outdated
| bool active = 3; | ||
| uint64 input_fee_ppk = 4; | ||
| Keys keys = 5; | ||
| uint64 version = 6; |
There was a problem hiding this comment.
Added it to the structure and the keyset rotation call
remote-signer.proto
Outdated
| } | ||
|
|
||
| // Witness type | ||
| message Witness { |
There was a problem hiding this comment.
|
@crodas I added the final_expiry to be optional |
|
I will apply the changes we discussed in CDK this week, specially whatever is in here and dropping the redundant amount field. |
|
@lescuer97 I think cashubtc/cdk#1179 was the thing we discussed, is there anything else missing? /cc @thesimplekid |
|
There are a number of gaps and vulnerabilities in the deterministic derivation path function that are addressed in this proposed NUT spec: #292 Namely, leading and trailing whitespace, capitalization differences, and functionally equivalent unicode character sequences can cause visually identical currency units to hash to different derivation paths. Also, the lack of a reserved range for currently hard coded currency unit derivation paths could lead to backwards incompatible derivation path conflicts. These properties could be exploited by attackers using specially crafted currency unit strings. If y'all would like to review PR 292 I think it would be complementary to this spec proposal and they could potentially go at the same time. |
|
@thesimplekid @vnprc added some features form this #292 pr. should have the details that we discussed |
8 participants
This is a standard for Mints to be able to communicate with a remote signer for cryptographic operations as well as keyset information.
Their is also a standard way for signers to derive their keysets from their master key.
The goal of this nut is to better isolate the private keys of the mint and standardize the communications between the signer and mint.
Implementations: