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 ಸಮಯದ ಸಮಸ್ಯೆಗಳ ದೀರ್ಘ ಇತಿಹಾಸ ಹೊಂದಿರುವಂಥವು. ಹೋಸ್ಟ್ ಅತಿಥಿಗೆ AES ಧ್ವಜಗಳನ್ನು ತೋರಿಸದ ವರ್ಚುವಲ್ ಯಂತ್ರದಲ್ಲಿ ಚಲಿಸುವ VPN ಕೇಂದ್ರೀಕರಣಕಾರ ಸರಿಯಾಗಿ ಈ ಸ್ಥಿತಿ, ಮತ್ತು ಹೋಸ್ಟ್ 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 ಧ್ವಜಗಳು ಮರೆಮಾಡಲಾದ ಕಂಟೇನರ್ ಹೋಸ್ಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಹೋಲಿಸಿ, ನಂತರ ಯಾವ ಸೈಫರ್ ನಿಜವಾಗಿ ಮಾತುಕತೆಯಾಯಿತು ಎಂದು ಬರೆದಿಡಿ: ಆ ದಾಖಲೆ ಮಾನದಂಡಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು.