I have verified that UPnP and NAT-PMP work against an older version of
the MiniUPnP daemon running on pfSense. This code is kind of hard to
test automatically.
Overview of changes:
- ClientIdentity has been removed, use discover.NodeID
- Server now requires a private key to be set (instead of public key)
- Server performs the encryption handshake before launching Peer
- Dial logic takes peers from discover table
- Encryption handshake code has been cleaned up a bit
- baseProtocol is gone because we don't exchange peers anymore
- Some parts of baseProtocol have moved into Peer instead
- add const length params for handshake messages
- add length check to fail early
- add debug logs to help interop testing (!ABSOLUTELY SHOULD BE DELETED LATER)
- wrap connection read/writes in error check
- add cryptoReady channel in peer to signal when secure session setup is finished
- wait for cryptoReady or timeout in TestPeersHandshake
- set proper public key serialisation length in pubLen = 64
- reset all sizes and offsets
- rename from DER to S (we are not using DER encoding)
- add remoteInitRandomPubKey as return value to respondToHandshake
- add ImportPublicKey with error return to read both EC golang.elliptic style 65 byte encoding and 64 byte one
- add ExportPublicKey falling back to go-ethereum/crypto.FromECDSAPub() chopping off the first byte
- add Import - Export tests
- all tests pass
- abstract the entire handshake logic in cryptoId.Run() taking session-relevant parameters
- changes in peer to accomodate how the encryption layer would be switched on
- modify arguments of handshake components
- fixed test getting the wrong pubkey but it till crashes on DH in newSession()
- add session token check and fallback to shared secret in responder call too
- use explicit length for the types of new messages
- fix typo resp[resLen-1] = tokenFlag
- correct sizes for the blocks : sec signature 65, ecies sklen 16, keylength 32
- added allocation to Xor (should be optimized later)
- no pubkey reader needed, just do with copy
- restructuring now into INITIATE, RESPOND, COMPLETE -> newSession initialises the encryption/authentication layer
- crypto identity can be part of client identity, some initialisation when server created
