CFB1, CFB8, CFB128 എന്നിവ തമ്മിലുള്ള വ്യത്യാസം കീ വലുപ്പമല്ല, ഫീഡ്ബാക്ക് വലുപ്പമാണ്

AES-256-CFB1 പോലുള്ള ഒരു പേരിൽ രണ്ട് സംഖ്യകളുണ്ട്, അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. 256 എന്നത് AES കീയുടെ നീളമാണ്. 1 എന്നത് CFB ഫീഡ്ബാക്ക്, അതായത് സെഗ്മെന്റ് വലുപ്പം, മോഡ് സ്വന്തം അവസ്ഥ എങ്ങനെ മുന്നോട്ട് കൊണ്ടുപോകുന്നു എന്നതിന്റെ സ്വഭാവം. 1-നെ കീ നീളമായി വായിച്ചാൽ പേര് ദുരന്തകരമായ തെറ്റായ ക്രമീകരണം പോലെ തോന്നും, അതുകൊണ്ടാണ് ഈ ചോദ്യം വീണ്ടും വീണ്ടും വരുന്നത്.

പേര് വിലയിരുത്തുന്നതിന് മുൻപ് നിങ്ങൾ മൂന്ന് അളവുകളിൽ ഏതാണ് നോക്കുന്നതെന്ന് തീരുമാനിക്കുക: കീ വലുപ്പം, ബ്ലോക്ക് വലുപ്പം, അല്ലെങ്കിൽ സെഗ്മെന്റ് വലുപ്പം. സാധാരണ അർത്ഥത്തിൽ സുരക്ഷാ പരാമീറ്റർ ആദ്യത്തേത് മാത്രമാണ്.

മൂന്ന് സംഖ്യകൾ, മൂന്ന് അളവുകൾ

AES 128, 192 അല്ലെങ്കിൽ 256-ബിറ്റ് കീകൾ സ്വീകരിക്കുന്നു, നിങ്ങൾ ഏത് തിരഞ്ഞെടുത്താലും 128-ബിറ്റ് ബ്ലോക്കുണ്ട്. ബ്ലോക്ക് വലുപ്പം മോഡിനല്ല, AES-നാണ്. CFB പ്രത്യയമാണ് മൂന്നാമത്തെ അളവ്: മോഡ് ഓരോ ഘട്ടത്തിലും എത്ര ഡാറ്റ ഉപഭോഗം ചെയ്ത് തിരികെ നൽകുന്നു എന്നത്. OpenSSL AES ഡോക്യുമെന്റേഷൻ CFB രൂപങ്ങൾക്ക് ആ ഷിഫ്റ്റ് വലുപ്പങ്ങൾ വ്യക്തമായി പട്ടികപ്പെടുത്തുന്നു.

CFB1 ഒരു സമയത്ത് ഒരു ബിറ്റ്, CFB8 ഒരു ബൈറ്റ്, CFB128 പൂർണ്ണ ബ്ലോക്ക് എന്നിവ തിരികെ നൽകുന്നു. മൂന്നും ഉള്ളിൽ ഒരേ 128-ബിറ്റ് ബ്ലോക്ക് സൈഫർ ഉപയോഗിക്കുന്നു; മാറുന്നത് ഓരോ പ്രവർത്തനത്തിനും കണക്കാക്കിയ ബ്ലോക്കിൽ നിന്ന് എത്ര ബിറ്റുകൾ ഉപയോഗിക്കുന്നു എന്നതാണ്. അതുകൊണ്ടാണ് പ്രത്യയം കീയുടെ ശക്തിയല്ല, ചെലവും ബഫറിംഗ് സ്വഭാവവുമാണ് മാറ്റുന്നത്.

ബ്ലോക്ക് വലുപ്പം ഒരിക്കലും മാറാത്തത് എന്തുകൊണ്ട്

AES ഒരു നിശ്ചിത 128-ബിറ്റ് ബ്ലോക്കുള്ള ബ്ലോക്ക് സൈഫറാണ്, മോഡുകൾ അതിന് ചുറ്റും കെട്ടിപ്പടുത്ത നിർമ്മാണങ്ങളാണ്. അവയൊന്നും സെഗ്മെന്റ് വലുപ്പത്തിന് ഒത്തുപോകാൻ ബ്ലോക്ക് ചെറുതാക്കുന്നില്ല. CFB1 നടപ്പാക്കലും പൂർണ്ണ AES ബ്ലോക്ക് കണക്കാക്കി ഫലത്തിൽ നിന്ന് ഒരു ബിറ്റ് എടുക്കുന്നു. മറ്റ് ബിറ്റുകൾ ആ ഘട്ടത്തിന് ഉപേക്ഷിക്കപ്പെടുന്നു, കാര്യക്ഷമതയുടെ ചെലവ് കൃത്യമായി അവിടെയാണ്.

അതിനാൽ ഒരു ബിറ്റ് ഫീഡ്ബാക്ക് ഒരു ബിറ്റ് കീയെ സൂചിപ്പിക്കുന്നില്ല, പേര് അതിന്റെ പ്രത്യയം കൊണ്ട് റാങ്ക് ചെയ്യാനും കഴിയില്ല. CFB128 CFB32-നേക്കാൾ നാല് മടങ്ങ് ശക്തമല്ല; അത് വലിയ സെഗ്മെന്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നു.

സെഗ്മെന്റ് വലുപ്പം യഥാർത്ഥത്തിൽ മാറ്റുന്നത്

