Feature/reply surbs

[jstuczyn]

So this pull requests actually does way more than what the branch name would suggest. Again, I should have probably dealt with each 'sub-feature' on its own. But regardless, the highlights of the work include:

• you can optionally attach a reply SURB to each message you send allowing for the recipient to reply anonymously!
• while this is not a feature, it's worth mentioning: there is no reply message retransmission and this is a difficult open problem possibly requiring system redesign. So REPLIES ARE UNRELIABLE and might, or might not, reach their destination.
• The Go, Python, Rust and JavaScript (not wasm one) examples were updated to show how to use reply SURBs.
• There is now a full end to end encryption on all messages exchanged between clients. There is, however, a tiny vulnerability because of this discussed in https://github.com/nymtech/nym/issues/296,
• There is also a full end to end encryption on all messages exchanged between clients and their gateways. On top of it, the "sphinx-y" messages have an extra MAC attached to ensure integrity.
• I've pulled out all ( I think ) hashing and symmetric-encryption algorithms used for easy replacement later on:

  nym/common/nymsphinx/params/src/lib.rs

  Lines 35 to 69 in 675ff9f

  	/// Hashing algorithm used during hkdf for ephemeral shared key generation per sphinx packet payload.
  	pub type PacketHkdfAlgorithm = blake3::Hasher;
  	/// Hashing algorithm used during hkdf while establishing long-term shared key between client and gateway.
  	pub type GatewaySharedKeyHkdfAlgorithm = blake3::Hasher;
  	/// Hashing algorithm used when computing digest of a reply SURB encryption key.
  	pub type ReplySURBKeyDigestAlgorithm = blake3::Hasher;
  	/// Hashing algorithm used when computing integrity (H)Mac for message exchanged between client and gateway.
  	// TODO: if updated, the pem type defined in gateway\gateway-requests\src\registration\handshake\shared_key
  	// needs updating!
  	pub type GatewayIntegrityHmacAlgorithm = blake3::Hasher;
  	/// Encryption algorithm used for encrypting acknowledgement messages.
  	// TODO: if updated:
  	// - PacketSize::ACK_PACKET_SIZE needs to be manually updated (if nonce/iv size differs);
  	// this requirement will eventually go away once const generics are stabilised (and generic_array and co. start using them)
  	// - the pem type defined in nym\common\nymsphinx\acknowledgements\src\key needs updating!
  	pub type AckEncryptionAlgorithm = Aes128Ctr;
  	/// Encryption algorithm used for end-to-end encryption of messages exchanged between clients
  	/// and their gateways.
  	// TODO: if updated, the pem type defined in gateway\gateway-requests\src\registration\handshake\shared_key
  	// needs updating!
  	pub type GatewayEncryptionAlgorithm = Aes128Ctr;
  	/// Encryption algorithm used for end-to-end encryption of messages exchanged between clients that are
  	/// encapsulated inside sphinx packets.
  	pub type PacketEncryptionAlgorithm = Aes128Ctr;
  	/// Encryption algorithm used for end-to-end encryption of reply messages constructed using ReplySURBs.
  	// TODO: I don't see any reason for it to be different than what is used for regular packets. Perhaps
  	// it could be potentially insecure to use anything else?
  	pub type ReplySURBEncryptionAlgorithm = PacketEncryptionAlgorithm;

As for the issues:

• Closes Get rid of instances of Deref polymorphism antipattern #283
• Might have dealt with Proper integrity check between client and gateway #282
• Closes The messages pushed from gateway should be encrypted. #276
• Closes The shared key between client and gateway should be stored in a file. #273
• I think also closes More secured auth token - some signature on request #5

However, some things are incomplete and introduced new problems such as https://github.com/nymtech/nym/issues/296, https://github.com/nymtech/nym/issues/294, #277