क्लाइंट-साइड एन्क्रिप्टेड · PDF शेयरिंग

क्लाइंट-साइड एन्क्रिप्टेड PDF शेयरिंग, सही तरीके से समझाई गई।

"एंड-टू-एंड एन्क्रिप्टेड" शब्द का उपयोग अक्सर अस्पष्ट रूप से होता है। यहाँ क्लाइंट-साइड एन्क्रिप्टेड PDF लिंक के पीछे की वास्तविक क्रिप्टोग्राफ़िक प्रक्रिया है — AES-256-GCM, की हैंडलिंग, फ्रैगमेंट बनाम पासफ्रेज़ मोड, और सर्वर वास्तव में क्या नहीं कर सकता। नोट: इस पेज पर "zero-knowledge" का अर्थ है कि सर्वर के पास आपकी फ़ाइल डिक्रिप्ट करने की कोई जानकारी नहीं है, न कि औपचारिक zero-knowledge proofs (ZKPs) — यह उत्पाद ZKPs का उपयोग नहीं करता।

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310,000 linkफ्रैगमेंट या पासफ्रेज़ memoryWeb Crypto API
sendएन्क्रिप्टेड लिंक भेजें यह कैसे काम करता है

यहाँ "zero-knowledge" का क्या अर्थ है

किसी भी बात से पहले एक त्वरित स्पष्टीकरण: यह सिस्टम zero-knowledge proofs (ZKPs) का उपयोग नहीं करता। इस पेज पर "zero-knowledge" शब्द एक कमज़ोर लेकिन व्यावहारिक रूप से उपयोगी गुण को दर्शाता है — सर्वर के पास आपकी साझा की गई फ़ाइल को डिक्रिप्ट करने के लिए कोई क्रिप्टोग्राफ़िक या परिचालन जानकारी नहीं है। की सर्वर तक कभी नहीं पहुँचती, इसलिए सर्वर इसे किसी भी परिस्थिति में प्रकट नहीं कर सकता। तंत्र सरल क्लाइंट-साइड एन्क्रिप्शन है, जिसमें की केवल URL फ्रैगमेंट में यात्रा करती है (या एक पासफ्रेज़ से डेराइव होती है जिसे सर्वर कभी नहीं देखता)।

memory
एन्क्रिप्शन आपके ब्राउज़र में होती है
सर्वर पर नहीं, किसी ऐसे वर्कर में नहीं जिसे आप नियंत्रित नहीं करते — आपके टैब में, window.crypto.subtle के ज़रिए। DevTools में सत्यापन योग्य।
cloud_off
केवल सिफरटेक्स्ट अपलोड होता है
अपलोड बॉडी AES-256-GCM सिफरटेक्स्ट है। PDF, फ़ाइलनाम और मेटाडेटा कभी भी पठनीय रूप में सर्वर तक नहीं पहुँचते।
vpn_key
की प्राप्तकर्ता के साथ रहती है
या तो URL फ्रैगमेंट में (कभी सर्वर को नहीं भेजी जाती) या एक पासफ्रेज़ से डेराइव होती है जिसे प्रेषक चुनता है। किसी भी तरह, हम इसे कभी नहीं देखते।
block
कोई रिकवरी नहीं = कोई बैकडोर नहीं
लिंक खो गया या पासफ्रेज़ भूल गए? फ़ाइल हमेशा के लिए चली गई। चूँकि की हमारे सर्वर तक कभी नहीं पहुँची, वह रिकवरी रास्ता जो गारंटी को कमज़ोर करता, मौजूद ही नहीं है।

क्लाइंट-साइड एन्क्रिप्टेड PDF लिंक कैसे बनता है

इस बात की विस्तृत जानकारी कि प्रेषक का ब्राउज़र, सर्वर और प्राप्तकर्ता का ब्राउज़र प्रत्येक क्या करता है — वास्तविक Web Crypto कॉल के साथ।

