I’ve looked a bit over the protocol to agree with push notification providers which is described here: Whisper Push Notifications
As far as I know is the technique that is proposed there usually known as ‘RSA Key Transport’. The main problem is that the ‘derived’ key only contains ‘randomness’ of the sender of the response, which is in that case the server. For that reason, it is possible that:
- the server uses the same key more than one time, the server may use even for all clients the same key.
- someone impersonates the server since the key does not rely on entropy of the client
- someone gets the key of the server and is therefore able to decrypt all previous sessions (perfect forward secrecy)
To 1.:
I think it shouldn’t be the responsibility of the server to choose the symmetric encryption key itself. This is problematic because the client (in that case ‘node A’) has to trust the other node (the server) to choose this key carefully.
For that reason, I would suggest to make the key dependent on entropy of both nodes and use a proper key exchange like (EC)DH.
To 2.:
The ‘derived’ key seems to be independent from the previous communication, so it is easy for an adversary to impersonate the server a.k.a. the ‘arbitrary wnode’.
For that reason, I would suggest to use a proper key exchange and make the key dependent of all previously send messages.
A possible man-in-the-middle attack is shown below
To 3.:
I think it is obvious that the protocol does not provide ‘perfect forward security’. In other words, once the secret of the server a.k.a. the arbitrary node gets lost / or in the hands of an adversary, all messages can be decrypted by the adversary.
For that reason, I would suggest to create for each session a new key and to use the public key of each node only to verify the authenticity in that moment. A (EC)DH protocol execution with fresh entropy will solve that problem.
I hope that I could help you with the design of that protocol 