Noise vs. ACKs

This commit is contained in:
Jeff Burdges
2019-01-06 23:47:14 +01:00
parent 482673553a
commit 67d0edb122
+3 -1
View File
@@ -18,10 +18,12 @@ Third, there are [no ACKs in secio](https://github.com/libp2p/go-libp2p-secio/is
As QUIC uses UDP only, we could add TCP based transport that uses TLS 1.3, perhaps by extending libp2p's existing transport with support for TLS 1.3, or perhaps adding a more flexible TLS 1.3 layer. We might prefer a flexible TLS 1.3 layer over conventional TLS integration into libp2p extending transports because our authentication privacy demands might work differently from TLS's server oriented model. As QUIC uses UDP only, we could add TCP based transport that uses TLS 1.3, perhaps by extending libp2p's existing transport with support for TLS 1.3, or perhaps adding a more flexible TLS 1.3 layer. We might prefer a flexible TLS 1.3 layer over conventional TLS integration into libp2p extending transports because our authentication privacy demands might work differently from TLS's server oriented model.
We could identify some reasonable [Noise](https://noiseprotocol.org/noise.html) variant, if avoiding the complexity of TLS sounds like a priority. I believe Noise XX fits the blockchain context well, due to Alice and Bob roles being easily reversible, improved modularity, and more asynchronous key certification from on-chain data. At the extreme, we could imagine identifing particular handshakes for particular interactions though, like GRANDPA using KK and fishermen using NK. We could identify some reasonable [Noise](https://noiseprotocol.org/noise.html) [variant](https://github.com/mcginty/snow), *if* avoiding the complexity of TLS sounds like a priority and ACKs are always handled by higher layers. I believe Noise XX fits the blockchain context well, due to Alice and Bob roles being easily reversible, improved modularity, and more asynchronous key certification from on-chain data. At the extreme, we could imagine identifying particular handshakes for particular interactions though, like GRANDPA using KK and fishermen using NK.
In short, we should make a new years resolution to replace secio, with our two simplest routes being either TLS 1.3 or Noise XX. In short, we should make a new years resolution to replace secio, with our two simplest routes being either TLS 1.3 or Noise XX.
---
Aside from these authentication repairs, there are two additional directions for possible future work: Aside from these authentication repairs, there are two additional directions for possible future work:
- *Post-quantum key exchange.* We'd likely employ LWE scheme here. Right now, CSIDH remains young and slow, but the small key size and long-term keys claims indicate that [CSIDH](https://www.esat.kuleuven.be/cosic/csidh-post-quantum-key-exchange-using-isogeny-based-group-actions/) might integrate better with Noise and blockchains. I'd skip the [existing specification](https://github.com/noiseprotocol/noise_wiki/wiki/Post-Quantum-Noise-with-New-Hope) for integrating Noise with New Hope Simple. Adam Langely has good arguments for [selecting the NTRU variant NRSS+SXY for Google's CECPQ2 experiment](https://www.imperialviolet.org/2018/12/12/cecpq2.html). I the module-LWE [Kyber](https://pq-crystals.org/kyber/) - *Post-quantum key exchange.* We'd likely employ LWE scheme here. Right now, CSIDH remains young and slow, but the small key size and long-term keys claims indicate that [CSIDH](https://www.esat.kuleuven.be/cosic/csidh-post-quantum-key-exchange-using-isogeny-based-group-actions/) might integrate better with Noise and blockchains. I'd skip the [existing specification](https://github.com/noiseprotocol/noise_wiki/wiki/Post-Quantum-Noise-with-New-Hope) for integrating Noise with New Hope Simple. Adam Langely has good arguments for [selecting the NTRU variant NRSS+SXY for Google's CECPQ2 experiment](https://www.imperialviolet.org/2018/12/12/cecpq2.html). I the module-LWE [Kyber](https://pq-crystals.org/kyber/)