AES-GCM അല്ലെങ്കിൽ ChaCha20-Poly1305: VPN ഡാറ്റ സൈഫർ തിരഞ്ഞെടുക്കൽ

രണ്ട് പേരുകളും 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 ചെലവഴിക്കുന്നു. രണ്ട് നിർമ്മിതികളും ബലഹീനതയല്ല; ചോദ്യം നിങ്ങളുടെ ഹാർഡ്‌വെയർ ഏതിനെ വിലകുറഞ്ഞ് നടപ്പാക്കുന്നു എന്നതാണ്.

നിങ്ങളുടെ പ്രോട്ടോക്കോൾ യഥാർത്ഥത്തിൽ എന്ത് തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു

OpenVPN-ലെ വിഭജനം ശ്രദ്ധിക്കുക: നിയന്ത്രണ ചാനലും ഡാറ്റാ ചാനലും വെവ്വേറെ ചർച്ച ചെയ്യുന്നു, അതിനാൽ TLS-നായി നിങ്ങൾ കാണുന്ന സ്യൂട്ട് നിങ്ങളുടെ പേലോഡ് സംരക്ഷിക്കുന്ന സൈഫറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സെഷൻ സംഗ്രഹം രണ്ടും റിപ്പോർട്ട് ചെയ്യുന്നു, രണ്ടിൽ ഒന്ന് മാത്രം വായിക്കുന്നത് സാധാരണ ആശയക്കുഴപ്പത്തിന്റെ ഉറവിടമാണ്.

OpenVPN-ൽ ഡാറ്റാ ചാനലിന്റെ സൈഫർ ഇരു അറ്റത്തുമുള്ള data-ciphers പട്ടികയിൽ നിന്നാണ് വരുന്നത്. സെർവറിന്റെ പട്ടികയും ക്ലയന്റിന്റെ പട്ടികയും വിഭജിക്കുന്നില്ലെങ്കിൽ കണക്ഷൻ data-ciphers-fallback അനുവദിക്കുന്നതിലേക്ക് പിൻവാങ്ങുന്നു അല്ലെങ്കിൽ പൂർണ്ണമായി പരാജയപ്പെടുന്നു, ആ പരാജയം സാധാരണയായി തെറ്റായ പാളിയിൽ ആരോപിക്കപ്പെടുന്നു. ഇരു വശത്തും ഒരേ പട്ടിക വയ്ക്കുക, തുടർന്ന് പട്ടികയുടെ ക്രമം പാലിച്ചു എന്ന് അനുമാനിക്കുന്നതിന് പകരം ചർച്ച ചെയ്ത ഫലം ലോഗിൽ സ്ഥിരീകരിക്കുക.

വിന്യാസത്തെക്കുറിച്ചുള്ള മൂന്ന് വസ്തുതകളിൽ നിന്ന് തീരുമാനിക്കുക

ഒന്നാമത്, എൻഡ്‌പോയിന്റുകൾക്ക് AES ത്വരണമുണ്ടോ? ഓരോ പങ്കാളിക്കും ഉണ്ടെങ്കിൽ AES-GCM വിലകുറഞ്ഞ തിരഞ്ഞെടുപ്പാണ്, പരിപാലിക്കുന്ന മിക്ക കോൺഫിഗറേഷനുകളിലും സ്ഥിരസ്ഥിതി. ഗണ്യമായ ഭാഗം ചെറിയ റൗട്ടറുകളോ പഴയ ഫോണുകളോ ആണെങ്കിൽ ChaCha20-Poly1305 കൂട്ടത്തിന്റെ വാൽ ശേഷിപ്പരിധിയാകുന്നത് തടയുന്നു.

രണ്ടാമത്, പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പ് വാഗ്ദാനം ചെയ്യുന്നുണ്ടോ? WireGuard-ൽ തീരുമാനം നിങ്ങൾക്കുവേണ്ടി എടുത്തുകഴിഞ്ഞു, ഉപയോഗപ്രദമായ ജോലി അതിനുചുറ്റുമുള്ള ഉപകരണങ്ങൾ നിശബ്ദമായി മറ്റെന്തെങ്കിലും പകരം വയ്ക്കുന്നില്ല എന്ന് പരിശോധിക്കുകയാണ്. OpenVPN, IPsec എന്നിവയിൽ ഉത്തരം ഒരു കോൺഫിഗറേഷൻ വരിയും രേഖപ്പെടുത്തേണ്ട ചർച്ചാ ഫലവുമാണ്.

മൂന്നാമത്, ഇരു അറ്റങ്ങൾക്കും യോജിക്കാമോ? ഒരു പങ്കാളി നടപ്പാക്കാത്ത സൈഫർ പ്രകടനത്തെക്കുറിച്ചുള്ള തീരുമാനമല്ല, അത് തടസ്സമാണ്. അതുകൊണ്ടാണ് പങ്കാളികളുടെ പട്ടിക ഏത് ബെഞ്ച്മാർക്കിനേക്കാളും പ്രധാനമാകുന്നത്: മിശ്രിത കൂട്ടത്തിന് കഴിവുകളുടെ വിഭജനം വേണം, വേഗതയേറിയ യന്ത്രത്തിന്റെ മുൻഗണനയല്ല.

നിങ്ങൾ അളക്കുന്നുവെങ്കിൽ ഉപകരണം, എൻഡ്‌പോയിന്റ്, ഭാരം എന്നിവ ഒരേപോലെ നിർത്തി ഒരു കാര്യം മാറ്റുക. വ്യത്യസ്ത പ്രദേശങ്ങളിലെ രണ്ട് സെർവറുകൾ താരതമ്യം ചെയ്യുന്ന പരീക്ഷണം പാത അളക്കുന്നു, സൈഫറല്ല, ലാപ്‌ടോപ്പിലെ അളവ് CPU ഫ്ലാഗുകൾ മറച്ച കണ്ടെയ്നർ ഹോസ്റ്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. താരതമ്യം ചെയ്യുക, തുടർന്ന് യഥാർത്ഥത്തിൽ ഏത് സൈഫർ ചർച്ച ചെയ്തു എന്ന് എഴുതിവയ്ക്കുക: ആ രേഖ ബെഞ്ച്മാർക്കിനേക്കാൾ മൂല്യമുള്ളതാണ്.