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 జెండాలు కప్పబడిన కంటైనర్ హోస్ట్ గురించి ఏమీ చెప్పదు. పోల్చండి, తర్వాత నిజంగా ఏ సైఫర్ చర్చించబడిందో రాసి ఉంచండి: ఆ నమోదు కొలత కంటే విలువైనది.