स्कैम में पैसे गँवाए? तुरंत 1930 पर कॉल करें। आगे क्या करें ›
Namaskara, नमस्कार English: भाषा बदलें

अपनी भाषा चुनें · भाषा चुनें

लोड हो रहा है…

जाँची गई = किसी मातृभाषी ने देखी है। पूरी साइट = हर पेज AI से अनुवाद हुआ है और भाव जाँचा गया है, मातृभाषी की जाँच बाकी है। बाकी भाषाओं में अभी सबसे नज़दीकी भाषा दिखती है। आपकी पसंद सिर्फ इसी डिवाइस पर रहेगी।

होम / Security

यह सुरक्षा कैसे काम करती है, आसान शब्दों में।

जो लोग जानना और समझना चाहते हैं, उनके लिए। पहले छोटी बात, फिर तकनीकी जानकारी।

आसान शब्दों में

आपके हर device की अपनी एक जोड़ी चाबियाँ होती हैं। जब आप कोई message भेजते हैं, तो आपका phone उसे एक नई, सिर्फ एक बार काम आने वाली चाबी से बंद करता है, फिर उस चाबी को chat के हर device के लिए अलग-अलग बंद करता है। सिर्फ वही devices उसे खोल सकते हैं। आपका phone message पर अपनी मुहर भी लगाता है, ताकि पढ़ने वाले का phone यह जान सके कि यह सच में आपकी तरफ से आया है और रास्ते में किसी ने बदला नहीं।

तकनीकी जानकारी

  • डिवाइस की चाबियाँ: चाबी के आदान-प्रदान के लिए X25519 और साइन करने के लिए Ed25519 — ये दोनों डिवाइस पर ही बनती हैं। निजी चाबियाँ डिवाइस के सुरक्षित भंडार में रखी जाती हैं और कभी अपलोड नहीं होतीं।
  • संदेश: एक रैंडम 256-bit कंटेंट चाबी, ChaCha20-Poly1305 से संदेश को बंद करती है। यह कंटेंट चाबी हर पाने वाले के डिवाइस के लिए अलग से ephemeral X25519 + HKDF-SHA256 द्वारा लपेटी जाती है। लिफ़ाफ़े का हेडर (बातचीत, भेजने वाला, डिवाइस, संदेश id, पाने वालों की सूची) associated data के रूप में जुड़ा रहता है और Ed25519 से साइन होता है।
  • फ़ाइलें: डिवाइस पर एक ऐसी key से बंद की जाती हैं जो सिर्फ़ एक बार काम आती है और खुद बंद संदेश के अंदर भेजी जाती है। Server पर सिर्फ़ बंद किया हुआ डेटा रखा जाता है।
  • कॉल: WebRTC के साथ DTLS-SRTP मीडिया। Offers, answers और ICE candidates भी उन्हीं साइन किए हुए, बंद लिफ़ाफ़ों में जाते हैं — इसलिए सर्वर कॉल की शुरुआत न पढ़ सकता है, न उसमें कुछ बदल सकता है।
  • Safety numbers: दोनों लोगों की device keys की एक पहचान-छाप होती है। यह पक्का करने के लिए कि बीच में कोई और तो नहीं है, आमने-सामने मिलकर इसे मिलाएँ। किसी contact की keys बदलने पर app आपको बता देता है।
  • साइन-इन: scrypt से पासवर्ड hash, चाहें तो TOTP दो-चरण जाँच जिसमें recovery कोड भी hash होते हैं, 5 बार गलत होने पर खाता रुक जाता है, 12 घंटे खाली रहने पर और ज़्यादा से ज़्यादा 24 घंटे का सेशन, HttpOnly SameSite=Strict कुकी। कहीं भी SMS नहीं।
  • वेब: सख़्त Content-Security-Policy, कोई तीसरे पक्ष का स्रोत नहीं, फ्रेम में दिखाना मना, प्रोडक्शन में HSTS।
  • Android: स्क्रीन कैप्चर रोकने के लिए FLAG_SECURE, बिना सुरक्षा वाला ट्रैफ़िक बंद, ऐप का बैकअप बंद।

Server क्या देख सकता है

कौन किससे और कब बात करता है, संदेश और फ़ाइलों का आकार, group के नाम और उनके सदस्य, और यह कि कॉल जुड़ रही है — यह सब server को दिखता है। काम की सूचियाँ, सहमतियाँ और रिपोर्ट के मसौदे server पर बिना end-to-end बंद किए रखे जाते हैं। यह बात हमने Privacy पेज पर खुलकर लिखी है।

हम जाँच कैसे करते हैं

हर release 40 से ज़्यादा जाँचों के एक अपने-आप चलने वाले दरवाज़े से गुज़रती है, जिनमें शामिल हैं: Python में लिखा protocol का एक अलग version जो app के साथ काम करे; बदले हुए, नकली और दोबारा भेजे गए envelopes पर हमले; server database में साफ text की तलाश; यह पक्का करना कि मिटने वाले पुराने messages अपनी keys के साथ हट जाते हैं; और एक browser जाँच कि web app कोई भी third-party request नहीं करता।

जानी-मानी कमियाँ

  • अभी forward secrecy ratchet नहीं है: अगर किसी डिवाइस की private key चोरी हो जाए, तो उस डिवाइस को भेजे गए पुराने संदेश खुल सकते हैं। Double-ratchet बनाने का काम आगे की योजना में है।
  • मेटाडेटा सर्वर को दिखता है, जैसा ऊपर बताया गया है।
  • वेब वर्ज़न की सुरक्षा ब्राउज़र पर और हमारे सर्वर से आने वाले कोड पर निर्भर करती है। यही एक वजह है कि वेब वर्ज़न अभी सिर्फ़ चुने हुए थोड़े से लोगों के लिए एक छोटे पायलट तक सीमित है: Google Play ऐप पहले आएगा, और हम उसका signing certificate Namaskara पाएँ पेज पर डालेंगे।

Security की कोई समस्या बताएँ

कोई कमज़ोरी मिली? कृपया इसे कहीं छापने से पहले हमें चुपचाप बताएँ — Contact के ज़रिए, subject में "Security" लिखकर। हम जवाब देंगे, उसे ठीक करेंगे, और आप चाहें तो आपका नाम भी लेंगे। कृपया दूसरे लोगों के accounts पर जाँच न करें।

Google Play पर आ रहा हैअर्ली एक्सेस