સ્ટેટિક કી ફાઇલમાં બિટ સંખ્યા OpenVPN સાઇફરની શક્તિ નથી

સ્કેનર કે સહકર્મી OpenVPN સ્ટેટિક કી ફાઇલની અંદર છપાયેલી બિટ સંખ્યા તરફ ઈશારો કરે છે અને પૂછે છે કે ટનલ આટલા કદનું સાઇફર કેમ વાપરતી નથી. પ્રશ્ન વાજબી લાગે છે, અને જવાબ કોઈ સંખ્યા નથી: બેનર સંગ્રહિત કી સામગ્રી ગણે છે, જ્યારે સાઇફર ફક્ત તે ભાગ વાપરે છે જે તેના કી કદને જરૂરી હોય. એ કુલને શક્તિના સેટિંગ તરીકે લેવાથી એવા ફેરફાર થાય છે જે કંઈ બદલતા નથી. આ ફોર્મેટ એવી રીતે બનાવાયું છે કે કોઈ પણ એક અલ્ગોરિધમ વાપરે તેના કરતાં વધુ સામગ્રી રાખે.

અહીં બે પ્રશ્નો ભળી જાય છે: ફાઇલ કેટલી કી સામગ્રી સંગ્રહે છે, અને સંમત સાઇફર કેટલું મજબૂત છે. ફક્ત બીજો જ ટનલનું વર્ણન કરે છે.

બેનરની સંખ્યા ખરેખર શું ગણે છે

કન્ટેનર સાઇફર સામગ્રી અને HMAC સામગ્રીને અલગ રચના તરીકે ક્રમિક કરે છે, અને દ્વિદિશ રૂપ બે એવા સેટ રાખે છે જેથી દરેક દિશા પોતાની કી લઈ શકે. લખતો કોડ છપાયેલી સંખ્યાને ક્રમિક રચનાઓની સંખ્યા, તેમના કદ અને પ્રતિ બાઇટ આઠ બિટ પરથી મેળવે છે. આ સંગ્રહ પરનું અંકગણિત છે, એવું નિવેદન નથી કે એક સાઇફર દરેક સંગ્રહિત બાઇટ વાપરે. હેડર મહત્તમ સાઇફર સામગ્રી ફાળવણી પણ નિશ્ચિત કરે છે જેથી લાઇબ્રેરી ફેરફાર ફોર્મેટનું કદ ચૂપચાપ ન બદલી શકે.

એને સર્ટિફિકેટ કી સાથે સરખાવો, જ્યાં બિટ સંખ્યા ખરેખર એક વસ્તુનું કદ વર્ણવે છે. 4,096 બિટની RSA કી અને જેનું બેનર 4,096 બિટ વાંચે છે એવી કી ફાઇલ અલગ કામ સાથેની અલગ વસ્તુઓ છે, અને તેમને એક જ ડાયલના બે સેટિંગ તરીકે ગોઠવવાથી ખરાબ તારણ નીકળે છે.

એક ફાઇલમાં બે કી સેટ

ફાઇલનો દરેક અડધો ભાગ એન્ક્રિપ્શન અને પ્રમાણીકરણ સામગ્રી પૂરો પાડે છે, કારણ કે પૂર્વ-વહેંચાયેલ કી મોડ એ અલગ ટુકડાઓથી બંને દિશામાં પેકેટ સુરક્ષિત કરે છે. સક્રિય સાઇફર ફક્ત તે બાઇટ વાપરે છે જે તેના કી કદને જરૂરી હોય, અને ડાયજેસ્ટ પોતાનું આઉટપુટ કદ વાપરે છે, તેથી ઉપયોગી શક્તિ વિકલ્પોમાંથી આવે છે, ફાઇલની લંબાઈમાંથી નહીં. હેક્સાડેસિમલ બ્લોબ લંબાવવાથી ગોઠવાયેલા અલ્ગોરિધમને તેમાંથી વધુ વાપરવાનું કહેવાતું નથી. ટિપ્પણીને મોટી સંખ્યાથી સંપાદિત કરવાથી તો વધુ ઓછું બદલાય છે.