സെഗ്മെന്റ് വലുപ്പം ഓരോ ഘട്ടത്തിലും എത്ര സൈഫർ ടെക്സ്റ്റ് തിരികെ നൽകുന്നു, ഓരോ ഘട്ടത്തിനും എത്ര പ്ലെയിൻ ടെക്സ്റ്റ് വഹിക്കാനാകും എന്നത് മാറ്റുന്നു. പിശക് പ്രചരണവും ബഫറിംഗ് സ്വഭാവവും ഇത് മാറ്റുന്നു, ഇത് സ്ട്രീം പോലുള്ള ഉപയോഗത്തിന് പ്രധാനമാണ്. ബൈറ്റ് അധിഷ്ഠിത സെഗ്മെന്റുകൾ ബഫറുകളുമായി ഒത്തുപോകുന്നു, ബിറ്റ് അധിഷ്ഠിതമായവ ഒത്തുപോകുന്നില്ല.

പ്രായോഗികമായി മോഡ് തിരഞ്ഞെടുക്കുന്നത് പ്രോട്ടോക്കോളാണ്, ഓപ്പറേറ്ററല്ല. VPN ഡാറ്റ ചാനൽ അതിന്റെ പ്രോട്ടോക്കോൾ നിർദ്ദേശിക്കുന്ന നിർമ്മാണം സ്വന്തം സമഗ്രതാ സംരക്ഷണത്തോടെ ഉപയോഗിക്കുന്നു, ലൈബ്രറി പട്ടിക ഏത് പേരുകൾ നിലവിലുണ്ടെന്ന് മാത്രം പറയുന്നു.

യോഗ്യതയില്ലാത്ത CFB ലേബൽ വായിക്കൽ

യോഗ്യതയില്ലാത്ത CFB ലേബലിന് അതിന്റെ നടപ്പാക്കൽ സന്ദർഭം ആവശ്യമാണ്. OpenSSL 1.0.2 ഹെഡറുകളിൽ EVP_aes_128_cfb എന്നത് EVP_aes_128_cfb128-ന്റെ മാക്രോയാണ്, 192, 256-ബിറ്റ് കീകൾക്ക് ഒത്തുപോകുന്ന അലിയാസുകളും ഉണ്ട്. അത് ഒരു ശാഖയുടെ API നാമകരണ സമ്പ്രദായമാണ്, എല്ലാ ലൈബ്രറിയും ഫയൽ ഫോർമാറ്റും GUI-യും ആ ചുരുക്കെഴുത്ത് അതേ രീതിയിൽ വികസിപ്പിക്കുന്നു എന്ന വാദമല്ല. നിങ്ങളുടെ മുന്നിലുള്ള പതിപ്പിന്റെ ഹെഡറോ ഡോക്യുമെന്റേഷനോ പരിശോധിക്കുക.

പഴയ പ്രൊഫൈൽ CFB എന്ന് പറയുകയും എതിർകക്ഷി അത് സ്വീകരിക്കുകയും ചെയ്താൽ, ചർച്ച ചെയ്ത പരാമീറ്ററുകൾ എവിടെയോ രേഖപ്പെടുത്തുന്നു: ഒരു ലോഗിൽ, ഒരു കോൺഫിഗറേഷൻ ഡമ്പിൽ, ഒരു API പ്രതികരണത്തിൽ. ഡിസ്പ്ലേ സ്ട്രിംഗിൽ നിന്ന് സെഗ്മെന്റ് വലുപ്പം അനുമാനിക്കുന്നതിന് പകരം അവ വായിക്കുക.

മോഡ് പേര് നിങ്ങളോട് പറയാത്തത്

പേര് എൻക്രിപ്ഷൻ സ്വഭാവം മാത്രം വിവരിക്കുന്നു, മറ്റൊന്നുമില്ല. VPN-ന് ഇപ്പോഴും സമഗ്രതാ സംരക്ഷണം, കീ ഡെറിവേഷൻ, എതിർകക്ഷി പ്രാമാണീകരണം എന്നിവ വേണം, CFB അവയൊന്നും നൽകുന്നില്ല. CFB8-നെ CFB1-ന് പകരം വയ്ക്കുന്നതും ബാഹ്യമായ മാറ്റമല്ല: വയർ സ്വഭാവം വ്യത്യസ്തമാണ്, ഇരു കക്ഷികളും ഒരേ നിർമ്മാണം പിന്തുണയ്ക്കണം. ഒരു ലൈബ്രറിയിലെ പേര് വിന്യസിച്ച ഗേറ്റ്‌വേ അതിനെ അതിന്റെ ഡാറ്റ ചാനലിന് സ്വീകരിക്കുന്നു എന്നതിന് തെളിവുമല്ല.

പരിപാലിക്കുന്ന എന്തിനും പ്രോട്ടോക്കോളിന്റെ പൂർണ്ണ സംരക്ഷണ ക്രമീകരണവും ഓപ്പറേറ്ററുടെ നയവും ഉപയോഗിക്കുക, ലൈബ്രറിയുടെയും ഗേറ്റ്‌വേയുടെയും പതിപ്പുകൾ, കൃത്യമായ ഓപ്ഷൻ, ചർച്ച ചെയ്ത ഫലം എന്നിവ രേഖപ്പെടുത്തുക. പഴയ പേര് നിങ്ങൾ വായിക്കുന്നത് വിശദീകരിക്കുന്നു; അത് ക്രമീകരണം പുനരുജ്ജീവിപ്പിക്കാൻ ന്യായീകരണമല്ല.