എല്ലായിടത്തും Signal Protocol അറ്റം മുതൽ അറ്റം വരെയുള്ള എൻക്രിപ്ഷനും AES-256-ഉം
Tosh Defence-ന്റെ Sanket.Chat ഓരോ സന്ദേശവും പ്രതികരണവും എൻക്രിപ്റ്റ് ചെയ്ത പ്രക്ഷേപണവും, സ്വതന്ത്ര ഓഡിറ്റിന് വിധേയമായ Signal-ന്റെ ഔദ്യോഗിക libsignal ഉപയോഗിച്ച്, Signal Protocol വഴി ഒരറ്റം മുതൽ മറ്റേ അറ്റം വരെ എൻക്രിപ്റ്റ് ചെയ്യുന്നു; ഇതിനായി PQXDH കീ ധാരണയും SPQR സഹിതമുള്ള Double Ratchet-ഉം ഉപയോഗിക്കുന്നു. ഫയലുകൾ, കോൾ ഫ്രെയിമുകൾ, കോൾ കൈമാറ്റം, പ്രാദേശിക സംഭരണം, ഇൻസ്റ്റാളേഷൻ അവസാനിപ്പിക്കുന്ന ഓരോ TLS സെഷനും AES-256 ഉപയോഗിക്കുന്നു; AES-128-ലേക്കുള്ള പിന്മാറ്റമോ അനുയോജ്യതാ രീതിയോ ഇല്ല.
AES-256 ഉപയോഗിക്കുക, അല്ലെങ്കിൽ പ്രവർത്തനം നിരസിക്കുക എന്നതാണ് SANKET-ന്റെ എൻജിനീയറിങ് നയം; ഇത് കോഡിൽ തന്നെ നടപ്പാക്കിയിരിക്കുന്നു. രൂപകൽപ്പന ചെയ്തതുപോലെ കൃത്യമായി എൻക്രിപ്ഷൻ നടത്താൻ കഴിയുന്നില്ലെങ്കിൽ, സുരക്ഷ ദുർബലപ്പെടുത്തുന്നതിനു പകരം പ്രവർത്തനം നിരസിക്കും.
സന്ദേശങ്ങൾ: മാറ്റം വരുത്താത്ത Signal Protocol
എല്ലാ സന്ദേശ എൻക്രിപ്ഷനും Sanket, iOS, Android, ഡെസ്ക്ടോപ്പ്, സെർവർ എന്നിവയിൽ ഒരേ പതിപ്പിലുള്ള Signal-ന്റെ ഔദ്യോഗിക libsignal ലൈബ്രറിയാണ് ഉപയോഗിക്കുന്നത്. ഇതിൽ Signal Protocol പുനർനിർമിച്ച പതിപ്പോ സന്ദേശങ്ങൾക്കായി മറ്റൊരു സൈഫറോ ഇല്ല.
X3DH-യുടെ പോസ്റ്റ്-ക്വാണ്ടം വിപുലീകരണമായ PQXDH ഉപയോഗിച്ചാണ് സെഷനുകൾ സ്ഥാപിക്കുന്നത്; ഇതിൽ X25519 കീ കരാറുകളും Kyber കീ എൻക്യാപ്സുലേഷനും സംയോജിപ്പിക്കുന്നു. തുടർന്ന് Double Ratchet ഉപയോഗിച്ച് സന്ദേശങ്ങൾ എൻക്രിപ്റ്റ് ചെയ്യുന്നു: ഓരോ സന്ദേശത്തിന്റെയും കീ AES-256 കീയായും HMAC-SHA256 കീയായും ഒരു പ്രാരംഭ വെക്ടറായും വികസിപ്പിക്കുന്നു; സന്ദേശം AES-256 ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത് HMAC-SHA256 ഉപയോഗിച്ച് പ്രാമാണീകരിക്കുന്നു; ഉപയോഗശേഷം കീ ഇല്ലാതാക്കുന്നു. ഓരോ സെഷനിലും ഇതോടൊപ്പം Signal-ന്റെ സ്പാർസ് പോസ്റ്റ്-ക്വാണ്ടം റാച്ചറ്റും പ്രവർത്തിക്കുന്നു.
രൂപകൽപ്പനപ്രകാരം പകരം ഉപയോഗിക്കാവുന്ന മാർഗമില്ല
libsignal ഉപയോഗിച്ച് എൻക്രിപ്ഷൻ നടത്താൻ കഴിയുന്നില്ലെങ്കിൽ ക്ലയന്റ് സന്ദേശം അയയ്ക്കാൻ വിസമ്മതിക്കുന്നു. libsignal തിരിച്ചറിയൽ കീ പ്രസിദ്ധീകരിക്കാത്ത ഉപകരണങ്ങളിലേക്ക് സാധാരണ വായിക്കാവുന്ന രൂപത്തിൽ അയയ്ക്കുന്നതിനു പകരം അവയെ ഒഴിവാക്കുന്നു; പഴയ സാധാരണ വായിക്കാവുന്ന സന്ദേശസൂചകങ്ങൾ നിരസിക്കുന്നു; libsignal ഫോർമാറ്റ് പാലിക്കാത്ത കീ കൂട്ടങ്ങൾ സെർവർ നിരസിക്കുന്നു. സന്ദേശ ഉള്ളടക്കത്തിന് സാധാരണ വായിക്കാവുന്ന രൂപത്തിലോ മറ്റൊരു എൻക്രിപ്ഷൻ രീതിയിലോ അയയ്ക്കാനുള്ള മാർഗമില്ല.
പങ്കിട്ട കീ ഇല്ലാത്ത ഗ്രൂപ്പുകൾ
ഗ്രൂപ്പ് സന്ദേശങ്ങൾ ഓരോ സ്വീകർത്താവിനും പ്രത്യേകം എൻക്രിപ്റ്റ് ചെയ്ത് അയയ്ക്കുന്നതിലൂടെ സംരക്ഷിക്കപ്പെടുന്നു: അയയ്ക്കുന്ന ഉപകരണം ഓരോ അംഗത്തിന്റെയും വിശ്വസനീയമായ ഓരോ ഉപകരണത്തിനായി, അതത് libsignal സെഷനിലൂടെ, സന്ദേശം വെവ്വേറെ എൻക്രിപ്റ്റ് ചെയ്യുന്നു. അംഗത്വത്തിലെ മാറ്റങ്ങൾക്ക് കീകൾ പുതുക്കേണ്ടതില്ല; നീക്കം ചെയ്ത അംഗം സന്ദേശം അയയ്ക്കേണ്ടവരുടെ പട്ടികയിൽ പിന്നെ ഉണ്ടാകില്ല.
എൻക്രിപ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ്, അയക്കുന്നയാൾ ഓരോ സ്വീകർത്താവിന്റെയും അക്കൗണ്ടിന്റെ സ്വന്തം കീ ഉപയോഗിച്ച് ഒപ്പിട്ട ഉപകരണപ്പട്ടിക പരിശോധിക്കുകയും ആ പട്ടികയിലില്ലാത്ത ഉപകരണത്തിലേക്ക് ഒന്നും അയയ്ക്കാതിരിക്കുകയും ചെയ്യുന്നു.
ഫയലുകളും കോളുകളും
ഓരോ ഫയലിനും ക്രമരഹിതമായി സൃഷ്ടിച്ച 256-ബിറ്റ് കീ ഉപയോഗിച്ച്, അറ്റാച്ച്‌മെന്റിന്റെ ഉള്ളടക്കം, പേരുകൾ, തരങ്ങൾ എന്നിവ ഉപകരണത്തിൽ AES-256-GCM വഴി എൻക്രിപ്റ്റ് ചെയ്യുന്നു. ആ കീ libsignal സന്ദേശത്തിനുള്ളിലൂടെയാണ് കൈമാറുന്നത്.
ശബ്ദത്തിനും ദൃശ്യത്തിനും രണ്ട് തലത്തിലുള്ള സംരക്ഷണമുണ്ട്. ഓരോ പങ്കാളിയുടെയും ഫ്രെയിമുകൾ ഓരോ അയയ്ക്കുന്നയാൾക്കും പ്രത്യേകം നിശ്ചയിച്ച കീ ഉപയോഗിച്ച് AES-256-GCM വഴി അറ്റം മുതൽ അറ്റം വരെ എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു. ഈ കീ ഓരോ 200 മില്ലിസെക്കൻഡിലും പുതുക്കപ്പെടുന്നതിനാൽ ഓരോ അയയ്ക്കുന്നയാൾക്കും ഓരോ സെക്കൻഡിലും 5 പുതിയ ഫ്രെയിം കീകൾ ലഭിക്കുന്നു. ആരെങ്കിലും ചേരുമ്പോഴോ പുറത്തുപോകുമ്പോഴോ പുതിയ യാദൃച്ഛിക കീ സൃഷ്ടിക്കപ്പെടുന്നു. ഓരോ ഉപകരണത്തിനും മീഡിയ സെർവറിനും ഇടയിൽ SRTP, AEAD_AES_256_GCM മാത്രമേ സ്വീകരിക്കൂ. മീഡിയ സെർവർ തനിക്ക് ഡീക്രിപ്റ്റ് ചെയ്യാനാകാത്ത എൻക്രിപ്റ്റ് ചെയ്ത ഫ്രെയിമുകൾ കൈമാറുന്നു. സെർവർ ഭാഗത്ത് കോൾ റെക്കോർഡ് ചെയ്യാനുള്ള സൗകര്യം ഈ രൂപകൽപ്പനയിൽ ഇല്ല.
- ഓരോ ഫയലിനും AES-256-GCM
- വിളിയിൽ സന്ദേശം അയക്കുന്ന ഓരോരുത്തർക്കും പ്രത്യേകം കീകൾ; എല്ലാവർക്കും പൊതുവായ ഒരു കീ അല്ല
- ഓരോ അയയ്ക്കുന്നയാൾക്കും സെക്കൻഡിൽ 5 ഫ്രെയിം കീകൾ
- SRTP AES-256-GCM മാത്രം
പ്രക്ഷേപണവും സംഭരണവും
ആപ്പുകളും ഇൻസ്റ്റാളേഷനും തമ്മിലുള്ള ഓരോ കണക്ഷനും TLS_AES_256_GCM_SHA384 സഹിതമുള്ള TLS 1.3 ഉപയോഗിക്കുന്നു; പ്ലാറ്റ്ഫോമിന്റെ ശൃംഖലാ സംവിധാനത്തിന് ആവശ്യമുള്ളിടത്ത് ECDHE, AES-256-GCM എന്നിവ സഹിതമുള്ള TLS 1.2 ഉപയോഗിക്കുന്നു. AES-128, ChaCha20, CBC രീതിയിലുള്ള ക്രിപ്റ്റോഗ്രാഫിക് കൂട്ടങ്ങൾ, സ്ഥിരമായ RSA എന്നിവ ഒഴിവാക്കിയിരിക്കുന്നു. ക്വാണ്ടം-ശേഷമുള്ള സംയുക്ത ക്രിപ്റ്റോഗ്രാഫിക് ഗ്രൂപ്പായ X25519MLKEM768 ആണ് ആദ്യം വാഗ്ദാനം ചെയ്യുന്നത്. അംഗീകരിച്ച ഓരോ ഉപകരണത്തിനും പരസ്പര TLS വഴി സ്വന്തം ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് സ്വയം പ്രാമാണീകരിക്കാനും കഴിയും.
ഉപകരണങ്ങളിൽ, പ്രാദേശിക ഡാറ്റാബേസുകൾ AES-256 ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യുകയും HMAC-SHA256 ഉപയോഗിച്ച് പ്രാമാണീകരിക്കുകയും ചെയ്യുന്നു. ഫോണുകളിൽ, പ്രോട്ടോക്കോൾ സംഭരണവും ഉപകരണത്തിലെ രഹസ്യങ്ങളും Secure Enclave, StrongBox അല്ലെങ്കിൽ വിശ്വസ്ത നിർവഹണ പരിതസ്ഥിതിയിലെ ഹാർഡ്‌വെയർ പിന്തുണയുള്ള കീ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്യുന്നു.
സാങ്കേതിക തെളിവ്
വിശദാംശങ്ങൾ SANKET ധവളപത്രത്തിൽ വായിക്കുക
ഈ പേജിലെ ഓരോ പ്രസ്താവനയും രജിസ്ട്രേഷൻ കൂടാതെ സൗജന്യമായി വായിക്കാവുന്ന പൊതുവായി ലഭ്യമായ SANKET സാങ്കേതിക സുരക്ഷയും വാസ്തുവിദ്യയും സംബന്ധിച്ച ധവളപത്രത്തിൽ പൂർണമായി വിശദീകരിച്ചിട്ടുണ്ട്.
SANKET Signal Protocol ഉപയോഗിക്കുന്നുണ്ടോ?
അതെ. എല്ലാ സംവിധാനങ്ങളിലും Signal-ന്റെ ഔദ്യോഗിക libsignal ലൈബ്രറി ഉപയോഗിച്ച്, PQXDH കീ ധാരണയും SPQR സഹിതമുള്ള Double Ratchet-ഉം വഴി Sanket എല്ലാ സന്ദേശങ്ങളും എൻക്രിപ്റ്റ് ചെയ്യുന്നു. പ്രോട്ടോക്കോൾ പുതുതായി നടപ്പിലാക്കിയ മറ്റൊരു പതിപ്പ് ഇതിൽ ഇല്ല.
SANKET-ലെ സന്ദേശങ്ങൾ AES-256 ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ?
അതെ. സന്ദേശങ്ങൾ libsignal-നുള്ളിൽ HMAC-SHA256 സഹിതം AES-256-CBC ഉപയോഗിക്കുന്നു; ഫയലുകൾ, കോൾ ഫ്രെയിമുകൾ, കോൾ കൈമാറ്റം, പ്രാദേശിക സംഭരണം, TLS എന്നിവ AES-256-GCM ഉപയോഗിക്കുന്നു. AES-128-ലേക്ക് മാറാനുള്ള ബദൽ സംവിധാനമില്ല.
ശബ്ദ, വീഡിയോ കോളുകൾക്ക് അറ്റം മുതൽ അറ്റം വരെ എൻക്രിപ്ഷൻ ഉണ്ടോ?
അതെ. ഓരോ അയയ്ക്കുന്നയാൾക്കും സെക്കൻഡിൽ 5 പുതിയ ഫ്രെയിം കീകൾ എന്ന നിരക്കിൽ, libsignal വഴി കൈമാറുന്ന അയയ്ക്കുന്നയാൾക്കുള്ള പ്രത്യേക കീകൾ ഉപയോഗിച്ച് കോൾ ഫ്രെയിമുകൾ AES-256-GCM-ൽ അറ്റംമുതൽ അറ്റംവരെ എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു. AES-256-GCM മാത്രം സ്വീകരിക്കുന്ന SRTP-ക്കുള്ളിലാണ് ഇത് പ്രവർത്തിക്കുന്നത്.
പ്രതികരണങ്ങളും ഒന്നിലധികം സ്വീകർത്താക്കൾക്കുള്ള സന്ദേശങ്ങളും എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ?
അതെ. പ്രതികരണങ്ങളും എൻക്രിപ്റ്റ് ചെയ്ത പ്രക്ഷേപണങ്ങളും മറ്റെല്ലാ സന്ദേശങ്ങളെയും പോലെ എൻഡ്-ടു-എൻഡ് എൻക്രിപ്റ്റ് ചെയ്ത libsignal സന്ദേശങ്ങളാണ്. പ്രക്ഷേപണത്തിന്റെ മുൻഗണന, സമയപരിധി, കാലാവധി തീരുന്ന സമയം എന്നിവയും എൻക്രിപ്ഷനുള്ളിലാണ്.
SANKET ഗ്രൂപ്പുകൾക്കായി പ്രേഷക കീകൾ ഉപയോഗിക്കുന്നുണ്ടോ?
ഇല്ല. ഓരോ അംഗത്തിന്റെയും വിശ്വസനീയമായ ഓരോ ഉപകരണത്തിനും SANKET ഗ്രൂപ്പ് സന്ദേശങ്ങൾ പ്രത്യേകം എൻക്രിപ്റ്റ് ചെയ്യുന്നു; ഓരോന്നിനും അതിന്റേതായ libsignal സെഷനാണ് ഉപയോഗിക്കുന്നത്. അതിനാൽ പങ്കിട്ട ഗ്രൂപ്പ് താക്കോലില്ല.
Sanket ഏത് TLS പതിപ്പുകളാണ് സ്വീകരിക്കുന്നത്?
TLS 1.3-നാണ് മുൻഗണന, TLS_AES_256_GCM_SHA384 മാത്രം ഉപയോഗിച്ച്. TLS 1.2 സ്വീകരിക്കുന്നത് ECDHE, AES-256-GCM എന്നിവയോടൊപ്പം മാത്രമാണ്. TLS 1.2-ന് താഴെയുള്ള ഒന്നും സ്വീകരിക്കില്ല; ഹൈബ്രിഡ് ക്വാണ്ടം-അനന്തര കീ കൈമാറ്റമായ X25519MLKEM768 ആദ്യം ലഭ്യമാക്കുന്നു.
libsignal സുരക്ഷാ പരിശോധനയ്ക്ക് വിധേയമായിട്ടുണ്ടോ?
അതെ. സ്വതന്ത്രമായി സുരക്ഷാ പരിശോധനയ്ക്ക് വിധേയമായ Signal-ന്റെ libsignal ലൈബ്രറിയെ അടിസ്ഥാനമാക്കിയാണ് Sanket നിർമ്മിച്ചിരിക്കുന്നത്; PQXDH പ്രോട്ടോക്കോൾ ഔപചാരികമായി വിശകലനം ചെയ്തിട്ടുമുണ്ട്.
ഞങ്ങളുടെ എഞ്ചിനീയർമാരോടൊപ്പം Sanket-ന്റെ ക്രിപ്റ്റോഗ്രഫി പരിശോധിക്കുക
വെളിപ്പെടുത്തൽ നിരോധന കരാറിന് വിധേയമായി ലഭ്യമാകുന്ന സാങ്കേതിക ധവളപത്രത്തിന്റെ നിയന്ത്രിത പതിപ്പ് ഉപയോഗിച്ച്, ക്രിപ്റ്റോഗ്രാഫിക് രൂപകൽപ്പനയുടെ ഓരോ പാളിയും Tosh Defence സുരക്ഷാ വാസ്തുശിൽപ്പികൾക്കും വിലയിരുത്തൽ സമിതികൾക്കും വിശദീകരിക്കുന്നു.