- Twitter(X) का नया encrypted DM (XChat) तकनीकी रूप से end-to-end encryption का दावा करता है, लेकिन private key चोरी, MITM, metadata exposure जैसी गंभीर सुरक्षा खामियां अब भी मौजूद हैं
- Libsodium Box (secret key-आधारित encryption) अपनाया गया है, लेकिन forward secrecy का समर्थन नहीं है और 4-अंकों के PIN पर आधारित कमजोर key protection के कारण private key निकालना तुलनात्मक रूप से आसान है
- Juicebox protocol से key backup/recovery किया जाता है, लेकिन वास्तविक सुरक्षा पूरी तरह backend trust पर निर्भर है, और Twitter सभी backend खुद चलाता है, इसलिए sharding का मतलब लगभग खत्म हो जाता है
- public key authentication/verification के लिए कोई out-of-band प्रक्रिया नहीं है, इसलिए Twitter MITM (man-in-the-middle attack) के जरिए keys बदल सकता है, और user metadata जस का तस उजागर रहता है
- Signal के विपरीत, फिलहाल वास्तविक privacy protection अपर्याप्त है, इसलिए विश्वसनीय encrypted messenger के रूप में Signal की सिफारिश की गई है
Twitter के नए encrypted DM का विश्लेषण
पृष्ठभूमि और सारांश
- Twitter(X) ने नया XChat encrypted messaging platform पेश किया, जिसे Rust में विकसित बताया गया है और Bitcoin-शैली की cryptographic structure अपनाने का प्रचार किया गया
- लेकिन वास्तविक implementation देखने पर, अब भी संरचना ऐसी है कि Twitter private key access, MITM (man-in-the-middle attack), और metadata collection कर सकता है
- निष्कर्ष: Signal इस्तेमाल करने की सलाह, Twitter(X) DM अपनी मूलभूत सीमाओं के कारण सुरक्षित नहीं है
encryption structure और इसकी सीमाएं
1. encryption तरीका
- Libsodium के box (public key-आधारित encryption) का उपयोग
- forward secrecy का समर्थन नहीं: private key लीक होने पर पुराने सभी messages decrypt किए जा सकते हैं (यानी Signal जैसे आधुनिक messengers की तुलना में अधिक कमजोर)
- वास्तविक implementation Rust नहीं बल्कि C library (jni binding के जरिए) का उपयोग करती है
2. key storage और recovery (Juicebox protocol)
- device पर बनी private key को Juicebox protocol से store किया जाता है
- key को PIN (4-अंकों) आधारित encryption के बाद store किया जाता है, और recovery के समय PIN डालना पड़ता है
- server PIN नहीं जानता, लेकिन PIN केवल 4-अंकों का है (10,000 संभावनाएं), इसलिए parallel brute force से इसे तेज़ी से crack किया जा सकता है
- Argon2id के साथ 16MB memory और 32 iterations लागू होने पर भी वास्तविक attacker के लिए यह बड़ी बाधा नहीं है (कम-शक्ति वाले laptop पर भी 0.2 सेकंड से कम)
3. key distribution (Sharding) structure की सीमाएं
- Juicebox multi-backend distribution (sharding) का समर्थन करता है, लेकिन Twitter तीनों backend खुद चलाता है
- अंततः key recovery प्रक्रिया में पूरी तरह Twitter पर भरोसा करना पड़ता है, इसलिए sharding का मूल सुरक्षा लाभ नहीं बचता
- backend के साथ सुरक्षित communication के लिए HSM, SGX जैसी hardware verification प्रक्रिया भी मौजूद नहीं है
4. public key authentication/exchange की कमजोरियां
- सामने वाले की public key सिर्फ Twitter server के जरिए मिलती है, उसे verify करने का अलग out-of-band तरीका नहीं है
- Twitter चाहे तो मनमानी public key देकर man-in-the-middle attack (MITM) कर सकता है
- आधिकारिक support page भी इस कमजोरी को स्वीकार करता है, और भविष्य में सुधार का संकेत देता है, लेकिन फिलहाल कोई ठोस उपाय नहीं है
5. metadata और अन्य समस्याएं
- कौन किससे, कब message भेजता और पाता है जैसी metadata जानकारी Twitter पूरी तरह देख सकता है
- private key उजागर न भी हो, तब भी user के communication patterns कंपनी के सामने खुले रहते हैं
निष्कर्ष और सिफारिश
- encrypted DM की design limitations के कारण, वास्तविक security और privacy के मामले में यह Signal जैसे verified messengers के स्तर तक नहीं पहुंचता
- जब तक Twitter public key, keystore, और communication path तीनों को नियंत्रित करता है, इसे वास्तविक end-to-end encryption नहीं माना जा सकता
- Signal जैसे खुले और पारदर्शी protocol वाले messenger के उपयोग की जोरदार सिफारिश की जाती है
1 टिप्पणियां
Hacker News की राय
मैं Matthew Garrett की लिखी हर चीज़ का प्रशंसक हूँ, लेकिन यह बात ज़रूर ज़ोर देकर कहना चाहता हूँ कि Signal बहुत पहले से हमेशा forward secrecy को सपोर्ट करता आया है। आधुनिक सुरक्षित messenger की अवधारणा लगभग OTR (Borisov और Goldberg) से शुरू हुई, जिसने सबसे पहले "perfect forward secrecy" और deniability जैसी अवधारणाएँ पेश कीं। Signal को मैं इन विचारों और उनके engineering पहलुओं—बेहतर cryptography, बेहतर code, बेहतर packaging—को आगे बढ़ाने वाला परिणाम मानता हूँ। निराशाजनक बात यह है कि नए messenger "pre-Signal" स्तर पर नहीं, बल्कि 2001 से पहले वाले, यानी pre-modern security स्तर तक पीछे जा रहे हैं
पिछली कई leaks से याद रखने लायक तीन बातें हैं। (1) FBI ने कंपनियों को गुप्त रूप से backdoor डालने के लिए "मजबूर" किया है। यह भी सामने आया था कि FISA court किसी कंपनी पर भारी-भरकम जुर्माना लगा सकती है। (2) बड़ी कंपनियों को backdoor की लागत के लिए करोड़ों से लेकर सैकड़ों करोड़ तक का भुगतान किया गया। साथ ही government contracts या export licenses जैसे कई तरीकों से दबाव डाला गया। कुल मिलाकर इसे "या तो पैसा, या बंदूक" वाली नीति की तरह देखा जा सकता है। (3) Lavabit केस में FBI ने keys माँगीं और साथ ही ग्राहकों से झूठ बोलने के लिए भी लगभग मजबूर किया। ऐसे उदाहरणों को देखते हुए यह शक होना स्वाभाविक है कि बड़े platforms पर encryption को सरकारी मांगों के कारण जानबूझकर कमजोर किया जाता है, या फिर लापरवाही से इतना ढीला लागू किया जाता है कि उसका मतलब ही कम रह जाता है। जब तक Patriot Act, FISC, गुप्त व्याख्याएँ जैसी व्यवस्थाएँ खत्म नहीं होतीं और उल्लंघन करने वालों को सज़ा नहीं मिलती, तब तक police state के भीतर encryption को Five Eyes पहले ही समझौता-ग्रस्त कर चुका है—मैं यही मानकर चलता हूँ
जब तक लोग App Store से PC-आधारित apps इंस्टॉल करते रहेंगे, यह पिछड़ी हुई स्थिति जारी रहने वाली है
अगर ephemeral key का उपयोग नहीं हो रहा, forward secrecy नहीं है, और interaction history भी नहीं है, तो इसमें असल में 'bitcoin-style' क्या है, यह समझना मुश्किल है
cryptography का इस्तेमाल हुआ है, लेकिन कुल मिलाकर यह दिलचस्प नहीं, लगभग बेकार-सी derivative technology लगती है
यानी इसका कोई खास व्यावहारिक उपयोग नहीं है
और Bitcoin खुद भी कोई सुरक्षित communication channel नहीं है
इसमें PIN-based key derivation का उपयोग होता है। लेकिन यह messaging से ज़्यादा backup implementation जैसा लगता है, इसलिए इसे कोई मूलभूत विशेषता मानना भी मुश्किल है
hash function इस्तेमाल होने की बात कही गई है
पुरानी चर्चा का लिंक साझा:
X का नया "encrypted" XChat भी खास ज़्यादा सुरक्षित नहीं है
संबंधित टिप्पणी देखें
अगर encryption करनी ही है, तो अलग software इस्तेमाल करना और public keys आमने-सामने मिलकर exchange करना बेहतर तरीका हो सकता है
सवाल: मैं जल्द ही Beijing जाने वाला हूँ, क्या वहाँ VPN के बिना Twitter इस्तेमाल किया जा सकता है?
"Bitcoin style encryption" वाली अभिव्यक्ति पर भी सवाल है। मेरी समझ में Bitcoin उस तरह की "encryption" से ज़्यादा cryptographic signatures पर निर्भर करता है, जैसा लोग आम तौर पर समझते हैं
यह शब्द असल में कोई वास्तविक अर्थ नहीं रखता, बस तकनीक से कम परिचित लोगों को प्रभावशाली लगने वाला marketing phrase है
यह भी ध्यान रखना चाहिए कि यह बात कहने वाला व्यक्ति खुद बहुत गहरे technical background वाला नहीं है
उसने यह शब्द शायद जानबूझकर इस्तेमाल किया ताकि विवाद खड़ा हो और ज़्यादा attention मिले
व्याख्यात्मक वीडियो का लिंक साझा
https://www.youtube.com/watch?v=sJNK4VKeoBM
बस ऐसा buzzword, जिससे चीज़ किसी “कीमती” या “value वाली” चीज़ जैसी लगे
क्या असली XChat (IRC client) X-Twitter पर trademark infringement का मुकदमा कर सकता है, यह सोचने वाली बात है
http://xchat.org/
मैं उस दौर में IRC user था जब XChat से HexChat की तरफ़ बदलाव हो रहा था। इसलिए यह देखकर हैरानी हुई कि HexChat का development भी बंद हो गया
HexChat के बंद होने की खबर
शायद हाँ, लेकिन XChat पक्ष को यह अच्छी तरह साबित करना होगा कि X जिन क्षेत्रों में दखल दे रहा है, वहाँ उसका वास्तविक commercial market है, और अलग-अलग jurisdictions में उसका trademark भी पंजीकृत है। वरना मामला और मुश्किल हो जाएगा
source article के मुताबिक Twitter जिस library का इस्तेमाल कर रहा है, उसकी दिलचस्प बात यह है कि developer ने खुद library description में लिखा है:
“चेतावनी: experimental library! review होने से पहले इसे production में इस्तेमाल न करें। risk और bugs की संभावना बहुत अधिक है”
https://github.com/ionspin/kotlin-multiplatform-libsodium
Twitter की brand power इतनी मजबूत है कि rebranding के बाद भी उसने अपनी पकड़ नहीं खोई—यह बात काफ़ी चौंकाती है