search

entropyxyz / entropy-core

Protocol and cryptography development.
https://docs.entropy.xyz/
GNU Affero General Public License v3.0
11 stars 2 forks source link

Encryption for secret share distribution. #188

Closed ok-john closed 2 years ago

ok-john commented 2 years ago

Currently secret shares are transported as plaintext over http between clients, the rocket server, and the chain. This leaves secret shares vulnerable to both traffic snooping and MITM attacks that could replace an intended secret share with a malicious one.

As discussed with @JesseAbram there are a few potential solutions to this problem.

1) Encrypt & Sign all messages using standard PKC and continue to use a non-encrypted transport (e.g. HTTP, wire, etc..) 2) Self signed certificates for TLS between nodes. 3) Integrating WireGuard as a secure transport over UDP. 4) Alternative secure transports such as QUICC, etc.. 5) Piggy-backing on the libp2p + noise protocol layer that's used by the nodes.

fjarri commented 2 years ago

Self signed certificates for TLS between nodes.

Not a great option if you want to do that from the browser. Browsers really dislike self-signed certs.

Another option is piggy-backing on the libp2p + noise protocol layer that's used by the nodes.

ok-john commented 2 years ago

Not a great option if you want to do that from the browser. Browsers really dislike self-signed certs.

While this won't be used for browsers (just TLS between nodes), I agree with you wholly. (Also have done work in web PKI and the whole system is somewhat of a nightmare, lol).

@fjarri is all of our network traffic able to utilize the noise protocol? We can use it for communication between nodes, how about light-clients/wallets that may not have established keys via DH?

jakehemmerle commented 2 years ago

Some architectural info for executing 5 is here https://substrate.stackexchange.com/questions/4761/what-is-the-best-way-to-add-additional-libp2p-protocols-to-substrate-client

jakehemmerle commented 2 years ago

I personally think 5 is the cleanest way and I hope would require the least amount of rewriting, but not necessarily the fastest to implement, so another method could still be a better idea

JesseAbram commented 2 years ago

Just a heads up, still most likely will be a signer from mobile not within a browser

ok-john commented 2 years ago

@jakehemmerle +1 to libp2p

@JesseAbram @fjarri any objections to libp2p? I'd prefer we make a decision sooner rather than later to avoid the need for a large rewrite of our threshold signing server down the road.

fjarri commented 2 years ago

During NY meet-up Jake and I were the proponents of p2p, so no objections from me.

ok-john commented 2 years ago

Moving discussion to #193