1 — प्रेषक का ब्राउज़र
// 256-bit AES key, generated locally key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // fresh 96-bit IV per file iv = crypto.getRandomValues(new Uint8Array(12)) // encrypt locally; GCM gives us an auth tag for integrity ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // upload ciphertext + iv (and salt, if passphrase mode) id = await PUT("/api/transfer", ct, {iv, expiry})
2 — शेयर लिंक का स्वरूप
// fragment mode: key lives after # link_f = `https://pdfpro.tools/s/<ID>#<KEY>` // passphrase mode: no key in the link; recipient must know the passphrase link_p = `https://pdfpro.tools/s/<ID>`
3 — सर्वर अपारदर्शी बाइट्स संग्रहीत करता है
ciphertext = ??? // random-looking, unreadable iv = 12-byte nonce salt = 16-byte random (passphrase mode only) expiry = 24h free / 30d Pro
4 — प्राप्तकर्ता का ब्राउज़र
// browsers never transmit the URL fragment to the server rawKey = /* from location.hash OR */ PBKDF2(passphrase, salt, 310_000, "SHA-256") ct = await GET("/api/transfer/" + id) pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // browser serves pdf to Downloads

फ्रैगमेंट मोड बनाम पासफ्रेज़ मोड

प्राप्तकर्ता तक की पहुँचाने के दो तरीके। समान सिफरटेक्स्ट गारंटी, अलग उपयोगिता / लीकेज ट्रेड-ऑफ।

फ्रैगमेंट मोड

