libp2p-noise: support all 12 handshakes

[kpp]

http://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental

The first character refers to the initiator's static key:

    N = No static key for initiator
    K = Static key for initiator Known to responder
    X = Static key for initiator Xmitted ("transmitted") to responder
    I = Static key for initiator Immediately transmitted to responder, despite reduced or absent identity hiding

The second character refers to the responder's static key:

    N = No static key for responder
    K = Static key for responder Known to initiator
    X = Static key for responder Xmitted ("transmitted") to initiator

However IK, IX, XX are supported only. Will you support other handshakes like NK for example?

[kpp]

pub struct ProtocolParams(snow::params::NoiseParams);

I see. I can build it manually.

[kpp]

I am confused a little bit. How about this:

impl UpgradeInfo for NoiseConfig<XX, X25519> {
    type Info = &'static [u8];
    type InfoIter = std::iter::Once<Self::Info>;

    fn protocol_info(&self) -> Self::InfoIter {
        std::iter::once(b"/noise/xx/25519/chachapoly/sha256/0.1.0")
    }
}

impl UpgradeInfo for NoiseConfig<IK, X25519> {
    type Info = &'static [u8];
    type InfoIter = std::iter::Once<Self::Info>;

    fn protocol_info(&self) -> Self::InfoIter {
        std::iter::once(b"/noise/ik/25519/chachapoly/sha256/0.1.0")
    }
}

impl UpgradeInfo for NoiseConfig<IK, X25519, PublicKey<X25519>> {
    type Info = &'static [u8];
    type InfoIter = std::iter::Once<Self::Info>;

    fn protocol_info(&self) -> Self::InfoIter {
        std::iter::once(b"/noise/ik/25519/chachapoly/sha256/0.1.0")
    }
}

Does it mean other handshakes are not supported yet?

[twittner]

Does it mean other handshakes are not supported yet?

Yes. As you noted initially, there is only support for IK, IX and XX so far.

[kpp]

Will there be support for all 12 handshakes?

[romanb]

I think support for any patterns involving N, i.e. without a static key for one or both parties, are unlikely to ever see support because pretty much all of libp2p is designed around authenticated peers, so the only option for establishing such a connection would be by direct use of transports like libp2p-tcp in combination with libp2p-noise and low-level libp2p-core APIs that allow to set up the connection with a peer yourself without going through the regular APIs for "dialing" and "listening".

That leaves KK, KX and XK which are currently not supported, but could be. Nevertheless, support for handshakes involving K are also not as convenient to use as one may think, since due to the signing of noise static keys with the libp2p identity keys one needs to Know both, the remote's public identity key and the remote's public static DH key, which also means that these static DH keys need to be longer-lived than desired, i.e. it is common to only persistently store the libp2p identity keys and generate new static DH keys on every node start.