AES-GCM ਜਾਂ ChaCha20-Poly1305: VPN ਡੇਟਾ ਸਾਈਫਰ ਦੀ ਚੋਣ
ਹਾਰਡਵੇਅਰ ਤਵਰਣ ਵਾਲੇ ਸਰਵਰਾਂ ਉੱਤੇ AES-GCM ਸਪਸ਼ਟ ਚੋਣ ਹੈ, ਅਤੇ ChaCha20-Poly1305 ਉਸ ਤੋਂ ਬਿਨਾਂ ਵੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲਦਾ ਹੈ। ਹੋ ਸਕਦਾ ਹੈ ਤੁਹਾਡਾ ਪ੍ਰੋਟੋਕੋਲ ਤੁਹਾਡੇ ਲਈ ਫੈਸਲਾ ਕਰੇ।
ਦੋਵੇਂ ਨਾਮ AEAD ਬਣਤਰਾਂ ਹਨ, ਦੋਵੇਂ ਮਾਨਕੀਕ੍ਰਿਤ ਹਨ, ਅਤੇ ਮੌਜੂਦਾ x86 ਸਰਵਰ ਉੱਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦਿਸਣ ਵਾਲੀ ਮਿਹਨਤ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਗੀਗਾਬਿਟ ਲਿੰਕ ਭਰ ਦੇਵੇਗਾ। ਉਸ ਸਰਵਰ ਤੋਂ ਬਾਹਰ ਜਾਣ ’ਤੇ ਹੀ ਚੋਣ ਮਨਮਾਨੀ ਰਹਿਣੀ ਬੰਦ ਹੁੰਦੀ ਹੈ: ਸਸਤੇ ਰਾਊਟਰ, ਪੁਰਾਣੇ ਫੋਨ ਅਤੇ ਵਰਚੁਅਲ ਯੰਤਰਾਂ ਵਿੱਚ ਅਕਸਰ AES ਤਵਰਣ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਉੱਥੇ ਫ਼ਰਕ ਵੱਡਾ ਹੈ। ਇਸ ਲਈ ਤੁਲਨਾ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਸਾਈਫਰ ਤੇਜ਼ ਹੈ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਸਾਈਫਰ ਇਸ ਅੰਤਿਮ ਬਿੰਦੂ ਸਮੂਹ ਉੱਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਚੋਣ ਦਿੰਦਾ ਵੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇੱਕੋ ਕੰਮ, ਵੱਖਰੇ ਕੋਰ
ਦੋਵੇਂ ਬਣਤਰਾਂ ਇੱਕ ਪਾਸ ਵਿੱਚ ਗੋਪਨੀਯਤਾ ਅਤੇ ਅਖੰਡਤਾ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਸੰਬੰਧਿਤ ਡੇਟਾ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ VPN ਪ੍ਰੋਟੋਕੋਲ ਉਹਨਾਂ ਨੂੰ ਡੇਟਾ ਚੈਨਲ ਲਈ ਵਰਤਦੇ ਹਨ। ਫ਼ਰਕ ਅੰਦਰ ਹੈ: AES-GCM ਕਾਊਂਟਰ ਮੋਡ ਵਿੱਚ AES ਬਲਾਕ ਸਾਈਫਰ ਹੈ ਜਿਸ ਵਿੱਚ GF(2^128) ਉੱਤੇ ਬਹੁਪਦ ਪ੍ਰਮਾਣਕ ਹੈ, ਜਦਕਿ ChaCha20-Poly1305 256 ਬਿੱਟ ਕੁੰਜੀ ਵਾਲਾ ਸਟ੍ਰੀਮ ਸਾਈਫਰ ਹੈ ਜਿਸ ਵਿੱਚ ਵੱਖਰਾ ਇੱਕ-ਵਾਰ ਪ੍ਰਮਾਣਕ ਹੈ।
ਕਾਰਜਸ਼ੀਲ ਤੌਰ ’ਤੇ ਜ਼ਰੂਰੀ ਗੱਲ ਸਾਂਝੀ ਹੈ: ਦੋਵੇਂ nonce ਦੁਬਾਰਾ ਵਰਤਣ ’ਤੇ ਭਿਆਨਕ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਦੋਵਾਂ ਨੂੰ ਹਰ ਕੁੰਜੀ ਲਈ nonce ਥਾਂ ਦਾ ਪ੍ਰਬੰਧ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਗ਼ਲਤ ਚੀਜ਼ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਵਾਲੇ ਸਾਥੀ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। AES-256-GCM ਕਹਿਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ CHACHA20-POLY1305 ਕਹਿਣ ਵਾਲੇ ਤੋਂ ਵੱਧ ਸੁਰੱਖਿਅਤ ਨਹੀਂ; ਲਾਗੂਆਤ ਸਹੀ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਮਜ਼ਬੂਤ ਹਨ।
AES-GCM ਕਿੱਥੇ ਜਿੱਤਦਾ ਹੈ
ਬਹੁਤੇ ਆਧੁਨਿਕ CPU ਉੱਤੇ AES ਲਈ ਸਮਰਪਿਤ ਹਦਾਇਤਾਂ ਹਨ: x86 ਉੱਤੇ AES-NI, ARMv8 ਉੱਤੇ ਕ੍ਰਿਪਟੋ ਵਿਸਤਾਰ, ਅਤੇ ਹਾਲੀਆ POWER ਤੇ RISC-V ਡਿਜ਼ਾਈਨਾਂ ਉੱਤੇ ਬਰਾਬਰ ਦੀਆਂ। ਜਦੋਂ ਇਹ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ GCM ਪ੍ਰਤੀ ਚੱਕਰ ਸ਼੍ਰੇਣੀ ਕਈ ਬਲਾਕ ਸਮਾਨਾਂਤਰ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਸਾਫ਼ਟਵੇਅਰ ਲਾਗੂਆਤ ਬੇਮਤਲਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਸਰਵਰਾਂ, ਡੈਸਕਟਾਪਾਂ ਅਤੇ ਮੌਜੂਦਾ ਫੋਨਾਂ ਲਈ ਆਮ ਹਾਲਤ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ AES ਵਰਤੋ ਸਲਾਹ ਵਾਜਬ ਡਿਫਾਲਟ ਹੈ।
ਸਮੱਸਿਆ ਦੂਜੇ ਦਰਜੇ ਦੀ ਹਾਲਤ ਹੈ। ਸਮਰਪਿਤ ਹਦਾਇਤਾਂ ਤੋਂ ਬਿਨਾਂ ਸਾਫ਼ਟਵੇਅਰ ਵਿੱਚ AES ਹੌਲੀ ਹੈ, ਅਤੇ ਸਾਰਣੀ-ਅਧਾਰਿਤ ਸਾਫ਼ਟਵੇਅਰ ਲਾਗੂਆਤਾਂ ਹੀ ਉਹ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ cache-ਸਮੇਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਲੰਮਾ ਇਤਿਹਾਸ ਹੈ। ਜਿਸ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਚੱਲ ਰਹੇ VPN ਕੇਂਦਰ ਦਾ ਹੋਸਟ ਮਹਿਮਾਨ ਨੂੰ AES ਝੰਡੇ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਉਹ ਠੀਕ ਇਹੀ ਹਾਲਤ ਹੈ, ਅਤੇ ਹੋਸਟ CPU ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਹੋਣ ਕਰਕੇ ਇਹ ਸੌਖਿਆਂ ਖੁੰਝ ਜਾਂਦੀ ਹੈ।
CPU ਕੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਨਹੀਂ, ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਕੀ ਵੇਖਦੀ ਹੈ ਜਾਂਚੋ: Linux ਉੱਤੇ grep -o aes /proc/cpuinfo | head -1, ਜਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇ CPU ਮਾਡਲ ਵਿੱਚ ਬਰਾਬਰ ਦਾ ਵਿਸ਼ੇਸ਼ਤਾ ਝੰਡਾ।
ChaCha20-Poly1305 ਕਿੱਥੇ ਜਿੱਤਦਾ ਹੈ
ChaCha20 ਢੋਣਯੋਗ ਸਾਫ਼ਟਵੇਅਰ ਵਿੱਚ ਤੇਜ਼ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਜੋੜ, ਘੁਮਾਓ ਅਤੇ XOR ਵਰਤਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀਆਂ ਲਾਗੂਆਤਾਂ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਭੇਤ ’ਤੇ ਨਿਰਭਰ ਸਾਰਣੀ ਖੋਜ ਤੋਂ ਬਚਦੀਆਂ ਹਨ। AES ਤਵਰਣ ਤੋਂ ਬਿਨਾਂ ਯੰਤਰ ਉੱਤੇ ਇਹ ਠੋਸ ਲਾਭ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ WireGuard ਨੇ ਇਹ ਚੁਣਿਆ: WireGuard ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਵੇਰਵਾ ChaCha20-Poly1305 ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲ ਦੇ ਇਸ ਦਾ ਡੇਟਾ ਸਾਈਫਰ ਦੱਸਦਾ ਹੈ।
ਉਹ ਇੱਕ ਚੋਣ ਲਾਹੇਵੰਦ ਗੱਲ ਕਹਿੰਦੀ ਹੈ: AES ਤਵਰਿਤ ਹਾਰਡਵੇਅਰ ਉੱਤੇ WireGuard AES-GCM ਦੇ ਮੁਕਾਬਲੇ ਕੁਝ ਥ੍ਰੂਪੁਟ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਲੇਖਕਾਂ ਨੇ ਫੋਨ, ਘਰੇਲੂ ਰਾਊਟਰ ਅਤੇ ਕੰਟੇਨਰ ਹੋਸਟਾਂ ਉੱਤੇ ਅੰਦਾਜ਼ਾਯੋਗ ਵਿਵਹਾਰ ਦੇ ਬਦਲੇ ਇਹ ਸਵੀਕਾਰ ਕੀਤਾ। ਜੇ ਤੁਹਾਡਾ ਬੇੜਾ ਮੁੱਖ ਤੌਰ ’ਤੇ ਛੋਟੇ ARM ਡੱਬੇ ਹਨ ਤਾਂ ਉਹ ਵਟਾਂਦਰਾ ਤੁਹਾਡੇ ਪੱਖ ਵਿੱਚ ਹੈ।
ਉਲਟ ਹਾਲਤ ਵਿਅਸਤ x86 ਕੇਂਦਰ ਹੈ, ਜਿੱਥੇ AES-NI ਨਾਲ AES-GCM ਤੇਜ਼ ਅਤੇ ਬਿਹਤਰ ਸਮਰਥਿਤ ਰਾਹ ਹੈ, ਅਤੇ ਜਿੱਥੇ ChaCha20 ਪ੍ਰਤੀ ਗੀਗਾਬਿਟ ਮਾਪਣਯੋਗ CPU ਖ਼ਰਚਦਾ ਹੈ। ਕੋਈ ਵੀ ਬਣਤਰ ਕਮਜ਼ੋਰੀ ਨਹੀਂ; ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਹਾਰਡਵੇਅਰ ਕਿਹੜੀ ਸਸਤੇ ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ।
ਤੁਹਾਡਾ ਪ੍ਰੋਟੋਕੋਲ ਅਸਲ ਵਿੱਚ ਕੀ ਚੁਣਨ ਦਿੰਦਾ ਹੈ
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
OpenVPN ਵਿੱਚ ਵੰਡ ਵੱਲ ਧਿਆਨ ਦਿਓ: ਕੰਟਰੋਲ ਚੈਨਲ ਅਤੇ ਡੇਟਾ ਚੈਨਲ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਗੱਲਬਾਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ TLS ਲਈ ਤੁਸੀਂ ਜੋ ਸੂਟ ਵੇਖਦੇ ਹੋ ਉਹ ਤੁਹਾਡੇ ਪੇਲੋਡ ਦੀ ਰੱਖਿਆ ਕਰਨ ਵਾਲੇ ਸਾਈਫਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਸੈਸ਼ਨ ਸਾਰ ਦੋਵੇਂ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪੜ੍ਹਨਾ ਉਲਝਣ ਦਾ ਆਮ ਸਰੋਤ ਹੈ।
OpenVPN ਵਿੱਚ ਡੇਟਾ ਚੈਨਲ ਦਾ ਸਾਈਫਰ ਦੋਵਾਂ ਸਿਰਿਆਂ ਦੀ data-ciphers ਸੂਚੀ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਦੀ ਸੂਚੀ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਸੂਚੀ ਨਹੀਂ ਮਿਲਦੀਆਂ ਤਾਂ ਕਨੈਕਸ਼ਨ ਜਾਂ ਤਾਂ data-ciphers-fallback ਜੋ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਉਸ ਵੱਲ ਮੁੜਦਾ ਹੈ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਫੇਲ੍ਹ ਆਮ ਤੌਰ ’ਤੇ ਗ਼ਲਤ ਪਰਤ ਉੱਤੇ ਮੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਪਾਸੇ ਇੱਕੋ ਸੂਚੀ ਰੱਖੋ, ਫਿਰ ਸੂਚੀ ਦਾ ਕ੍ਰਮ ਮੰਨਿਆ ਗਿਆ ਮੰਨਣ ਦੀ ਥਾਂ ਲਾਗ ਵਿੱਚ ਗੱਲਬਾਤ ਦਾ ਨਤੀਜਾ ਪੱਕਾ ਕਰੋ।
ਤੈਨਾਤੀ ਬਾਰੇ ਤਿੰਨ ਤੱਥਾਂ ਤੋਂ ਫ਼ੈਸਲਾ ਕਰੋ
ਪਹਿਲਾ, ਅੰਤਿਮ ਬਿੰਦੂਆਂ ਵਿੱਚ AES ਤਵਰਣ ਹੈ? ਜੇ ਹਰ ਸਾਥੀ ਕੋਲ ਹੈ ਤਾਂ AES-GCM ਸਸਤੀ ਚੋਣ ਅਤੇ ਬਹੁਤੀਆਂ ਸੰਭਾਲੀਆਂ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਡਿਫਾਲਟ ਹੈ। ਜੇ ਕਾਫ਼ੀ ਹਿੱਸਾ ਛੋਟੇ ਰਾਊਟਰ ਜਾਂ ਪੁਰਾਣੇ ਫੋਨ ਹਨ ਤਾਂ ChaCha20-Poly1305 ਬੇੜੇ ਦੀ ਪੂਛ ਨੂੰ ਸਮਰੱਥਾ ਦੀ ਹੱਦ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਦੂਜਾ, ਪ੍ਰੋਟੋਕੋਲ ਚੋਣ ਦਿੰਦਾ ਵੀ ਹੈ? WireGuard ਨਾਲ ਫ਼ੈਸਲਾ ਤੁਹਾਡੇ ਲਈ ਲਿਆ ਜਾ ਚੁੱਕਾ ਹੈ, ਅਤੇ ਲਾਹੇਵੰਦ ਕੰਮ ਇਹ ਜਾਂਚਣਾ ਹੈ ਕਿ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਾਧਨ ਚੁੱਪਚਾਪ ਕੁਝ ਹੋਰ ਨਹੀਂ ਰੱਖ ਰਹੇ। OpenVPN ਅਤੇ IPsec ਨਾਲ ਜਵਾਬ ਇੱਕ ਸੰਰਚਨਾ ਲਾਈਨ ਅਤੇ ਦਰਜ ਕਰਨ ਯੋਗ ਗੱਲਬਾਤ ਨਤੀਜਾ ਹੈ।
ਤੀਜਾ, ਕੀ ਦੋਵੇਂ ਸਿਰੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ? ਜਿਸ ਸਾਈਫਰ ਨੂੰ ਇੱਕ ਸਾਥੀ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ ਉਹ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ, ਰੁਕਾਵਟ ਹੈ। ਇਸੇ ਲਈ ਸਾਥੀਆਂ ਦੀ ਸੂਚੀ ਕਿਸੇ ਵੀ ਬੈਂਚਮਾਰਕ ਤੋਂ ਵੱਧ ਜ਼ਰੂਰੀ ਹੈ: ਮਿਸ਼ਰਤ ਬੇੜੇ ਨੂੰ ਸਮਰੱਥਾਵਾਂ ਦਾ ਕੱਟ ਚਾਹੀਦਾ ਹੈ, ਸਭ ਤੋਂ ਤੇਜ਼ ਮਸ਼ੀਨ ਦੀ ਪਸੰਦ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਮਾਪਦੇ ਹੋ ਤਾਂ ਯੰਤਰ, ਅੰਤਿਮ ਬਿੰਦੂ ਅਤੇ ਭਾਰ ਇੱਕੋ ਰੱਖੋ ਅਤੇ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ। ਵੱਖਰੇ ਖੇਤਰਾਂ ਦੇ ਦੋ ਸਰਵਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵਾਲਾ ਪਰਖ ਰਾਹ ਮਾਪਦਾ ਹੈ, ਸਾਈਫਰ ਨਹੀਂ, ਅਤੇ ਲੈਪਟਾਪ ਬੈਂਚਮਾਰਕ ਉਸ ਕੰਟੇਨਰ ਹੋਸਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜਿਸ ਦੇ CPU ਝੰਡੇ ਢਕੇ ਹੋਏ ਹਨ। ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਲਿਖ ਕੇ ਰੱਖੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਾਈਫਰ ਤੈਅ ਹੋਇਆ: ਉਹ ਰਿਕਾਰਡ ਬੈਂਚਮਾਰਕ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ।