The realms of cryptography are plagued with challenges including how to get the best security with the least amount of wait time for the user.
Fundamentally, encryption speed comes down town a couple of factors.
- How many rounds of encryption are required.
- How much data is required per round.
- Block Cipher vs. Stream Cipher.
When discussing symmetric key algorithms, there are two categorical types, block and stream. In fact, you mentioned two in your question: ChaCha20 which is a stream cipher and AES which is a block cipher. The difference comes down to the way the encryption is applied to data (bit by bit or block by block). In the case of ChaCha, it streams data in specific block sizes. Due to the fundamental differences in operation (and light research) ChaCha20 is not based upon AES and wont likely have improved performance from Intel's NI technology.
For more information on ChaCha20 vs AES see here:
https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes
Also related to GCM vs CTR:
https://crypto.stackexchange.com/questions/14747/gcm-vs-ctrhmac-tradeoffs
Moving onto keysize, the bigger the key the more computational strength required to properly perform encryption or decryption. The more data required to perform the encryption will increase your decryption/encryption times. However, by doubling key length, you are exponentially increasing the level of difficulty to crack a key, not merely doubling it. This is why certain researchers may discourage smaller key sizes (such as AES128) and encourage adoption of larger keys (AES 256). It's the same fundamental protocol, but breaking the encryption is much more costly for the attacker.
Going on to the fourth sub question, I would recommend reading the post above on the appeal of ChaCha20 vs AES. Though it is a singular example, it discusses how the mathematics of encryption do not always align with computational process. This is why ChaCha20 can be performed quicker than AES even though it may iterate 20 rounds of encryption instead of ten or more with AES. Summarized, identically sized keys will operate differently based on the ability of the processor to churn through the data based on the mathematical computation required.
Lastly, you asked about the security of the tunnel over all. In reality, a high security payload is better off being encrypted and decrypted before being packaged for transmission to begin with. This will further challenge an attacker because your data security is not compromised if your network channel is; even if a man in the middle attack is successful.
As a security architect, my job is to determine what the "right" level of security is for a business process. This turns out a high number of variables including what the potential risk factor is, cost to the company in the event of breach, perceived valued of the data, cost to mitigate, and more. If you're trying to protect a public share, then a lighter security scheme is required than if you're protecting a security data lake. Being able to account for the business and technical requirements will help dictate your needs.
In your example of a file share, if speed of access and least impact to network are of highest importance, then a smaller encryption key size and lightweight cipher will benefit your business use case. If you're trying to prevent loss of sensitive data, then increasing key size and even choosing a slower algorithm may be justified. The point is that the "right" encryption may be different depending on your use case, even within the same company.