की URL हैश (#) में रहती है

सबसे सरल प्रवाह: लिंक कॉपी करें, प्राप्तकर्ता को चैट में पेस्ट करें, हो गया। URL का वह हिस्सा जो # के बाद होता है, किसी भी अनुपालित ब्राउज़र द्वारा कभी किसी वेब सर्वर को नहीं भेजा जाता — यही की को निजी रखता है।

  • प्राप्तकर्ता के लिए एक कदम — लिंक पर क्लिक करें।
  • कम झंझट, कम-से-मध्यम संवेदनशीलता वाली शेयरिंग के लिए उपयुक्त।
  • जोखिम: यदि लिंक किसी स्क्रीनशॉट या ब्राउज़र सिंक में लीक हो जाए, तो फ़ाइल भी लीक हो जाती है।
  • तब उपयोग करें जब आप चैनल पर भरोसा करते हों (साइन्ड मैसेंजर, आंतरिक चैट)।
पासफ्रेज़ मोड

पासफ्रेज़ से डेराइव की (PBKDF2)

प्रेषक एक पासफ्रेज़ चुनता है। ब्राउज़र एक रैंडम 128-बिट सॉल्ट पर PBKDF2-SHA256 के 310,000 इटरेशन के ज़रिए 256-बिट की डेराइव करता है। सॉल्ट सर्वर-साइड संग्रहीत होता है; पासफ्रेज़ आउट-ऑफ-बैंड साझा किया जाता है (फोन, Signal, व्यक्तिगत रूप से)।

  • टू-फ़ैक्टर शेयर: लिंक और पासफ्रेज़ अलग-अलग यात्रा करते हैं।
  • केवल लिंक पर्याप्त नहीं — सिफरटेक्स्ट अपठनीय रहता है।
  • पासफ्रेज़ की मज़बूती मायने रखती है: 310k इटरेशन ब्रूट फोर्स को धीमा करते हैं लेकिन 6-अक्षर वाले पासफ्रेज़ को नहीं बचाते।
  • तब उपयोग करें जब लिंक फॉरवर्ड हो सकता हो या कहीं संग्रहीत हो जहाँ आप पूरी तरह भरोसा नहीं करते।
गुणफ्रैगमेंट मोडपासफ्रेज़ मोड
की वाहकURL हैश (#)पासफ्रेज़ + सॉल्ट
सर्वर कभी की देखता हैनहींनहीं
सर्वर संग्रहीत करता हैसिफरटेक्स्ट + IVसिफरटेक्स्ट + IV + सॉल्ट
प्राप्तकर्ता की झंझटलिंक पर क्लिक करेंलिंक पर क्लिक करें + पासफ्रेज़ टाइप करें
स्क्रीनशॉट से लीक होने योग्यहाँ (लिंक = की)नहीं (केवल लिंक बेकार है)
ब्रूट-फोर्स प्रतिरोधी256-बिट रैंडमपासफ्रेज़ पर निर्भर
सर्वोत्तम उपयोगविश्वसनीय चैनलों पर कम-झंझट शेयरिंगअधिक संवेदनशील शेयरिंग

सर्वर पर संग्रहीत सिफरटेक्स्ट फिर भी आपकी सुरक्षा क्यों करता है

लोग अक्सर पूछते हैं: "अगर यह आपके सर्वर पर है, तो यह निजी कैसे है?" उत्तर यह है कि सिफरटेक्स्ट फ़ाइल नहीं है। की के बिना, यह बस यादृच्छिक-दिखने वाले बाइट्स हैं। व्यवहार में इसका क्या अर्थ है।

storage
डेटाबेस उल्लंघन = सिफरटेक्स्ट लीक
यदि कोई हमलावर हमारे डेटाबेस से समझौता करता, तो वह अपारदर्शी बाइट्स लेकर जाता। एक फ़ाइल को रिकवर करने के लिए 256-बिट की को ब्रूट-फोर्स करना होगा — जो ज्ञात भौतिकी के साथ संभव नहीं है।
gavel
समन पर सिफरटेक्स्ट मिलता है
एक अदालत हमें जो है उसे सौंपने के लिए मजबूर कर सकती है। जो हमारे पास है वह सिफरटेक्स्ट है। अदालत का आदेश उस की को पूर्वव्यापी रूप से नहीं बना सकता जो हमने कभी संग्रहीत नहीं की।
group
अंदरूनी पहुँच निष्क्रिय हो जाती है
पूर्ण डेटाबेस क्रेडेंशियल वाला कोई बेईमान कर्मचारी भी फ़ाइलें नहीं पढ़ सकता। गारंटी गणित द्वारा लागू होती है, एक्सेस कंट्रोल द्वारा नहीं।
timer
समाप्ति गारंटी को और मज़बूत करती है
समाप्ति पर सिफरटेक्स्ट हटा दिया जाता है (24 घंटे मुफ्त, Pro में 30 दिन तक)। उसके बाद, सिफरटेक्स्ट भी चला जाता है — फ़ाइल की एकमात्र प्रति वहीं मौजूद है जहाँ इसे डिक्रिप्ट किया गया था।

warningईमानदार सीमाएँ

क्लाइंट-साइड एन्क्रिप्शन एंडपॉइंट सुरक्षा की समस्या हल नहीं करता। प्रेषक या प्राप्तकर्ता के डिवाइस पर मैलवेयर मेमोरी से की चुरा सकता है। कोई समझौता किया गया ब्राउज़र एक्सटेंशन डिक्रिप्टेड फ़ाइल पढ़ सकता है। और किसी ग्रुप चैट में फॉरवर्ड किया गया लिंक हर क्रिप्टोग्राफ़िक गारंटी को खत्म कर देता है। यह संरचना उल्लंघन की लागत बढ़ाती है; यह सभी जोखिम समाप्त नहीं करती।

क्लाइंट-साइड एन्क्रिप्शन बनाम अन्य "सुरक्षित" विकल्प

PDF साझा करने के सामान्य विकल्पों की स्पष्ट तुलना। "सुरक्षित" लेबल वाले अधिकांश विकल्प ट्रांसपोर्ट-एन्क्रिप्टेड हैं — वे डेटा को ट्रांज़िट में सुरक्षित करते हैं, लेकिन प्राप्त करने वाला सर्वर अभी भी प्लेनटेक्स्ट और की रखता है।

विकल्पट्रांज़िट में TLSसर्वर फ़ाइल पढ़ सकता हैसमाप्तिप्राप्तकर्ता खाता
ईमेल अटैचमेंटआमतौर पर हाँहाँ — हर हॉप परहमेशा के लिएज़रूरी नहीं
सामान्य क्लाउड शेयर लिंकहाँहाँवैकल्पिककभी-कभी
पासवर्ड-सुरक्षित PDFहाँहाँ (यदि होस्ट के पास फ़ाइल है)कभी नहींज़रूरी नहीं
PDF Pro (फ्रैगमेंट मोड)हाँनहीं24 घंटे / 30 दिनज़रूरी नहीं
PDF Pro (पासफ्रेज़ मोड)हाँनहीं24 घंटे / 30 दिनज़रूरी नहीं

संबंधित पठन

सुरक्षा संरचना अवलोकन
खतरा मॉडल, साइनिंग फ्लो, और हम किससे बचाव करते हैं — DevTools-सत्यापन योग्य दावों के साथ।
सुरक्षित PDF ट्रांसफर, समझाया गया
ट्रांसफर एंड-टू-एंड कैसे दिखता है इसका उत्पाद वॉकथ्रू।
PDF सुरक्षित रूप से कैसे भेजें
ईमेल पर एन्क्रिप्टेड शेयरिंग कब चुनें, और प्राप्तकर्ता साइनअप के बिना यह कैसे करें।

ट्रस्ट-आवश्यक शेयरिंग बनाम zero-knowledge लाइव रेस

एक ही लक्ष्य — PDF साझा करना। दोनों ट्रस्ट मॉडल को साथ-साथ पूरा होते देखें।

cloud_upload
ट्रस्ट-आवश्यक शेयर
सर्वर प्लेनटेक्स्ट रखता है
  1. सर्वर पर PDF अपलोड करें
  2. सर्वर प्लेनटेक्स्ट रखता हैप्लेनटेक्स्ट
  3. सर्वर हटाने का वादा करता हैविश्वास
  4. उनकी तरफ से उल्लंघन का जोखिमजोखिम
  5. प्राप्तकर्ता प्लेनटेक्स्ट डाउनलोड करता हैउजागर
प्लेनटेक्स्ट सर्वर प्रतियाँ
1+
सर्वर पढ़ सकता है
हाँ
सर्वर पर किज़
हाँ
shield_lock
यह टूल
Zero-knowledge शेयर
  1. ब्राउज़र में PDF एन्क्रिप्ट करेंE2E
  2. सर्वर केवल सिफरटेक्स्ट रखता हैZero-knowledge
  3. प्राप्तकर्ता स्थानीय रूप से डिक्रिप्ट करता हैहो गया
check_circle
पहले ही साझा हो गया — और सर्वर इसे पढ़ नहीं सकता।
सर्वर पर कोई प्लेनटेक्स्ट नहीं। की की कस्टडी नहीं। डिज़ाइन से उल्लंघन-प्रूफ।
प्लेनटेक्स्ट सर्वर प्रतियाँ
0
सर्वर पढ़ सकता है
नहीं
सर्वर पर किज़
नहीं
एनिमेशन एक बार प्रति व्यू चलता है — दोबारा देखने के लिए टैप करें।

अक्सर पूछे जाने वाले प्रश्न

क्लाइंट-साइड एन्क्रिप्टेड PDF शेयरिंग का वास्तव में क्या अर्थ है?
इसका अर्थ है कि आपकी साझा की गई फ़ाइल संग्रहीत करने वाला सर्वर इसे सचमुच डिक्रिप्ट नहीं कर सकता। एन्क्रिप्शन की प्रेषक के ब्राउज़र में उत्पन्न होती है, कभी अपलोड नहीं होती, और केवल प्राप्तकर्ता का ब्राउज़र इसे पुनर्निर्मित कर सकता है — या तो URL फ्रैगमेंट से या उस पासफ्रेज़ से जिसे प्रेषक आउट-ऑफ-बैंड साझा करता है। गारंटी क्रिप्टोग्राफी द्वारा लागू होती है, किसी एक्सेस-कंट्रोल नीति द्वारा नहीं जिसे हम बदल सकें। नोट: यह औपचारिक zero-knowledge proofs (ZKPs) से अलग है, जिसका यह उत्पाद उपयोग नहीं करता।
PDF Pro क्लाइंट-साइड एन्क्रिप्टेड शेयरिंग के लिए कौन सी एन्क्रिप्शन उपयोग करता है?
प्रति फ़ाइल 96-बिट रैंडम इनिशियलाइज़ेशन वेक्टर के साथ AES-256-GCM सिमेट्रिक एन्क्रिप्शन। पासफ्रेज़ मोड के लिए, किज़ 128-बिट रैंडम सॉल्ट पर PBKDF2-SHA256 के 310,000 इटरेशन के ज़रिए डेराइव होती हैं। सभी क्रिप्टो ब्राउज़र के मूल Web Crypto API में चलता है।
फ्रैगमेंट मोड और पासफ्रेज़ मोड में क्या अंतर है?
फ्रैगमेंट मोड 256-बिट की को URL हैश (जो # के बाद होता है) में रखता है, जिसे ब्राउज़र कभी किसी सर्वर को नहीं भेजते। पूरे लिंक वाला कोई भी व्यक्ति डिक्रिप्ट कर सकता है। पासफ्रेज़ मोड की को उस पासफ्रेज़ से डेराइव करता है जिसे प्रेषक चुनता है; उसके बिना सिफरटेक्स्ट अपठनीय रहता है। यदि लिंक लीक हो जाए तो पासफ्रेज़ मोड अधिक सुरक्षित है; कम-झंझट शेयरिंग के लिए फ्रैगमेंट मोड आसान है। ऊपर की तुलना तालिका देखें।
क्या URL फ्रैगमेंट वास्तव में एन्क्रिप्शन की वाहक के रूप में सुरक्षित है?
अनुपालित ब्राउज़र URL के फ्रैगमेंट हिस्से (# के बाद का भाग) को कभी सर्वर को नहीं भेजते। यह क्लाइंट-साइड रहता है और केवल प्राप्तकर्ता के टैब में चल रहे JavaScript के लिए दृश्यमान है। यही शेयर लिंक को डिक्रिप्शन क्रेडेंशियल बनाता है — की प्राप्तकर्ता के साथ यात्रा करती है, अपलोड के साथ नहीं। आप इसे अपने ब्राउज़र के Network टैब में सत्यापित कर सकते हैं: अनुरोध URL ? या # पर काट दिया जाता है।
क्या PDF Pro या कोई अदालत क्लाइंट-साइड एन्क्रिप्टेड शेयरिंग के ज़रिए संग्रहीत फ़ाइलें पढ़ सकती है?
नहीं। सर्वर AES-256-GCM सिफरटेक्स्ट और एक इनिशियलाइज़ेशन वेक्टर संग्रहीत करता है (पासफ्रेज़ मोड में सॉल्ट सहित)। की के बिना — जो हमें कभी नहीं मिली — वह डेटा क्रिप्टोग्राफ़िक रूप से यादृच्छिक बाइट्स से अप्रभेद्य है। हम केवल सिफरटेक्स्ट प्रकट कर सकते हैं, जो हमारे पास है।
यदि मैं लिंक खो दूँ या पासफ्रेज़ भूल जाऊँ तो क्या होगा?
फ़ाइल स्थायी रूप से अनरिकवरेबल है। यह डिज़ाइन के अनुसार है — क्लाइंट-साइड एन्क्रिप्शन का अर्थ है कोई रिकवरी रास्ता नहीं, क्योंकि रिकवरी रास्ते के लिए हमें की रखनी होगी। पासफ्रेज़ को पासवर्ड मैनेजर में सहेजें और लिंक को कहीं टिकाऊ स्थान पर रखें।
क्या क्लाइंट-साइड एन्क्रिप्टेड PDF शेयरिंग मुफ्त है?
हाँ। मुफ्त टियर AES-256-GCM एन्क्रिप्शन और 24 घंटे की लिंक समाप्ति के साथ बिना साइनअप के उपलब्ध है। मुफ्त-टियर फ़ाइल सीमा लगभग 25 MB प्रति ट्रांसफर है; Pro समाप्ति विंडो को 30 दिन तक बढ़ाता है और फ़ाइल-साइज़ सीमाएँ बढ़ाता है।
क्या प्राप्तकर्ता को कोई खाता चाहिए?
नहीं। प्राप्तकर्ता लिंक पर क्लिक करता है, उनका ब्राउज़र Web Crypto API के ज़रिए स्थानीय रूप से डिक्रिप्ट करता है, और वे फ़ाइल डाउनलोड करते हैं — कोई साइनअप नहीं, कोई इंस्टॉल नहीं, फ़ाइल और उनके बीच कोई पोर्टल की दीवार नहीं।

एक एंड-टू-एंड एन्क्रिप्टेड लिंक भेजें। इसे समय पर समाप्त होने दें।

आपके ब्राउज़र में AES-256-GCM एन्क्रिप्शन। कोई साइनअप नहीं, सर्वर-साइड प्लेनटेक्स्ट नहीं, कोई रिकवरी बैकडोर नहीं।

sendएन्क्रिप्टेड लिंक बनाएँ