Without going as far as implementing #198, there are things we should be doing already:
r10336 makes it at least possible to encrypt the first hello packet, controlled by the env var
The IV and salt can also be changed using env vars.
The statement in the ticket description about needing more salt may be wrong: when we use encryption (which is when we care about salt), we already send 'iv' and 'salt' which are random.
See also: ticket:933#comment:5
Encrypting the first packet is not particularly useful: there is little to hide in that packet, especially when also using authentication (we skip a lot of data in that case since we will be sending the second hello with the challenge response), and in fact it may be a bad idea: if we somehow end up repeatedly encrypting with the pre-defined IV, we could expose enough information to help break the key.
See AES encryption of files in Python with PyCrypto: in A word about the initialization vector: it suffices to say that the IV is as important as the salt in hashed passwords, and the lack of correct IV usage led to the cracking of the WEP encryption for wireless LAN.
I have also reviewed our use of salt and iv: we use uuid.uuid4, which is fine for this purpose. See Answer to: When are you truly forced to use UUID as part of the design?: Version 4 UUIDs are essentially just 16 bytes of randomness pulled from a cryptographically secure random number generator, with some bit-twiddling to identify the UUID version and variant and Frankly, in a single application space without malicious actors, the extinction of all life on earth will occur long before you have a collision, even on a version 4 UUID, even if you're generating quite a few UUIDs per second.
I think this is good enough for now and we should NOT be encrypting the first packet.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/951