AES v2

[totaam]

Splitting from #4372 because there are just too many issues that simply cannot be fixed without breaking backwards compatibility.
Adding new flags only gets you so far, and makes the code very hard to understand and maintain.

• increase minimum number of iterations for PBKDF2 to 100000? (441c3da + 9314110 keep backwards compatibility)
• perhaps also support / switch-to Bcrypt
• always use correct PKCS#7 padding (d5d88b8)
• keep the same IV for chunks of the same packet? (how? using a header flag? conflicts with encrypting the whole packet?)
• actually verify the tag with GCM - requires a new IV for every packet
• encrypt then MAC: add HMAC to CBC? using a different key: AES-GCM vs. AES-CBC: You should also devise some sort of key-separation mechanism so you’re not using the same key for two different algorithms
• use a secure compare function for MAC
• drop CTR? AES-GCM vs. AES-CTR: Just use AES-GCM. No contest.
• support a better block cipher than AES: ChaCha20?
• switch to bytes for IV (continuation of 6888621)
• per-mode IV size: 12 bytes for GCM, 16 for CBC, etc
• the encryptor should choose the (random) IV and not use the one supplied in a plain text packet - see non-random IV
• encrypt the whole packet, including the header
• support for always encrypting the first packet by sending the IV with it - this causes an issue with proxy servers and end-to-end encryption - this requires opportunistic switch to encrypted connections, which has to be enforced by the client requesting it
• support re-keying - even if this is not a real issue to be concerned with right now for CBC or GCM
• also update the html5 client, again: use native API for AES xpra-html5#314 (and keep its API limitations in mind)
• consider Authenticated Key Exchanges like SPEKE - originally discussed in protect against mitm attacks #198 (comment) (back in 2012!) or the one chosen by IETF: CPACE