જો તમે ખરેખર લાંબી કી ઈચ્છો છો, તો બદલવાનું સેટિંગ સાઇફર કે ડાયજેસ્ટ છે, અને જનરેટર પસંદ કરેલા અલ્ગોરિધમને જે જોઈએ તે બનાવે છે.

પ્રોફાઇલ વાંચવાથી ખબર પડે કે તમારી પાસે કયો મોડ છે

એક જ ફાઇલ ફોર્મેટ બે તદ્દન અલગ કામ કરે છે, અને કયું તમારી પાસે છે તે ફક્ત પ્રોફાઇલ કહે છે. જૂની secret લાઇન ફાઇલને ટનલની એકમાત્ર કી સામગ્રી બનાવે છે, જ્યારે tls-auth કે tls-crypt તેને સર્ટિફિકેટની સાથે કંટ્રોલ-ચેનલ સુરક્ષા બનાવે છે. બંનેમાંથી કોઈ પણ ઉપયોગ તેને ક્લાયન્ટના સર્ટિફિકેટ ખાનગી કીમાં ફેરવતો નથી, ભલે બ્લોક કેટલો સરખો દેખાય. બદલી બનાવતાં પહેલાં વિકલ્પ અને આવૃત્તિ ઓળખો, અને અક્ષર ઉમેરવાને બદલે દસ્તાવેજીકૃત જનરેટર વાપરો.

એ ભેદ જાહેરાત પ્રત્યેનો પ્રતિભાવ પણ નક્કી કરે છે. લીક થતી tls-auth કી સેશન કી જાહેર કરતી નથી, પણ હુમલાખોરને કંટ્રોલ-ચેનલ ટ્રાફિક દાખલ કરવા દે છે, તેથી તેને બદલવી તો પડે જ. લીક થયેલી secret કી વધુ ખરાબ છે, કારણ કે તે જ એવી સામગ્રી હતી જે ડેટાને પોતે સુરક્ષિત કરતી હતી.

સુરક્ષા સમીક્ષાએ શું નોંધવું જોઈએ

ત્રણ વસ્તુ અલગ નોંધો: સંમત ડેટા-ચેનલ સુરક્ષા, કંટ્રોલ-ચેનલ સુરક્ષા અને સાથીઓ કેવી રીતે પ્રમાણીકરણ કરે છે. data-ciphers AES-256-GCM જેવી લાઇન ફક્ત પ્રથમનું વર્ણન કરે છે, અને ત્યાં અટકતો અહેવાલ એ જવાબ આપી શકતો નથી કે કંટ્રોલ-ચેનલ બિલકુલ સુરક્ષિત છે કે નહીં. સ્ટેટિક કી ફાઇલ tls-auth કે tls-crypt સાથે વપરાય ત્યારે બીજી શ્રેણીમાં આવે છે, અને ન વપરાય ત્યારે કોઈમાં નહીં. શ્રેણીઓ ભેળવનાર સમીક્ષકો વધુ મજબૂત સાઇફર ઈચ્છતા હોય ત્યારે મોટી કી ફાઇલ માગે છે.

જો ફાઇલ જાહેર થઈ ગઈ હોય, તો તેને ફેરવો અને મંજૂર ચેનલ દ્વારા ફરી વહેંચો. ચેડા પામેલી ગુપ્તતામાં અક્ષર ઉમેરવા એ ફેરવવું નથી, અને તે જાહેર થયેલી સામગ્રીને માન્ય રાખે છે.

ફેરવવાનો રેકોર્ડ જે પ્રોફાઇલનો છે તેની સાથે રાખો. આગલી સમીક્ષા પૂછશે કઈ કી કયો સમયગાળો સુરક્ષિત કરતી હતી, અને બેનર એનો જવાબ નહીં આપે.