Improper nonce handling

[dnkolegov]

There are two issues with nonce handling:

1. Nonces are 32 bits long. The Noise spec requires 64-bit nonce.

https://github.com/NodeFactoryIo/js-libp2p-noise/blob/master/src/%40types/handshake.d.ts#L12-L15

2. Nonce overflow.
   The spec requires returning an error if the maximum number is reached. This is the same issue as in the flynn package but more realistic due to 32-bit length.

https://github.com/NodeFactoryIo/js-libp2p-noise/blob/master/src/handshakes/abstract-handshake.ts#L46-L48

[mpetrunic]

Hey @dnkolegov tnx for opening issue.

1. Because of javascript limitations this would force us to use BigInt which will degrade performance to some degree. @vasco-santos should be switch nonce to BigInt?
2. I think this is valid. Would it be ok if throw error when nonce is > MAX_SAFE_INTEGER?

[dnkolegov]

Would it be ok if throw error when nonce is > MAX_SAFE_INTEGER?

Yes. That's correct. For example, https://github.com/flynn/noise/blob/master/state.go#L44-L46.

Because of javascript limitations this would force us to use BigInt which will degrade performance to some degree. should be switch nonce to BigInt?

It should be noted that all other libp2p-noise implementations use Noise with 64-bit nonce. My concern here is that your implementation will throw an exception while a peer having another implementation (e.g., go-libp2p) would process it correctly.

[mpetrunic]

It should be noted that all other libp2p-noise implementations use Noise with 64-bit nonce. My concern here is that your implementation will throw an exception while a peer having another implementation (e.g., go-libp2p) would process it correctly.

Pretty sure we will close connection and new connection will start from 0 nonce. That said it's highly unlikely anyone will ever pass uint32 number of messages in single connection 😄