तकनीकी श्वेतपत्र

यह श्वेतपत्र PDF Pro की Secure Transfer प्रणाली के आर्किटेक्चर का वर्णन करता है — यह एक एंड-टू-एंड एन्क्रिप्टेड फ़ाइल ट्रांसफर तंत्र है जिसमें फ़ाइलें अपलोड से पहले AES-256-GCM का उपयोग करके क्लाइंट-साइड एन्क्रिप्ट की जाती हैं। सर्वर केवल अपारदर्शी सिफरटेक्स्ट संग्रहीत करता है और किसी भी बिंदु पर फ़ाइल सामग्री को डिक्रिप्ट, निरीक्षण या पढ़ने में सक्षम नहीं होता। यह प्रणाली दो मुख्य मोड का समर्थन करती है: एक स्वतः-उत्पन्न यादृच्छिक कुंजी (URL फ्रैगमेंट के माध्यम से परिवहित, जो कभी सर्वर को नहीं भेजी जाती) या PBKDF2 का उपयोग करके पासफ्रेज़-व्युत्पन्न कुंजी। दोनों मोड में, एन्क्रिप्शन कुंजी केवल प्रेषक और प्राप्तकर्ता के ब्राउज़र में मौजूद रहती है। यह दस्तावेज़ प्रणाली के क्रिप्टोग्राफ़िक प्रिमिटिव, डेटा प्रवाह, खतरे के मॉडल और ईमानदार सीमाओं का विवरण देता है। शब्दावली पर नोट: यह प्रणाली जीरो-नॉलेज प्रूफ (ZKPs) का उपयोग नहीं करती। जब हम कहते हैं कि सर्वर को आपकी फ़ाइलों की "शून्य जानकारी" है, तो हमारा तात्पर्य है — क्लाइंट-साइड एन्क्रिप्शन के परिणामस्वरूप — सर्वर केवल ऐसा सिफरटेक्स्ट रखता है जिसे वह डिक्रिप्ट नहीं कर सकता।

Secure Transfer प्रणाली एक सख्त क्लाइंट-सर्वर पृथक्करण का पालन करती है जहाँ सभी क्रिप्टोग्राफ़िक संक्रियाएँ विशेष रूप से ब्राउज़र में होती हैं:

• क्लाइंट (ब्राउज़र): कुंजी व्युत्पत्ति, एन्क्रिप्शन, डिक्रिप्शन, फ़ाइल पठन, फ़ाइल पुनर्निर्माण।
• सर्वर (Supabase Storage + Serverless Functions): एन्क्रिप्टेड ब्लॉब संग्रहीत करता है, मेटाडेटा प्रबंधित करता है (समाप्ति, डाउनलोड गिनती), एक्सेस नीतियाँ लागू करता है।

सर्वर को जानबूझकर एन्क्रिप्टेड डेटा के लिए एक "डम्ब पाइप" के रूप में डिज़ाइन किया गया है। उसे एन्क्रिप्शन कुंजी, पासफ्रेज़ या फ़ाइल सामग्री का कोई ज्ञान नहीं है। यह आर्किटेक्चरल रूप से लागू है, न केवल नीति द्वारा।

सभी फ़ाइल एन्क्रिप्शन AES-256-GCM प्रमाणित एन्क्रिप्शन एल्गोरिदम का उपयोग करता है, जो ब्राउज़र के नेटिव Web Crypto API के माध्यम से एक्सेस किया जाता है। यह गोपनीयता (डेटा पढ़ा नहीं जा सकता) और अखंडता (बिना पहचान के डेटा संशोधित नहीं किया जा सकता) दोनों प्रदान करता है।

1.3.1 एल्गोरिदम पैरामीटर

1.3.2 एन्क्रिप्शन कार्यान्वयन

// Simplified encryption flow (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Derive key from passphrase (see Section 1.4)
const key = await deriveKey(passphrase, salt);

// Encrypt the file
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Package: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

