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-ը
AES-ն ունի հատուկ հրահանգներ ժամանակակից պրոցեսորների մեծ մասում․ AES-NI՝ x86-ի վրա, գաղտնագրման ընդլայնումները՝ ARMv8-ի վրա, և համարժեքներ՝ վերջին POWER և RISC-V նախագծերում։ Երբ դրանք կան, GCM-ը մի քանի բլոկ է գործարկում զուգահեռաբար յուրաքանչյուր ցիկլի դասի համար, և ծրագրային իրականացումն անկարևոր է դառնում։ Սա սովորական դեպք է սերվերների, աշխատանքային կայանների և ընթացիկ հեռախոսների համար, և դրա համար է, որ տվյալների կենտրոնում AES օգտագործելու խորհուրդը ողջամիտ լռելյայն է։
Խնդիրը երկրորդ կարգի դեպքն է։ Առանց հատուկ հրահանգների AES-ը ծրագրային միջավայրում դանդաղ է, և աղյուսակներով ղեկավարվող ծրագրային իրականացումներն են նրանք, որոնք ունեն cache-ի ժամանակի խնդիրների երկար պատմություն։ Վիրտուալ մեքենայում աշխատող VPN կենտրոնացուցիչը, որի հոսթը հյուրին չի ցուցադրում AES դրոշակներ, հենց այս դեպքն է, և այն հեշտ է բաց թողնել, քանի որ հոսթի պրոցեսորն ունի այդ հատկությունը։
Ստուգեք, թե ինչ է իրականում տեսնում գործընթացը, ոչ թե ինչ է աջակցում պրոցեսորը․ grep -o aes /proc/cpuinfo | head -1 Linux-ում, կամ համարժեք հատկության դրոշակը հիպերվիզորի պրոցեսորի մոդելում։
Որտեղ հաղթում է ChaCha20-Poly1305-ը
ChaCha20-ը արագ է տեղափոխելի ծրագրաշարում, քանի որ օգտագործում է միայն գումարում, պտտում և XOR, և դրա իրականացումները նախագծով խուսափում են գաղտնիքից կախված աղյուսակային որոնումներից։ Առանց AES արագացման սարքում դա նյութական առավելություն է, և դրա համար է, որ WireGuard-ն ընտրեց այն․ WireGuard արձանագրության նկարագրությունը ChaCha20-Poly1305-ը նշում է որպես իր տվյալների գաղտնագրում՝ առանց այլընտրանքի։
Այդ մեկ ընտրությունը օգտակար բան է ասում․ այն ապարատում, որտեղ AES-ը արագացված է, WireGuard-ը զիջում է որոշակի թողունակություն AES-GCM-ի համեմատ, և դրա հեղինակները դա ընդունել են հեռախոսներում, տնային երթուղիչներում և կոնտեյներային հոսթերում կանխատեսելի վարքագծի դիմաց։ Եթե ձեր պարկը հիմնականում փոքր ARM արկղեր են, այդ փոխանակումը ձեր օգտին է։
Հակառակ դեպքը զբաղված x86 կենտրոնացուցիչն է, որտեղ AES-NI-ով AES-GCM-ը ավելի արագ և ավելի լավ աջակցվող ուղին է, և որտեղ ChaCha20-ը ծախսում է չափելի պրոցեսոր յուրաքանչյուր գիգաբիթի համար։ Կառուցվածքներից ոչ մեկը թուլություն չէ․ հարցն այն է, թե ձեր ապարատը որն է կատարում էժան։
Ինչ է ձեր արձանագրությունը իրականում թույլ տալիս ընտրել
| 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-ի դեպքում պատասխանը կարգավորման տողն է և գրանցվող բանակցված արդյունքը։
Երրորդ, կարո՞ղ են երկու կողմերը համաձայնության գալ։ Գաղտնագրումը, որը գործընկերներից մեկը չի իրականացնում, կատարողականության որոշում չէ, դա ընդհատում է։ Այդ պատճառով գործընկերների ցանկը ավելի կարևոր է, քան ցանկացած չափում․ խառը պարկին պետք է հնարավորությունների հատում, ոչ թե ամենաարագ մեքենայի նախապատվությունը։
Եթե չափեք, պահեք սարքը, վերջնակետը և բեռը նույնը և փոխեք մեկ բան։ Երկու տարբեր տարածաշրջանների սերվերներ համեմատող թեստը չափում է երթուղին, ոչ թե գաղտնագրումը, և նոթբուքի չափումը ոչինչ չի ասում կոնտեյներային հոսթի մասին, որի պրոցեսորի դրոշակները քողարկված են։ Համեմատեք, ապա գրի առեք, թե որ գաղտնագրումն է իրականում բանակցվել․ այդ գրառումն ավելի արժեքավոր է, քան չափումը։