Add authentication for the Delivered message

[hackaugusto]

We don't want to sign all messages because ecrecover is an expensive operation, specially we don't want to sign the Delivered messages because that would double the number of signatures, without encryption that means that an Delivered message can be easily forged.

A forged Delivered's can be used to make a channel unusable and maybe to steal some asset.

• To make a channels unusable an Delivered for a DirectTransfer or Secret message is sufficient, since the sender would update it's state while the partner won't.
• To steal some asset a MediatedTransfer is required, ABC, B would need to intercept the RevealSecret messages and make sure that C don't receive it until the the BC lock expires, then it can settle the transaction AB on chain with the secret learned from the intercepted message (Secure against interception of RevealSecret messages #473).
  • This is still possible with the Secret Registry iff the lock expiration changes, and this is possible since the settle timeout is not enforced to be constant through out the network

With an encryption scheme faster than ecrecoverable signatures we can drop the signatures from the messages that are not exposed to the smart contract (messages that are signed only to inform us about the sender, eg. SecretRequest, TransferTimeout, etc.)

[heikoheiko]

As we don't have a perfect forward secrecy requirement, not even encryption for the forged ack issue we can go with something simple as only authentication of messages is needed.

Naive approach: A session secret that both parties send on (re)connect, encrypted for the pubkey that we already know (do we? or only the address?).
Then we send Ack([echo, hash(echo + secret)]) as an authenticated ack.

[konradkonrad]

encrypted for the pubkey that we already know (do we? or only the address?)

We don't. It could however make sense to attach the pubkey to the discovery information (currently in the discovery contract). In the future we should be able to query pubkey's through a discovery (dht?) layer. If we go with any sort of devp2p derivative, we will need node pubkeys anyway (even if queried via ethereum address from DHT).

[hackaugusto]

5cde158 fixed this, ATM the message is being signed