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 പതിപ്പും അത് നിലയുറപ്പിച്ച സ്യൂട്ടും ഉൾപ്പെടുന്നു. ഒരു പ്രൊഫൈൽ മാറ്റം ഈ രണ്ട് ഔട്ട്പുട്ടുകളിൽ ഒന്നുകൊണ്ടും ന്യായീകരിക്കാനാവുന്നില്ലെങ്കിൽ, അത് സവിശേഷതയുടേതല്ല, പേരിന്റെ മാറ്റമാണ്.