Mostro key managements

[grunch]

It is required to read NIP-59 (gift wrap) and NIP-06 to fully understand this document

In order to have interoperability, when a user started the client for first time, the client should create a new mnemonic seed phrase which is the only information users will need to share with other client to have the same Mostro session. Mostro clients should use the derivation path m/44'/1237'/38383'/0/0.

Clients will always use the first one (zero) m/44'/1237'/38383'/0/0 to identify the user with mostrod, users who wants to maintain reputation can send an event to Mostro signed with the zero key, the identifier, used to update their rating, the client will start deriving new keys from m/44'/1237'/38383'/0/1 for each new order created or taken, users who don't want to maintain reputation simply don't send the identifier event to mostrod, let's see it in more detail with an example:

• Alice starts a Mostro client for first time, at that moment the client creates a new mnemonic seed phrase and derive two keys, the identifier key (index 0) and the next operation key with index 1 m/44'/1237'/38383'/0/1, we will use operation keys to sign the gift wrap seal event.

• Before start operating the client automatically should identify with Mostrod, in order to achieve this the client send a message in a Gift wrap Nostr event to mostrod with the seal signed with index 1 key and this content's rumor:

{
  "identify": {
    "version": 1,
    "pubkey": "000051b64809ca8356d01d8a8029999b78e1b9a6df8f09d18d873843c9ce7065", // index `0` pubkey
    "action": "challenge",
    "content": null
  }
}

• Mostrod respond with a random number hashed with sha256, Here the content's rumor:

{
  "identify": {
    "version": 1,
    "pubkey": "000051b64809ca8356d01d8a8029999b78e1b9a6df8f09d18d873843c9ce7065",
    "action": "challenge",
    "content": "a3072317291444df786c993fac6783d147f8af5a86fadaa7540757b5db3d2f6d"
  }
}

• Alice's client sends a message in a gift wrap Nostr event to Mostrod with seal signed with index 1 key and with the index 0 pubkey in the rumor, inside the content the client signs the chanllenge with index 0 key, this way Mostrod knows that the user of index 1 is also the user of index 0, Here the content's rumor:

{
  "identify": {
    "version": 1,
    "pubkey": "000051b64809ca8356d01d8a8029999b78e1b9a6df8f09d18d873843c9ce7065",
    "action": "signed-challenge",
    "content": "7e8fe1eb644f33ff51d8805c02a0e1a6d034e6234eac50ef7a7e0dac68a0414f7910366204fa8217086f90eddaa37ded71e61f736d1838e37c0b73f6a16c4af2"
  }
}

• Now Alice can create or take a new order with the index 1 key, and Mostrod can show the reputation liked to index 0 key, in the particular case there is no reputation, but it will be the next time Alice operates.

• Alice create a sale order using index 1 key

• Bob takes the order

