Encrypting the payload will allow you to get by more scanners and in general make the traffic harder to notice. Since the publicly available server code needs to be able to decrypt the payload there is no way to make it completely secure, so this seems like a good tradeoff that prevents passive naive monitoring from triggering while not being more complicated than necessary.

The only real improvement that I can see being made would be adding perfect forward secrecy so that a logged session couldn't be decrypted after the fact. But that would likely add a lot of complexity (I think you need bidirectional communication?)

Seems like single-byte XOR would be almost as good for obfuscation purposes, but I guess using chacha20 from the public key as a pseudo-OTP doesn't hurt.

> The only real improvement that I can see being made would be adding perfect forward secrecy so that a logged session couldn't be decrypted after the fact. But that would likely add a lot of complexity (I think you need bidirectional communication?)

Yeah.

This is a NOBUS attack - Nobody But Us.

By tying it to a particular key owned by the attacker, no other party can trigger the exploit.

I don't think this is responsive to my comment.

I think it is? They were not trying to hide the content, but rather to ensure that nobody else could encrypt valid payloads.

The signing accomplishes that. The chacha20 encryption with part of a public key, which is what I'm discussing above, is just obfuscation.

That action would create extra noise.