search

ExchangeUnion / xud

Exchange Union Daemon 🔁 ⚡️
https://exchangeunion.com
GNU Affero General Public License v3.0
115 stars 44 forks source link

Signing & encrypting #158

Closed moshababo closed 5 years ago

moshababo commented 6 years ago

Decide which encryption schemes we want to apply.

kilrau commented 6 years ago

xud enables two levels of signing/encrypting:

  1. Sign only: Sign all order packets, peer verifies authenticity with my public key
  2. Sign & encrypt: Sign & encrypt order to verify authenticity and encrypt orders with clients nodePubKey to ensure order info can only be decrypted by white-listed peers

Notes: 1. is the default and signs all orders via ECDSA with the xud's private key. This ensures that the xuds nodePubKey carried in the order's invoice is the actual pubKey of the xud sending the invoice. We decided to place the nodePubKey directly in the invoice description field for a faster processing, since this avoids a payment hash vs. nodePubKey lookup for each incoming new order. This mode prevents xud's pretending to be someone else and knowing the actual issuer of an order is important for e.g. the incentive & punishing mechanism to work. This mode connects to all available peers and is suitable for exchanges located in jurisdictions without a strict legal framework for digital assets.

To be discussed @sangaman @moshababo : it could be enough to just verify the nodePubKey on handshake (https://github.com/ExchangeUnion/xud/issues/341) and not sign and verify every packet. This would increase processing speed.

2. is optional, can be enabled in the config. Additionally to everything 1. does, xud encrypts orders with the public key of each white-listed peer. This mode is more resource intensive and requires maintaining a white-list of peers. It is suitable for exchanges located in jurisdictions with a strict legal framework and ensures that order information can only be received and processed by white-listed trading partners, e.g. other licensed exchanges.

This issue is about implementing Mode 2.

kilrau commented 6 years ago

Not priority for next milestone, moved to next

moshababo commented 5 years ago

As discussed in #341,

1: there’s no need to sign all p2p messages while we’re in fully-connected network mode. Signing is necessary only for the communication session authentication.

2: we will encrypt all communication via shared secret key (ECDH/ECDHE) per session. This will make encrypting on white-list peers public key unnecessary, since only the session peer will be able to decrypt it.