• After finish the deal, both mostro clients derive the next key, Alice new key is index 2 (m/44'/1237'/38383'/0/2) and send a message in a Gift wrap Nostr event to mostrod with the seal signed with index 2 key, Here the content's rumor:

{
  "identify": {
    "version": 1,
    "pubkey": "000051b64809ca8356d01d8a8029999b78e1b9a6df8f09d18d873843c9ce7065", // index `0` pubkey
    "action": "challenge",
    "content": null
  }
}

• Mostrod respond with a random number hashed with sha256

• Alice's client sends a message in a gift wrap Nostr event to Mostrod with seal signed with index 2 key and with the index 0 pubkey in the rumor, inside the content the client signs the chanllenge with index 0 key, this way Mostrod knows that the user of index 2 is also the user of index 0

• Now Alice can create or take a new order with the index 2 key, and Mostrod can show the reputation liked to index 0 key.

Full privacy mode

Clients must offer a more private version where the client never ask for a challenge to mostrod, in that case mostrod can't link users orders, the tradeoff is that users who choose this option cannot have a reputation

[bilthon]

Let me start by outlining the overall objectives and use the introduction of NIP-06 as a reference point to highlight common ground.

Objectives:

1. Facilitate portability by using a deterministic key generation mechanism based on NIP-06.
2. Prevent users from mistakenly entering key material already used in other NOSTR social media apps.
3. Rotate keys for every trade.

It's important to provide more context around item 3. To do so, let's first recall that there are two types of private communications in the Mostro protocol:

• Peer-to-Mostro
• Peer-to-Peer

These two types of communications are "gift-wrapped," meaning the sender’s information and other metadata are always obfuscated.

Peer-to-Mostro communications consist of all NIP-59 messages sent directly from the peer to Mostro. Examples include actions like new-order, take-sell, fiat-sent, release, and others.

For users aiming to build a reputation, it's worth noting that rotating keys for Peer-to-Mostro communications offers no additional privacy benefits. These keys inevitably need to be linked to one another during the reputation-building process. While Mostro could internally erase all past trade data, including the associated keys, the client would have to trust that Mostro is actually doing so without any way to verify it. Given this context, rotating the key used for Peer-to-Mostro communications seems unnecessary. Instead, we could standardize around using m/44'/1237'/38383'/0/0—referred to here as the "zero key" or "identity key" for all Peer-to-Mostro communications.

Peer-to-Peer communications, however, present a case where key rotation adds value. While some fiat payment methods may expose a user’s identity to the counterparty—undermining the privacy benefits—there’s still merit in implementing this feature on the NOSTR communication side. Ultimately, the choice of fiat payment method lies with the user, and for those that don’t reveal their identity, this mechanism would remain effective.

The idea here is to use a series of per-trade keys, starting with m/44'/1237'/38383'/0/1 and incrementing from there. These "per-trade keys" (or "p2p keys") would be assigned by Mostro to each party once the escrow is secured, allowing them to communicate directly. This is similar to how lnp2pbot currently shares Telegram handles between parties.

Figure 1 below condensates these ideas.

Fig 1. Peer-to-Mostro and Peer-to-Peer communications illustrated. Key zero is consistently used in the Peer-to-Mostro channel even across trades, as illustrated by the solid lines. Peer-to-Peer communications do make use of key rotation on a per-trade basis, and this is illustrated by the dashed lines and the use of keys AN and BN.

Key Ownership

This proposal not only involves committing to specific keys but also suggests proving ownership of those keys through challenge-and-response messages. I think this not only adds an extra communication round which would increase latency, but is actually not necessary.

The motivation seems to be twofold:

1- To ensure the peer commits to a specific per-trade key.
2- To verify that the peer actually owns the per-trade key.

I understand the rationale behind item 2 is to prevent triangulation scams, which can occasionally occur in systems like lnp2pbot. In such scams, a supposed buyer is tricked into sending fiat to a seller while believing they are paying for a completely unrelated service (e.g., fake cellphone unlocking). For this to work, both endpoints of the fiat transfer must never communicate directly, allowing the scammer to act as a middleman.

However, not all triangulations are inherently malicious. Cross-border remittance systems, for instance, often rely on similar mechanisms. The key difference is that in legitimate cases, both parties—buyer and seller—should have a direct communication channel to confirm the trade terms: the seller gives up sats expecting fiat, and the buyer sends fiat expecting sats, not a fictitious service.

Requiring proof of ownership of the "per-trade key" seems overly rigid and could block legitimate use cases we might want to accommodate in the future. In my view, it’s sufficient for each party to commit to a specific public key without needing to prove ownership.

By sending their chosen "trade key" in a signed message to Mostro, each party effectively commits to that key. Swapping it for another key would be impossible since it’s embedded in the encrypted payload of a NIP-59 event and secured by the signature.

Conclusion

I don't want to conclude this post without a more precise description of the proposed changes to the protocol messages to achieve the limited key rotation described above.

Order creation

{
  "order": {
    "version": 1,
    "action": "new-order",
    "content": {
      "order": {
        "kind": "sell",
        "status": "pending",
        "amount": 0,
        "fiat_code": "VES",
        "min_amount": null,
        "max_amount": null,
        "fiat_amount": 100,
        "payment_method": "face to face",
        "premium": 1,
        "trade_key": "7:f1795f48904fb5979f18ad1a2417890f399452b4ce04b83e7d4468d23fb848be"
        "created_at": 0
      }
    }
  }
}

Here the order creator is communicating to mostro what trade key they want to use. Note that both the derivation index and key are communicated in the <index>:<key> format. Conversely in the take-sell message, the buyer would have to send:

{
  "order": {
    "version": 1,
    "id": "ede61c96-4c13-4519-bf3a-dcf7f1e9d842",
    "action": "take-sell",
    "content": {
        "trade_key": "3:d4aac6fff942258a37d40e741470933b77f2570cfa910d1a93a50dfa4cc2cfc6"
    }
  }
}

Basically both parties inform Mostro of their desired "trade keys" when the order is created and taken.

Once the hold invoice is secured, Mostro will in turn send the following message to the seller:

{
  "order": {
    "version": 1,
    "id": "ede61c96-4c13-4519-bf3a-dcf7f1e9d842",
    "action": "buyer-took-order",
    "content": {
      "order": {
        "id": "ede61c96-4c13-4519-bf3a-dcf7f1e9d842",
        "kind": "sell",
        "status": "active",
        "amount": 7851,
        "fiat_code": "VES",
        "fiat_amount": 100,
        "payment_method": "face to face",
        "premium": 1,
        "buyer_trade_key": "d4aac6fff942258a37d40e741470933b77f2570cfa910d1a93a50dfa4cc2cfc6",
        "seller_trade_key": "f1795f48904fb5979f18ad1a2417890f399452b4ce04b83e7d4468d23fb848be",
        "buyer_invoice": null,
        "created_at": 1698937797
      }
    }
  }
}

Similarly, the buyer will receive:

{
  "order": {
    "version": 1,
    "id": "ede61c96-4c13-4519-bf3a-dcf7f1e9d842",
    "pubkey": null,
    "action": "hold-invoice-payment-accepted",
    "content": {
      "order": {
        "id": "ede61c96-4c13-4519-bf3a-dcf7f1e9d842",
        "kind": "sell",
        "status": "active",
        "amount": 7851,
        "fiat_code": "VES",
        "fiat_amount": 100,
        "payment_method": "face to face",
        "premium": 1,
        "buyer_trade_key": "d4aac6fff942258a37d40e741470933b77f2570cfa910d1a93a50dfa4cc2cfc6",
        "seller_trade_key": "f1795f48904fb5979f18ad1a2417890f399452b4ce04b83e7d4468d23fb848be",
        "buyer_invoice": null,
        "created_at": 1698937797
      }
    }
  }
}

This is basically just replacing the existing master_buyer_pubkey and master_seller_pubkey for buyer_trade_key and seller_trade_key.

Clients should also keep track of which trade key index was last used to make sure these are not re-used. To facilitate portability, Mostro could keep track of a client's last derived key index, which could be retrieved by the client with a message like this:

{
    "status": {
        "version": 1,
        "action": "key-index",
        "content": null
    }
}

To which Mostro could reply with:

{
    "status": {
        "version":1,
        "action": "key-index",
        "content": {
            "index": 7
        }
    }
}

[arkanoider]

My two cents...
I would keep simpler about having no reputation.
No reputation? Just create always a new Key, robosats style.

[z017]

By supporting by protocol a full privacy mode, Mostro database keeps more clean by only saving the identities that people want to be saved.

But it's not so important. As you said, this mode can be implemented by clients selecting which key to use.

[arkanoider]

Obviously i won't say that's not a good idea...but i like to keep things as simple as possible.
Anyway @grunch will have the final word! 😄
By the way, welcome @z017 ! We need devs here...so any comment is super appreciated!

[z017]

Thx @arkanoider !

And yes it's just an idea. I tend to overengineering XD

[arkanoider]

You're welcome @z017 ! I suppose you're a young and smart guy, normal to overengineer! I am an old man living a simple life... LOL

[arkanoider]

Sorry for my noobness in cryptography, but using 2 tags in rumor like these:

• nonce tag with u64 value ( good source of randomness imo )
• signed_nonce with pubkey0 signature of nonce

Like this:

// external wrap layer
{
  "id": "<id>",
  "kind": 1059,
  "pubkey": "<Buyer's ephemeral pubkey>",
  "content": { // Seal
    "id": "<seal's id>",
    "pubkey": "<index 1 pubkey (trade key)>",
    "content": { // Rumour
      "id": "<rumor's id>",
      "pubkey": "<Index 0 pubkey>",
      "kind": 1,
      "content": [
        {
          "order": {
            "version": 1,
            "action": "new-order",
            "content": {
              "order": {
                "kind": "buy",
                "status": "pending",
                "amount": 0,
                "fiat_code": "VES",
                "fiat_amount": 100,
                "payment_method": "face to face",
                "premium": 1,
                "created_at": 0,
                "trade_key_index": 1
              }
            }
          }
        }
      ],
      "created_at": 1691518405,
      "tags": [
        [
          "nonce",
          "u64 value"
        ],
        [
          "signed_nonce",
          "index 0 signature of the nonce tag"
        ]
      ]
    },
    "kind": 13,
    "created_at": 1686840217,
    "tags": [],
    "sig": "<index 1 pubkey (trade key) signature>"
  },
  "tags": [
    [
      "p",
      "<Mostro's pubkey>"
    ]
  ],
  "created_at": 1234567890,
  "sig": "<Buyer's ephemeral pubkey signature>"
}

So we have:

• A signature of pubkey 0 inside ruomr so ownership can be proved and we don't break nips.
• A seal can be signed with a trading key.

[z017]

The signature must be applied over all the data that Mostro requires and wants to validate to create an order.

If the client only signs the nonce. Mostro can create a new order with the same nonce and signature a replay the message to another Mostro server (this is the replay attack).

I think we need to add:

• identity_key
• trade_key
• mostro_key

When the mostro server receives a new gift wrap:

• desencrypt seal
• got seal_trade_pubkey and seal_trade_signature
• if signature is valid, mostro knows that the client has the private key associated with seal_trade_pubkey
• desencrypt rumor
• got rumor_trade_pubkey, rumor_mostro_pubkey, rumor_identity_key, rumor_content_identity_signature
• if rumor_mostro_pubkey is not the server pubkey, discard message (this can be optional but avoid Mostro replay the order to another Mostro)
• if rumor_trade_pubkey != seal_trade_pubkey, discard message
• if rumor_identity_key and the rumor_content_identity_signature are not valid, discard message
• create order

The only complication here (and that's why before I put the identity signature on the seal) it's that the identity signature must be done manually over the first part of the content (this is not a Nostr standard).

If we cannot add new keys to the seal json and the NIP-59 says the seals tags must be empty. Maybe the identity signature can be set on the gift wrap tags and sign the rumor id like the seal trade key signature.

[z017]

Proposal with identity signature as a gift wrap tag.

// external wrap layer
{
  "id": "<id>",
  "kind": 1059,
  "pubkey": "<Buyer's ephemeral pubkey>",
  "content": { // seal
    "id": "<seal's id>",
    "pubkey": "<index 2 pubkey (trade key)>", // trade key (must match trade key in rumor)
    "content": { // rumor
      "id": "<rumor's id>"
      "pubkey": "<index 2 pubkey (trade key)>", // trade key in rumor
      "kind": 1,
      "content": [
        {
          "order": {
            "version": 1,
            "action": "new-order",
            "content": {
              "order": {
                "kind": "buy",
                "status": "pending",
                "amount": 0,
                "fiat_code": "VES",
                "fiat_amount": 100,
                "payment_method": "face to face",
                "premium": 1,
                "created_at": 0,
                "trade_key_index": 2,
                "mostro_key": "<mostro pubkey>", // mostro key in rumor (avoids replay attack)
                "identity_key": "<index 0 pubkey (identity key)>", // identity key in rumor (nullable in full privacy mode)
                "reputation": true, // indicates this trade is reputation tracked (requires identity_key)
              }
            }
          }
        },
      ],
      "created_at": 1691518405,
      "tags": []
    },
    "kind": 13,
    "created_at": 1686840217,
    "tags": [],
    "sig": "<index 2 pubkey (trade key) signature>" // proof of trade key ownership
  },
  "tags": [
    ["p", "<Mostro's pubkey>"], // mostro key (must match mostro key in rumor)
    ["is", "<index 0 signature of the rumor's id>"], // proof of identity key ownership, not required in full privacy mode
  ],
  "created_at": 1234567890,
  "sig": "<Buyer's ephemeral pubkey signature>"
}

[bilthon]

Replay attacks were also a concern I was going to raise with @arkanoider 's proposal. I think we can stick to @grunch 's version with the slight modification that the identity key is used at the seal level for the first messages: new-order, take-buy & take-sell.

This is more idiomatic with NIP-59 that kinda reserves the seal level for the sender identity. The overall idea would be that in these 3 first messages a user is more or less saying "look, I'm user X, but for this trade I'll be using key Y". And all subsequent messages are signed at seal level with the trade key Y.

I realized this is not a nitpick but actually protects us from replay attacks as well. As otherwise the combination of message(with order data) + signature if leaked could be used to create orders on a user's name.

Here's what this would look like:

{ // gift wrap
  "id": "<id>",
  "kind": 1059,
  "pubkey": "<Buyer's ephemeral pubkey>",
  "content": { // seal
    "id": "<seal's id>",
    "pubkey": "<index 0 pubkey (identity key)>",
    "content": { // rumor
      "id": "<rumor's id>"
      "pubkey": "<index 0 pubkey>",
      "kind": 1,
      "content": [
        "order": {
          "version": 1,
          "action": "new-order",
          "content": {
            "order": {
              "kind": "buy",
              "status": "pending",
              "amount": 0,
              "fiat_code": "VES",
              "fiat_amount": 100,
              "payment_method": "face to face",
              "premium": 1,
              "created_at": 1732649993,
              "trade_key": "<index>:<pubkey_hex>",
            }
          }
        },
        <signature of the serialized order data with trade_key>
      ],
      "created_at": 1691518405,
      "tags": [],
    },
    "kind": 13,
    "created_at": 1686840217,
    "tags": [],
    "sig": "<signature created with index 0 pubkey (identity key)>"
  },
  "tags": [
    ["p", "<Mostro's pubkey>"]
  ],
  "created_at": 1234567890,
  "sig": "<Buyer's ephemeral pubkey signature>"
}

I've also prepared a colored version here.

PS. I realized there's another slight difference from @grunch proposal to mine, and this is that his includes the trade_key_index while in mine this info is encoded in the trade key payload by using the <index>:<pubkey_hex> format. Either way is fine, I just prefer it being more compact.

[arkanoider]

I like this, simple as that and NIP aligned.

Thanks @bilthon @z017 you have enlightened an old man on replay attacks.

[z017]

• Identity or Trade key signing the first messages

  • I like the idea of the first messages being signed by the identity key.
    In my proposal I finally rotate them to make identity nullable in the full privacy mode.
    But if that mode is managed by the clients, identity is always defined.

• What do you think about moving the second signature as a gift wrap tag?

  • In the gift wrap tag version
    • The rumor id is signed
    • The rumor id is calculated by Nostr libraries
    • The rumor id commits to rumor's pubkey
  • In the rumors content version
    • The mostro message is signed
    • The mostro message hash is a mostro convention (not Nostr)
    • The mostro message doesn't have rumor's pubkey

[bilthon]

Oh so that's what is stands for in your proposal, "identity signature", right?

Well overall I'm not a big fan of using tags for content or otherwise non-indexable meta-data. I'm also not sure what the benefits are. But I think I can point out a downside, which is that it would make gift wrap events directed to mostro instances stand out against other unrelated gift wraps. Ideally we should aim to blend in with the greater set of unrelated gift wrap events. An external observer should have to guess wether a gift wrap is for a mostro instance or not. With this tag we'd be leaking this info.

I also think using the identity key at the seal level prevents useful replay attacks and further tights everything together.

[z017]

Oh so that's what is stands for in your proposal, "identity signature", right?

Yes, is a reference to "identity signature".

it would make gift wrap events directed to mostro instances stand out

It's a big downside for privacy! With that in mind, I prefer the other solution.

[grunch]

Thank you all for your amazing ideas, we have a final version, closing this discussion

https://mostro.network/protocol/key_management.html