OpenVPN EC vs ED: આ નામો તાકાતની સીડી કેમ નથી
EC, ED, ECDHE અને auth અલગ અલગ પ્રશ્નોના જવાબ આપે છે. કંઈપણ સરખાવે કે સંપાદિત કરે તે પહેલાં OpenVPN પ્રોફાઇલને દરેક નામ જે કામ કરે તે પ્રમાણે ગોઠવો.
એક પ્રોફાઇલમાં ec, ed, ecdh, ecdsa, auth અને TLS સાઇફરની યાદી એકબાજુ ગોઠવો, અને ફાઇલ છ સ્થિતિવાળા તાકાત-ડાયલ જેવી લાગવા લાગે છે. પણ એવું નથી. દરેક નામ અલગ પ્રશ્નનો જવાબ આપે છે, અને જે બે પ્રોફાઇલ તેમાંથી એકમાં અલગ પડે છે તે જરૂરી નથી કે એકબીજાથી વધુ મજબૂત કે નબળા હોય. નામોને તેમના કામ પ્રમાણે ગોઠવવામાં લગભગ પાંચ મિનિટ લાગે છે અને ચાલતી ગોઠવણીમાં લોકો કરતા મોટા ભાગના ખરાબ ફેરફારો અટકાવે છે.
નીચેની ગોઠવણી ગૂંચવણથી જ શરૂ થાય છે, પછી બહારની તરફ પ્રોફાઇલના એ ભાગો તરફ જાય છે જે ખરેખર નક્કી કરે છે કે તમારા ટ્રાફિકને શું બચાવે છે. દરેક વિભાગ વારાફરતી એક ખોટું વાંચન લે છે અને બતાવે છે કે નામ ખરેખર શેની સાથે જોડાયેલું છે.
બે અક્ષર, બે અલગ પ્રશ્નો
સૌથી વધુ ચર્ચા ઊભી કરતી જોડી EC અને ED છે, અને ચર્ચા સામાન્ય રીતે ધારે છે કે તે એક જ પ્રશ્નના હરીફ જવાબો છે. તેઓ એક જ ધરી પર પણ નથી. EC ગણિતના એક કુટુંબનું વર્ણન કરે છે: લંબવૃત્તીય વક્ર ક્રિપ્ટોગ્રાફી, જ્યાં સુરક્ષા મોટા પરિમિત ક્ષેત્રમાં નહીં પણ વક્ર પરના વિવિક્ત લઘુગણકની મુશ્કેલીમાંથી આવે છે.
ED તે કુટુંબની અંદરના વક્રના આકારનું વર્ણન કરે છે. Twisted Edwards વક્ર એ ઝડપ અને અમલીકરણની ઘણી ભૂલો સામે પ્રતિકાર માટે પસંદ કરાયેલી રજૂઆત છે, અને Ed25519 એ નામ છે જે લોકો સામાન્ય રીતે ધારે છે. વક્ર લંબવૃત્તીય વક્ર ક્રિપ્ટોગ્રાફીનો હરીફ નથી; તે લંબવૃત્તીય વક્ર લખવાની એક રીત છે. ED ને "નવું, વધુ મજબૂત EC" તરીકે વાંચવું એ પહેલું ખોટું વળાંક છે, અને તેના પછીનું બધું એ જ દિશામાં ખોટું હોવાની શક્યતા છે.
સહી કરવી અને અદલાબદલી કરવી અલગ કામો છે
કુટુંબનો પ્રશ્ન નક્કી થયા પછી, બાકીનાં નામો બે કોલમમાં વિભાજિત થાય છે જે કદી એકબીજાનું સ્થાન લેતા નથી. એક કોલમ સહી કરે છે, બીજી વહેંચાયેલા ગુપ્ત પર સંમત થાય છે.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA અને ECDSA બંને સહી કરે છે, પણ તે અલગ કી ફોર્મેટવાળી અલગ સ્કીમ છે, તેથી એક માટે જારી કરેલું પ્રમાણપત્ર બીજા તરીકે વાપરી શકાતું નથી. EdDSA થોડા વક્રોના સમૂહ માટે વ્યાખ્યાયિત છે; P-256 તેમાંનું એક નથી, તેથી P-256 પ્રમાણપત્ર ECDSA સાથે ચકાસાય છે અને કદી Ed25519 સાથે નહીં.
અદલાબદલી કોલમમાં EdDH નામનું કોઈ સમાનાર્થી નથી. Curve25519 કી પરનો ક્ષણિક કરાર X25519 છે, અને તે ચોક્કસ વક્ર સાથેનું ECDH છે, P-256 સાથે જેમ છે તેમ જ. Ed25519 કડક રીતે સહી સ્કીમ દર્શાવે છે, જોકે આ નામ અદલાબદલી માટે ઢીલી રીતે વપરાય છે કારણ કે બંને વક્ર સંબંધિત છે: સહી માટે વપરાતું Edwards સ્વરૂપ અને X25519 માટે વપરાતું Montgomery સ્વરૂપ એ જ અંતર્ગત ગણનું વર્ણન કરે છે.
EC પ્રોફાઇલમાં dh ફાઇલ કેમ નથી
dh ફાઇલમાં પરિમિત ક્ષેત્ર Diffie-Hellman માટે પહેલેથી બનાવેલા પરિમાણો હોય છે, અને એ પરિમાણો એટલા માટે છે કે મોટી અવિભાજ્ય સંખ્યા અને જનરેટર ક્યાંકથી આવવા જોઈએ. લંબવૃત્તીય વક્રની અદલાબદલીને તેની જરૂર નથી: નામવાળું વક્ર જ પરિમાણ-સમૂહ છે, અને બંને પક્ષ તેને પહેલેથી જાણે છે. EC પ્રોફાઇલ સૂચના છોડી શકે તેનું આ આખું કારણ છે.
બે પરિસ્થિતિઓ હજી પણ બીજી રીતે આધુનિક દેખાતી પ્રોફાઇલમાં dh લીટી પેદા કરે છે. પહેલી છે બીજો શ્રોતા કે જૂનો સાથી જે ખરેખર પરિમિત ક્ષેત્રના ગણ પર વાટાઘાટ કરે છે. બીજી છે RSA યુગના નમૂનામાંથી કૉપી કરેલો અને કદી દૂર ન કરેલો બાકી રહેલો ટેક્સ્ટ. જે પ્રોફાઇલ અદલાબદલી માટે વક્રનું નામ આપે છે અને છતાં 2048-બિટ dh ફાઇલ લોડ કરે છે તે એ કર્યા બદલ વધુ સુરક્ષિત નથી; તે ન વપરાયેલી વસ્તુ ઉપાડી રહ્યું છે.
TLS 1.3 એ નામમાંથી કી અદલાબદલી દૂર કરી
TLS_AES_256_GCM_SHA384 ની TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 સાથે સરખામણી કરો અને ટૂંકું નામ નીચાણ જેવું લાગે છે. તે નામ બદલવું છે, અને કારણ માળખાકીય છે: TLS 1.3 એ સ્થિર RSA અને પરિમિત ક્ષેત્ર Diffie-Hellman કી અદલાબદલી દૂર કરી, તેથી ક્ષણિક લંબવૃત્તીય વક્રની અદલાબદલી જ બાકી રહેલો એકમાત્ર બિન-PSK વિકલ્પ છે. દરેક સ્યૂટમાં તેનું નામ આપવું એ જ હકીકત ડઝન વાર પુનરાવર્તિત કરશે.
પ્રમાણપત્રનો પ્રકાર સંબંધિત કારણસર નામમાંથી અદૃશ્ય થયો. 1.3 માં પ્રમાણપત્ર હેન્ડશેકની સહીની પ્રમાણિકતા ચકાસે છે, કી કરારની નહીં, તેથી તે હવે સ્યૂટ પસંદ કરતું નથી. એટલે જ ગોઠવણીમાં 1.3 માટે અલગ સાઇફર યાદી છે: સ્યૂટનાં નામ બદલાયાં અને ફરી ગોઠવાયાં, નબળાં કરાયાં નહીં.
એક પરિણામ સ્પષ્ટ કહેવા જેવું છે. ECDHE કી અદલાબદલીનું અલ્ગોરિધમ છે અને કદી સાઇફર નથી. "લંબવૃત્તીય" તરીકે વર્ણવાયેલું સ્યૂટ બે સાથીઓ સહિયારી કી સુધી કેવી રીતે પહોંચ્યા તે વિશે કંઈક કહે છે, અને પછી પેલોડને શું એન્ક્રિપ્ટ કરે છે તે વિશે કંઈ જ નહીં.
auth પેકેટની પ્રમાણિકતા ચકાસે છે, પેલોડની નહીં
auth સૂચના એ HMAC ડાયજેસ્ટ પસંદ કરે છે જે પેકેટની પ્રમાણિકતા ચકાસે છે, અને તેનું ઐતિહાસિક મૂળભૂત મૂલ્ય SHA1 છે. બિન-AEAD ડેટા સાઇફર સાથે OpenVPN સાઇફરટેક્સ્ટ પર ડાયજેસ્ટ ગણે છે અને તેને જોડે છે, એન્ક્રિપ્ટ-પછી-MAC ગોઠવણી જે પેડિંગ સાથે ચેડાં કરવાનું અવ્યવહારુ બનાવે છે.
અહીં દંતકથા એ છે કે auth ને SHA512 સુધી વધારવાથી ટનલ મજબૂત થાય છે. તે એન્ક્રિપ્શનની તાકાત વધારતું નથી, અને જો વાટાઘાટ કરેલો ડેટા સાઇફર AES-256-GCM જેવો AEAD મોડ હોય, તો ડાયજેસ્ટ ડેટા પેકેટ પર બિલકુલ લાગુ થતું નથી. GCM ટેગ પહેલેથી તેમની પ્રમાણિકતા ચકાસે છે, અને auth મૂલ્ય કંટ્રોલ-ચેનલના HMAC અને હજી વપરાતા કોઈપણ બિન-AEAD સાઇફર માટે રહે છે.
તેથી સૂચના મહત્વની છે, પણ ફાઇલમાં તેની જગ્યા સૂચવે તેના કરતાં સાંકડી જગ્યાએ મહત્વની છે. ખરેખર કયો સાઇફર વાટાઘાટ થયો તે તપાસવાથી ખબર પડે કે તે બિલકુલ લાગુ પડે છે કે નહીં.
પ્રોફાઇલ કોલમ પ્રમાણે વાંચો, ક્રમ પ્રમાણે નહીં
ત્રણ પ્રશ્નો સ્તરોને સ્વચ્છ રીતે અલગ પાડે છે, અને દરેકનો જવાબ વાટાઘાટ કરેલા સત્રનો અલગ ભાગ આપે છે. કયો સાઇફર પેલોડને બચાવે છે? કયો ટેગ કે ડાયજેસ્ટ દરેક પેકેટની ખાતરી આપે છે, અને વપરાતા સાઇફરને એની બિલકુલ જરૂર છે? કોના પ્રમાણપત્રે હેન્ડશેક બંધ કર્યો, અને કંટ્રોલ ચેનલ વધુમાં tls-auth કે tls-crypt દ્વારા સુરક્ષિત છે?
EC કે ED લેબલમાં કંઈ પણ એ ત્રણમાંથી એકેય નક્કી કરતું નથી, અને સ્યૂટનું નામ એકલું પણ તેમાંથી એકેય નક્કી કરતું નથી. વાટાઘાટ કરેલું પરિણામ જ એકમાત્ર પુરાવો છે, તેથી શબ્દભંડોળમાંથી તાકાત અનુમાન કરવાને બદલે તેને વાંચો:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logપહેલો આદેશ તમને કહે છે કે તમારું પ્રમાણપત્ર ખરેખર કઈ સહી સ્કીમ વાપરે છે, અને તમે ECDSA ચલાવી રહ્યા છો કે Ed25519 તે જાણવાનો આ એકમાત્ર ભરોસાપાત્ર રસ્તો છે. બીજો ક્લાયન્ટે સત્ર માટે નોંધેલી કંટ્રોલ-ચેનલ લીટી બતાવે છે, જેમાં TLS આવૃત્તિ અને જે સ્યૂટ પર તે સ્થિર થયું તેનો સમાવેશ થાય છે. જો પ્રોફાઇલનો ફેરફાર એ બે આઉટપુટમાંથી એકથી પણ વાજબી ઠરે નહીં, તો તે કદાચ ગુણધર્મનો નહીં પણ નામનો ફેરફાર છે.