Encryption and Authentication proposal

[bddap]

Grin transactions are not encrypted by default, making them vulnerable to man in the middle attacks.

The proposed solution uses snow, an implementaion of the noise protocol framework, to provide mandatory encryption and mutual authentication for grin wallet communications. Both the connection initiator (client) and the responder (server) are authenticated by their public keys. Encrypted streams are implememented atop TCP. While the solution does not implement public key addressing, it is an incremental step towards that goal.

Readers are encouraged to provide feedback.

Proposed change

Encrypt OwnerApi and ForeignApi communications using noise protocol Noise_XX_25519_ChaChaPoly_BLAKE2s.

Considerations

Serving apis over http benefits usability. Do we depricate the http apis?

Should communications outside of grin-wallet be encrypted as well?

Encrypted streams are difficult to implement without async/await support. My current encrypted streams implementation relies on async/await. grin-wallet targets stable Rust so a merge won't be possible until mid-August when Rust 1.37 becomes stable.

For encrypted transactions to become the de-facto standard, other implementations like Grin++ will need to implement them. Luckily, the noise protocol framework is implemented in multiple languages, including C.

Future steps

• Address lookups (perhaps using a DHT of type PUBKEY->(IP, PORT))
• NAT workarounds

Alternatives

• I2P
  • Provides a superset of the proposed functionality, including pubkey adresses and nat traversal.
  • I2P is a non-trivial dependency. Usage would require an I2P deamon running on target machines.
• TOR
  • Provides a superset of the proposed functionality, including pubkey adresses and nat traversal.
  • TOR is a non-trivial dependency.
• Tox
  • Provides a superset of the functionality of this change, including pubkey adresses and nat traversal.
  • Intended primarily for chat and other encrypted communication but plans to provide an interface for generic encrypted byte streams.
  • Rust port is WIP.
• TLS
  • Current Public Key Infastructure does not fit Grin's use case.
  • Mutual authentication over TLS with self signed certificates is possible in theory but it is not TLS's primary intended use. This blog series shows current state of TLS client authentication in Rust. The author was able to authenticate clients but only when using openssl bindings.

Proposed conventions

Wallet URL format, bikeshedding welcome :)

<PUBLIC-KEY>@{IP,DOMAIN}[:PORT] has been proposed.

The convention may become popular outside of grin and used for general purpose adressing. In that case "@" becomes a problem for email servers. <PUBLIC-KEY>+{IP,DOMAIN}[:PORT] or similar may be used to avoid potential conflict with email, ssh, etc.

Potential usablility issue

Public keys are long: 5033dc859ac591cec7bc4a32a49db2c6c80794c334cb6e739eff74f5f4b9d20b@50.51.1.30:24345

Post-DHT upgrade

When it becomes possible to look up adresses by public key, IP becomes optional: <PUBLIC-KEY>@{IP,DOMAIN}[:PORT] -> <PUBLIC-KEY>[@{IP,DOMAIN}[:PORT]].

Related issues

• Deprecate http listener for external addresses #66
• Add TLS to peer-to-peer connections grin#1420

Previous work

• Forum discussion
• Wiki page
• Initial encrypted streams implementaion

Request for feedback

If anyone wants to comment on these plans, please do. Make sure to tag @bddap on gitter or github.

I intend to start a WIP pr if this proposal is well accepted.

[0xmichalis]

Alternatives
I2P

* Provides a superset of the proposed functionality, including pubkey adresses and nat traversal.

* I2P is a non-trivial dependency. Usage would require an I2P deamon running on target machines.

There is ongoing work to add I2P support in both the node and wallet comms - see mimblewimble/grin#2712

[lehnberg]

@bddap are you still considering this? Could a similar approach be suitable for the p2p network as well? mimblewimble/grin#1420

[bddap]

I still think it's a useful addition and yes, it could work in p2p.

It may be possible now to use rustls (without PKI) for this instead of noise. unfinished work on wallet tls listener.

[yeastplume]

Going to close this issue now, as we've selected TOR as an optional dependency to handle these issues.