अंतिम एन्क्रिप्टेड ब्लॉब तीन घटकों का संयोजन है: 16-बाइट सॉल्ट (कुंजी व्युत्पत्ति के लिए उपयोग), 12-बाइट IV (AES-GCM के लिए उपयोग), और संलग्न 16-बाइट GCM प्रमाणीकरण टैग के साथ सिफरटेक्स्ट। यही ब्लॉब सर्वर को प्राप्त होता है और संग्रहीत किया जाता है।

Secure Transfer दो परस्पर अनन्य कुंजी मोड का समर्थन करता है। मोड का चयन प्रेषक द्वारा ट्रांसफर निर्माण के समय किया जाता है।

1.4.1 मोड A — स्वतः-उत्पन्न कुंजी (डिफ़ॉल्ट)

डिफ़ॉल्ट मोड में, कोई पासफ्रेज़ शामिल नहीं होता। ब्राउज़र सीधे एक क्रिप्टोग्राफ़िक रूप से यादृच्छिक 256-बिट AES कुंजी उत्पन्न करता है:

• ब्राउज़र crypto.getRandomValues() और crypto.subtle.generateKey() के माध्यम से एक यादृच्छिक 256-बिट AES-GCM कुंजी उत्पन्न करता है।
• कुंजी को रॉ बाइट्स के रूप में निर्यात किया जाता है और URL फ्रैगमेंट (#) में रखा जाता है।
• HTTP विनिर्देश के अनुसार, URL फ्रैगमेंट कभी सर्वर को नहीं भेजा जाता — यह विशेष रूप से ब्राउज़र द्वारा संसाधित होता है।
• प्रेषक पूर्ण URL (फ्रैगमेंट सहित) को अपने पसंदीदा चैनल (जैसे, मैसेजिंग ऐप, ईमेल) के माध्यम से प्राप्तकर्ता के साथ साझा करता है।
• प्राप्तकर्ता का ब्राउज़र URL फ्रैगमेंट से कुंजी निकालता है और फ़ाइल को डिक्रिप्ट करने के लिए उसका उपयोग करता है।

1.4.2 मोड B — पासफ्रेज़-सुरक्षित ट्रांसफर

जब प्रेषक पासफ्रेज़ सेट करने का विकल्प चुनता है, तो PBKDF2 का उपयोग करके उस पासफ्रेज़ से कुंजी व्युत्पन्न की जाती है:

• उपयोगकर्ता एक पासफ्रेज़ प्रदान करता है।
• PBKDF2-SHA256 के माध्यम से पासफ्रेज़ से AES-256 कुंजी व्युत्पन्न की जाती है।
• पैरामीटर: 600,000 इटरेशन, यादृच्छिक 16-बाइट सॉल्ट।
• व्युत्पन्न कुंजी फ़ाइल को एन्क्रिप्ट करती है।
• सॉल्ट को सिफरटेक्स्ट के साथ संग्रहीत किया जाता है (एन्क्रिप्टेड ब्लॉब में प्रीपेंड किया जाता है)।
• पासफ्रेज़ आउट-ऑफ-बैंड (लिंक से अलग) साझा किया जाता है।
• पासफ्रेज़ रिकवरी संभव नहीं है — न सर्वर और न ही PDF Pro एक भूला हुआ पासफ्रेज़ पुनः प्राप्त कर सकते हैं।

1.4.3 PBKDF2 पैरामीटर (मोड B)

1.4.4 कुंजी व्युत्पत्ति कार्यान्वयन (मोड B)

async function deriveKey(passphrase, salt) {
  // Import passphrase as raw key material
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Derive AES-256-GCM key
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

एक सुरक्षित ट्रांसफर का पूर्ण जीवनचक्र इस मार्ग का अनुसरण करता है:

1.5.1 भेजना (अपलोड) — मोड A (स्वतः-उत्पन्न कुंजी)

1. प्रेषक ब्राउज़र में एक फ़ाइल चुनता है।
2. ब्राउज़र crypto.getRandomValues() का उपयोग करके एक यादृच्छिक 256-बिट AES-GCM कुंजी और एक यादृच्छिक 12-बाइट IV उत्पन्न करता है।
3. ब्राउज़र AES-256-GCM का उपयोग करके फ़ाइल को एन्क्रिप्ट करता है, जिससे सिफरटेक्स्ट + प्रमाणीकरण टैग उत्पन्न होता है।
4. ब्राउज़र [IV | ciphertext+tag] को एक ब्लॉब में संयोजित करता है।
5. ब्राउज़र HTTPS के माध्यम से एन्क्रिप्टेड ब्लॉब को सर्वर पर अपलोड करता है।
6. सर्वर ब्लॉब को Supabase Storage में संग्रहीत करता है और एक मेटाडेटा रिकॉर्ड बनाता है (ट्रांसफर ID, समाप्ति, डाउनलोड सीमा, फ़ाइल नाम, फ़ाइल आकार)।
7. सर्वर एक ट्रांसफर URL लौटाता है। ब्राउज़र निर्यातित कुंजी को URL फ्रैगमेंट (#) में जोड़ता है।
8. प्रेषक प्राप्तकर्ता के साथ पूर्ण URL (फ्रैगमेंट सहित) साझा करता है।

1.5.2 भेजना (अपलोड) — मोड B (पासफ्रेज़)

1. प्रेषक ब्राउज़र में एक फ़ाइल चुनता है और पासफ्रेज़ दर्ज करता है।
2. ब्राउज़र crypto.getRandomValues() का उपयोग करके एक यादृच्छिक 16-बाइट सॉल्ट और 12-बाइट IV उत्पन्न करता है।
3. ब्राउज़र PBKDF2 (600K इटरेशन) का उपयोग करके पासफ्रेज़ से AES-256 कुंजी व्युत्पन्न करता है।
4. ब्राउज़र AES-256-GCM का उपयोग करके फ़ाइल को एन्क्रिप्ट करता है, जिससे सिफरटेक्स्ट + प्रमाणीकरण टैग उत्पन्न होता है।
5. ब्राउज़र [salt | IV | ciphertext+tag] को एक ब्लॉब में संयोजित करता है।
6. ब्राउज़र HTTPS के माध्यम से एन्क्रिप्टेड ब्लॉब को सर्वर पर अपलोड करता है।
7. सर्वर ब्लॉब को Supabase Storage में संग्रहीत करता है और एक मेटाडेटा रिकॉर्ड बनाता है (ट्रांसफर ID, समाप्ति, डाउनलोड सीमा, फ़ाइल नाम, फ़ाइल आकार)।
8. सर्वर ट्रांसफर ID युक्त ट्रांसफर URL लौटाता है।
9. प्रेषक ट्रांसफर URL और पासफ्रेज़ को अलग-अलग चैनलों के माध्यम से प्राप्तकर्ता के साथ साझा करता है।

1.5.3 प्राप्त करना (डाउनलोड) — मोड A

1. प्राप्तकर्ता पूर्ण ट्रांसफर URL खोलता है (फ्रैगमेंट में कुंजी के साथ)।
2. ब्राउज़र URL फ्रैगमेंट से AES कुंजी निकालता है (कभी सर्वर को नहीं भेजी जाती)।
3. ब्राउज़र HTTPS के माध्यम से सर्वर से एन्क्रिप्टेड ब्लॉब डाउनलोड करता है।
4. ब्राउज़र ब्लॉब से IV (पहले 12 बाइट) निकालता है।
5. ब्राउज़र निकाली गई कुंजी और IV के साथ AES-256-GCM का उपयोग करके सिफरटेक्स्ट को डिक्रिप्ट करता है।
6. यदि डिक्रिप्शन सफल होता है (GCM टैग मान्य), तो प्लेनटेक्स्ट फ़ाइल उपयोगकर्ता को प्रस्तुत की जाती है।
7. सर्वर डाउनलोड काउंटर अपडेट करता है और, यदि बर्न-ऑन-रीड सक्षम है, तो ब्लॉब हटा देता है।

1.5.4 प्राप्त करना (डाउनलोड) — मोड B

1. प्राप्तकर्ता ट्रांसफर URL खोलता है और ब्राउज़र में पासफ्रेज़ दर्ज करता है।
2. ब्राउज़र HTTPS के माध्यम से सर्वर से एन्क्रिप्टेड ब्लॉब डाउनलोड करता है।
3. ब्राउज़र ब्लॉब से सॉल्ट (पहले 16 बाइट) और IV (अगले 12 बाइट) निकालता है।
4. ब्राउज़र PBKDF2 (600K इटरेशन) का उपयोग करके पासफ्रेज़ + सॉल्ट से AES-256 कुंजी व्युत्पन्न करता है।
5. ब्राउज़र व्युत्पन्न कुंजी और IV के साथ AES-256-GCM का उपयोग करके सिफरटेक्स्ट को डिक्रिप्ट करता है।
6. यदि डिक्रिप्शन सफल होता है (GCM टैग मान्य), तो प्लेनटेक्स्ट फ़ाइल उपयोगकर्ता को प्रस्तुत की जाती है।
7. यदि डिक्रिप्शन विफल होता है (गलत पासफ्रेज़ = गलत कुंजी = अमान्य GCM टैग), तो एक त्रुटि दिखाई जाती है।
8. सर्वर डाउनलोड काउंटर अपडेट करता है और, यदि बर्न-ऑन-रीड सक्षम है, तो ब्लॉब हटा देता है।

डिज़ाइन के अनुसार सभी सुरक्षित ट्रांसफर क्षणिक हैं। स्थायी भंडारण का कोई विकल्प नहीं है।

1.7.1 समाप्ति विकल्प

1.7.2 हटाने की गारंटी

जब कोई ट्रांसफर समाप्त होता है या बर्न ऑन रीड होता है, तो एन्क्रिप्टेड ब्लॉब Supabase Storage से स्थायी रूप से हटा दिया जाता है। मेटाडेटा रिकॉर्ड को स्थायी रूप से हटाने से पहले 30 दिनों के लिए सॉफ्ट-डिलीटेड स्थिति में (दुरुपयोग जाँच के लिए) रखा जाता है। मेटाडेटा रिकॉर्ड में एन्क्रिप्शन कुंजी, पासफ्रेज़, या कोई भी ऐसी जानकारी नहीं होती जिसका उपयोग फ़ाइल को पुनर्निर्मित करने के लिए किया जा सके।

1.8.1 धारणाएँ

• विश्वसनीय ब्राउज़र रनटाइम (कोई दुर्भावनापूर्ण एक्सटेंशन नहीं)
• लिंक/पासफ्रेज़ साझा करने के लिए सुरक्षित चैनल
• HTTPS टर्मिनेशन विश्वसनीय है
• प्राप्तकर्ता डिवाइस से समझौता नहीं हुआ है
• स्क्रीन कैप्चर रोकथाम नहीं है

1.8.2 दायरे से बाहर

• एंडपॉइंट डिवाइस पर मैलवेयर
• सोशल इंजीनियरिंग / फिशिंग अटैक
• प्राप्तकर्ताओं द्वारा स्क्रीन कैप्चर
• समझौता किए गए ब्राउज़र एक्सटेंशन
• क्वांटम कम्प्यूटिंग अटैक (भविष्य की विचारणीय बात)

• पासफ्रेज़ की ताकत उपयोगकर्ता-नियंत्रित है। हम UI में न्यूनतम लंबाई लागू कर सकते हैं, लेकिन हम उपयोगकर्ताओं को कमज़ोर पासफ्रेज़ चुनने से नहीं रोक सकते। एन्क्रिप्शन की सुरक्षा सीधे पासफ्रेज़ की एन्ट्रॉपी के अनुपात में होती है।
• पासफ्रेज़ संचरण आउट-ऑफ-बैंड है। हम पासफ्रेज़ साझा करने के लिए कोई सुरक्षित चैनल प्रदान नहीं करते। यदि पासफ्रेज़ असुरक्षित चैनल (जैसे, ट्रांसफर URL के साथ अनएन्क्रिप्टेड ईमेल) पर साझा किया जाता है, तो सुरक्षा मॉडल कमज़ोर हो जाता है।
• फ़ाइल मेटाडेटा एन्क्रिप्टेड नहीं है। मूल फ़ाइल नाम और फ़ाइल आकार सर्वर पर प्लेनटेक्स्ट में संग्रहीत हैं। यह ट्रांसफर की गई फ़ाइल के प्रकार और अनुमानित प्रकृति को प्रकट करता है, भले ही उसकी सामग्री एन्क्रिप्टेड रहे।
• क्लाइंट-साइड कोड विश्वास। उपयोगकर्ताओं को विश्वास करना होगा कि हमारे CDN द्वारा परोसा गया JavaScript सही, अपरिवर्तित कोड है। एक समझौता किया गया CDN या DNS हाइजैक दुर्भावनापूर्ण JavaScript परोस सकता है। यह सभी वेब-आधारित क्रिप्टोग्राफी की एक मौलिक सीमा है।
• कोई फॉरवर्ड सेक्रेसी नहीं। यदि एन्क्रिप्टेड ब्लॉब हटाए जाने से पहले किसी भी बिंदु पर पासफ्रेज़ से समझौता हो जाता है, तो ब्लॉब की संग्रहीत प्रति को डिक्रिप्ट किया जा सकता है। बर्न-ऑन-रीड और कम समाप्ति समय इसे कम करते हैं।
• ब्राउज़र सुरक्षा मॉडल निर्भरता। प्रणाली की सुरक्षा ब्राउज़र के Web Crypto API कार्यान्वयन और उसके मेमोरी आइसोलेशन पर निर्भर करती है। एक समझौता किया गया ब्राउज़र या दुर्भावनापूर्ण ब्राउज़र एक्सटेंशन सभी क्लाइंट-साइड सुरक्षा को कमज़ोर कर सकता है।
• क्वांटम कम्प्यूटिंग। AES-256 को क्वांटम-प्रतिरोधी माना जाता है (Grover का एल्गोरिदम प्रभावी सुरक्षा को 128 बिट तक कम करता है, जो अभी भी असंभव है)। हालाँकि, SHA-256 के साथ PBKDF2 विशेष रूप से पोस्ट-क्वांटम प्रतिरोध के लिए डिज़ाइन नहीं है। यह निकट भविष्य की चिंता नहीं है लेकिन पूर्णता के लिए उल्लिखित है।

यह श्वेतपत्र PDF Pro की Privacy Signature प्रणाली के आर्किटेक्चर का वर्णन करता है — यह एक क्रिप्टोग्राफ़िक दस्तावेज़ हस्ताक्षर तंत्र है जहाँ PDF दस्तावेज़ हस्ताक्षरकर्ता के ब्राउज़र को कभी नहीं छोड़ता। यह प्रणाली डिटैच्ड डिजिटल हस्ताक्षर उत्पन्न करने के लिए P-256 कर्व और SHA-256 हैशिंग के साथ ECDSA का उपयोग करती है। केवल दस्तावेज़ हैश, क्रिप्टोग्राफ़िक हस्ताक्षर और सार्वजनिक कुंजी सर्वर को प्रेषित की जाती हैं। निजी कुंजियाँ उत्पन्न, एन्क्रिप्ट और विशेष रूप से उपयोगकर्ता के ब्राउज़र में IndexedDB का उपयोग करके संग्रहीत की जाती हैं, जो PBKDF2 कुंजी व्युत्पत्ति (600,000 इटरेशन) और AES-256-GCM एन्क्रिप्शन द्वारा सुरक्षित हैं। यह दस्तावेज़ पूर्ण हस्ताक्षर और सत्यापन आर्किटेक्चर, कुंजी प्रबंधन मॉडल, हस्ताक्षरित पेलोड स्कीमा, ऑडिट ट्रेल डिज़ाइन, खतरे के मॉडल और ईमानदार सीमाओं का विवरण देता है।

Privacy Signature प्रणाली एक मूलभूत बाधा के इर्द-गिर्द डिज़ाइन की गई है: PDF दस्तावेज़ को कभी सर्वर को प्रेषित नहीं किया जाना चाहिए। यह डिटैच्ड सिग्नेचर मॉडल के माध्यम से आर्किटेक्चरल रूप से लागू है।

• क्लाइंट (ब्राउज़र): कुंजी उत्पादन, कुंजी भंडारण (IndexedDB में एन्क्रिप्टेड), दस्तावेज़ हैशिंग (SHA-256), हस्ताक्षर उत्पादन (ECDSA P-256), हस्ताक्षर सत्यापन।
• सर्वर (Supabase): सार्वजनिक कुंजियाँ, हस्ताक्षर रिकॉर्ड (हैश + हस्ताक्षर + मेटाडेटा), ऑडिट ट्रेल इवेंट संग्रहीत करता है। PDF दस्तावेज़, निजी कुंजियाँ या कुंजी पासफ्रेज़ कभी प्राप्त नहीं करता।

2.3.1 एल्गोरिदम पैरामीटर

2.3.2 हस्ताक्षर प्रवाह

// 1. Hash the PDF document (client-side)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Sign the hash with the private key (client-side)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey from IndexedDB (decrypted)
  hashBuffer
);

// 3. Send to server: hash + signature + public key (NOT the PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 कुंजी उत्पादन

// Generate ECDSA P-256 key pair (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extractable (needed for encryption + storage)
  ["sign", "verify"]
);

// Export public key as JWK for server registration
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Export private key as JWK for encrypted storage
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

परसिस्टेंट निजी कुंजियाँ कभी प्लेनटेक्स्ट में संग्रहीत नहीं की जाती हैं। IndexedDB में लिखे जाने से पहले, निजी कुंजी (JWK JSON के रूप में निर्यातित) को Secure Transfer के समान पैटर्न का उपयोग करके एन्क्रिप्ट किया जाता है:

2.5.1 सुरक्षा पैरामीटर

2.5.2 स्टोरेज स्कीमा

// IndexedDB record structure for an encrypted signing key
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* JWK format, unencrypted */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

PDF Pro एक डिटैच्ड सिग्नेचर मॉडल का उपयोग करता है, जिसका अर्थ है कि हस्ताक्षर दस्तावेज़ से अलग संग्रहीत किया जाता है। यह महत्वपूर्ण गोपनीयता तंत्र है: दस्तावेज़ कभी हस्ताक्षरकर्ता के डिवाइस को नहीं छोड़ता।

2.6.1 सर्वर को क्या भेजा जाता है

• PDF का SHA-256 हैश (32 बाइट, 64 वर्णों में हेक्स-एन्कोडेड)।
• हैश पर ECDSA हस्ताक्षर (64 बाइट, base64-एन्कोडेड)।
• हस्ताक्षरकर्ता की सार्वजनिक कुंजी (JWK प्रारूप)।
• मेटाडेटा: हस्ताक्षरकर्ता का प्रदर्शन नाम, हस्ताक्षरकर्ता ईमेल (यदि प्रमाणित), टाइमस्टैम्प, हस्ताक्षर ID।

2.6.2 सर्वर को क्या नहीं भेजा जाता

• PDF दस्तावेज़ स्वयं — कभी प्रेषित नहीं।
• निजी कुंजी — कभी ब्राउज़र नहीं छोड़ती।
• हस्ताक्षर पासफ्रेज़ — कभी ब्राउज़र नहीं छोड़ता।
• PDF से कोई भी पेज सामग्री, टेक्स्ट या छवियाँ।

निम्नलिखित JSON स्कीमा सर्वर पर संग्रहीत पूर्ण हस्ताक्षर रिकॉर्ड को परिभाषित करती है:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": "sha256-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

हस्ताक्षर सत्यापन एक दो-चरण प्रक्रिया है: क्लाइंट-साइड क्रिप्टोग्राफ़िक सत्यापन के बाद सर्वर-साइड क्रॉस-चेकिंग।

2.8.1 चरण 1: क्लाइंट-साइड क्रिप्टोग्राफ़िक सत्यापन

1. उपयोगकर्ता ब्राउज़र में एक PDF लोड करता है।
2. ब्राउज़र लोड किए गए PDF का SHA-256 हैश गणना करता है।
3. ब्राउज़र इस हैश से मेल खाने वाले किसी भी हस्ताक्षर रिकॉर्ड के लिए सर्वर से क्वेरी करता है।
4. लौटाए गए प्रत्येक हस्ताक्षर रिकॉर्ड के लिए, ब्राउज़र ECDSA सत्यापन करता है:

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. यदि isValid === true, तो हस्ताक्षर क्रिप्टोग्राफ़िक रूप से वैध है: हस्ताक्षर के बाद से दस्तावेज़ संशोधित नहीं हुआ है, और हस्ताक्षर संबंधित निजी कुंजी के धारक द्वारा उत्पन्न किया गया था।

2.8.2 चरण 2: सर्वर-साइड क्रॉस-चेक

1. सर्वर पुष्टि करता है कि हस्ताक्षर रिकॉर्ड में सार्वजनिक कुंजी एक ज्ञात उपयोगकर्ता को पंजीकृत है (प्रमाणित हस्ताक्षरों के लिए)।
2. सर्वर पुष्टि करता है कि हस्ताक्षर रिकॉर्ड रिवोक नहीं किया गया है।
3. सर्वर ऑडिट ट्रेल अखंडता की पुष्टि करता है (हैश चेन सत्यापन)।
4. सर्वर हस्ताक्षरकर्ता का पहचान स्तर और पंजीकरण स्थिति लौटाता है।

2.8.3 सत्यापन परिणाम

प्रत्येक हस्ताक्षर और सत्यापन इवेंट एक टैम्पर-एविडेंट ऑडिट ट्रेल में दर्ज किया जाता है। इवेंट हैश-चेन्ड होते हैं: प्रत्येक इवेंट में पिछले इवेंट का SHA-256 हैश शामिल होता है, जो एक ब्लॉकचेन के समान एक अपेंड-ओनली चेन बनाता है।

2.9.1 ऑडिट इवेंट प्रकार

2.9.2 हैश चेन संरचना

// Each audit event includes:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* event-specific payload */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Tamper detection: to verify the chain, compute:
// SHA-256(JSON.stringify(event without eventHash field))
// and confirm it matches eventHash.
// Then confirm previousEventHash matches the prior event's eventHash.

यदि चेन में कोई भी इवेंट संशोधित किया जाता है, तो सभी बाद के हैश लिंक टूट जाएंगे, जिससे टैम्परिंग तुरंत पहचाने योग्य हो जाती है। यह ऑडिट ट्रेल अखंडता की एक मज़बूत गारंटी प्रदान करता है।

नोट: प्रोडक्ट UI में, 'self_asserted' को 'स्व-अभिकथित पहचान' या 'गेस्ट साइनिंग' के रूप में प्रदर्शित किया जा सकता है। 'authenticated' को 'प्रमाणित खाता' के रूप में प्रदर्शित किया जा सकता है। ये समान अंतर्निहित पहचान स्तरों के लिए प्रदर्शन लेबल हैं।

2.11.1 धारणाएँ

• विश्वसनीय ब्राउज़र रनटाइम
• Web Crypto API कार्यान्वयन सही है
• IndexedDB अन्य ऑरिजिन के लिए एक्सेसिबल नहीं है
• उपयोगकर्ता अपना पासफ्रेज़ सुरक्षित रखता है
• सर्वर कोड प्रकाशित व्यवहार से मेल खाता है

2.11.2 दायरे से बाहर

• एंडपॉइंट डिवाइस पर मैलवेयर
• सोशल इंजीनियरिंग / फिशिंग अटैक
• प्राप्तकर्ताओं द्वारा स्क्रीन कैप्चर
• समझौता किए गए ब्राउज़र एक्सटेंशन
• क्वांटम कम्प्यूटिंग अटैक (भविष्य की विचारणीय बात)

• योग्य इलेक्ट्रॉनिक हस्ताक्षर (QES) नहीं। PDF Pro हस्ताक्षर EU विनियम 910/2014 (eIDAS) की योग्य इलेक्ट्रॉनिक हस्ताक्षर की आवश्यकताओं को पूरा नहीं करते। हम एक योग्य ट्रस्ट सेवा प्रदाता (QTSP) नहीं हैं, और हमारी हस्ताक्षर कुंजियाँ योग्य हस्ताक्षर निर्माण डिवाइस (QSCD) पर उत्पन्न नहीं की जाती हैं।
• eIDAS योग्य नहीं। eIDAS के तहत, केवल योग्य इलेक्ट्रॉनिक हस्ताक्षरों को सभी EU सदस्य राज्यों में हस्तलिखित हस्ताक्षर के कानूनी समकक्ष माना जाता है। PDF Pro हस्ताक्षर अधिक से अधिक उन्नत इलेक्ट्रॉनिक हस्ताक्षर हैं, और उनकी कानूनी स्थिति विशिष्ट अधिकार क्षेत्र और उपयोग मामले पर निर्भर करती है।
• Adobe-विश्वसनीय नहीं। PDF Pro हस्ताक्षर Adobe Approved Trust List (AATL) पर नहीं दिखते। Adobe Acrobat में PDF Pro-हस्ताक्षरित दस्तावेज़ खोलने पर, हस्ताक्षर Adobe के UI में "विश्वसनीय" के रूप में नहीं दिखेगा। सत्यापन PDF Pro की सत्यापन प्रणाली के माध्यम से किया जाना चाहिए।
• प्रमाणपत्र प्राधिकरण नहीं। हम X.509 प्रमाणपत्र जारी नहीं करते। हमारी सार्वजनिक कुंजी अवसंरचना PDF Pro के लिए स्वामित्व है और सरकारी एजेंसियों या प्रमाणपत्र प्राधिकरणों द्वारा उपयोग की जाने वाली PKI प्रणालियों के साथ इंटरऑपरेबल नहीं है।
• नोटराइज़ेशन नहीं। PDF Pro हस्ताक्षर नोटराइज़ेशन, अपोस्टिल, या सरकारी-प्रमाणित दस्तावेज़ प्रमाणीकरण के किसी भी रूप का गठन नहीं करते।
• कोई वास्तविक-दुनिया पहचान सत्यापन नहीं। हम Supabase Auth के माध्यम से ईमेल पते सत्यापित करते हैं, लेकिन हम सरकारी ID सत्यापन, बायोमेट्रिक सत्यापन, या व्यक्तिगत पहचान प्रमाणन नहीं करते।

2.12.1 PDF Pro हस्ताक्षर किसके लिए उपयुक्त हैं

• व्यावसायिक वर्कफ़्लो — आंतरिक दस्तावेज़ अनुमोदन, टीम साइन-ऑफ, खरीद प्राधिकरण जहाँ पक्षकार PDF Pro पहचान मॉडल पर भरोसा करते हैं।
• अखंडता सत्यापन — यह साबित करना कि किसी विशिष्ट समय बिंदु के बाद से दस्तावेज़ संशोधित नहीं हुआ है।
• नॉन-रिपुडिएशन (सीमित) — यह प्रदर्शित करना कि एक विशिष्ट निजी कुंजी के धारक ने एक विशिष्ट समय पर एक विशिष्ट दस्तावेज़ पर हस्ताक्षर किया। नॉन-रिपुडिएशन की ताकत इस बात पर निर्भर करती है कि निजी कुंजी कितनी अच्छी तरह सुरक्षित है और सार्वजनिक कुंजी किसी पहचान से कैसे बाउंड है।
• ऑडिट अनुपालन — आंतरिक अनुपालन आवश्यकताओं के लिए दस्तावेज़ हस्ताक्षर इवेंट का टैम्पर-एविडेंट ऑडिट ट्रेल प्रदान करना।
• अनुबंध हस्ताक्षर — कई अधिकार क्षेत्रों में, ESIGN (US), UETA (US), और eIDAS Article 25(1) (EU) जैसे कानूनों के तहत इलेक्ट्रॉनिक हस्ताक्षर (गैर-योग्य सहित) अधिकांश वाणिज्यिक अनुबंधों के लिए कानूनी रूप से वैध हैं।