कॉन्क्रिप्टर

Rust में निर्मित एक मल्टी-थ्रेडेड AEAD एन्क्रिप्शन इंजन। ट्रिपल-बफर्ड io_uring पाइपलाइन, Rayon के माध्यम से समानांतर चंक प्रोसेसिंग, और ring के माध्यम से असेंबली-ऑप्टिमाइज्ड सिफर का उपयोग करके गीगाबाइट-प्रति-सेकंड थ्रूपुट पर फ़ाइलों को एन्क्रिप्ट और डिक्रिप्ट करता है।

⚠️ अस्वीकरण: प्रयोगात्मक सॉफ्टवेयर ⚠️

यह प्रोजेक्ट अत्यंत नया है और वर्तमान में उत्पादन या मिशन-महत्वपूर्ण उपयोग के लिए अनुशंसित नहीं है। हालांकि क्रिप्टोग्राफिक प्राइमिटिव (AES-256-GCM, ChaCha20-Poly1305 via ring) और प्रारूप डिज़ाइन सुदृढ़ हैं, कोडबेस का औपचारिक सुरक्षा ऑडिट या व्यापक वास्तविक दुनिया परीक्षण नहीं हुआ है। अपने जोखिम पर उपयोग करें। संवेदनशील डेटा की सुरक्षा के लिए, इस प्रोजेक्ट के परिपक्व होने तक GnuPG, age, या OpenSSL जैसे युद्ध-परीक्षित टूल का उपयोग करने पर विचार करें।

विशेषताएँ

• दोहरी सिफर सपोर्ट: AES-256-GCM (हार्डवेयर AES-NI) और ChaCha20-Poly1305 via ring (असेंबली-ऑप्टिमाइज्ड)
• समानांतर एन्क्रिप्शन: Rayon-आधारित मल्टी-थ्रेडेड चंक प्रोसेसिंग सभी CPU कोर में
• ट्रिपल-बफर्ड io_uring पाइपलाइन: तीन घूर्णन बफर पूल का उपयोग करके कर्नेल I/O और CPU-साइड क्रिप्टो को ओवरलैप करता है — जबकि एक बैच के राइट्स इन-फ़्लाइट होते हैं, अगले बैच को Rayon द्वारा एन्क्रिप्ट किया जा रहा होता है, और तीसरे बैच के रीड्स कर्नेल को सबमिट किए जा रहे होते हैं। कोई syscall-per-chunk ओवरहेड नहीं, कोई mmap सीमाएँ नहीं (कोई SIGBUS नहीं, कोई वर्चुअल एड्रेस स्पेस खत्म नहीं)
• Argon2id कुंजी व्युत्पत्ति: उद्योग-मानक पासवर्ड-टू-की स्ट्रेचिंग (डिफ़ॉल्ट 256 MiB मेमोरी, 3 पुनरावृत्तियाँ, --memory के माध्यम से कॉन्फ़िगरेबल)
• स्व-वर्णन KDF पैरामीटर: मेमोरी लागत, पुनरावृत्तियाँ और समानता एन्क्रिप्टेड फ़ाइल हैडर में संग्रहीत होते हैं ताकि डिक्रिप्शन उन्हीं पैरामीटर्स का उपयोग करे जो एन्क्रिप्शन समय पर चुने गए थे। लीगेसी फ़ाइलें (सभी-शून्य सेंटिनल) को पुराने 64 MiB डिफ़ॉल्ट के साथ पारदर्शी रूप से संभाला जाता है
• चंक-इंडेक्स्ड नॉन्स: TLS 1.3-शैली XOR नॉन्स व्युत्पत्ति चंक रीऑर्डर हमलों को रोकती है
• हैडर-प्रमाणित AAD: पूर्ण 4 KiB संरेखित हैडर प्रत्येक चंक के AAD में शामिल होता है, सभी हैडर फ़ील्ड्स (कोर, KDF पैरामीटर और आरक्षित बाइट्स) को प्रमाणित करता है और ट्रंकेशन, हैडर-फ़ील्ड हेरफेर और आरक्षित-बाइट तस्करी हमलों को रोकता है
• STREAM-शैली अंतिम चंक: AAD में एक अंतिम-चंक फ़्लैग ट्रंकेशन और अपेंड हमलों को रोकता है (STREAM निर्माण से प्रेरित)
• प्रति फ़ाइल ताज़ा यादृच्छिकता: प्रत्येक एन्क्रिप्शन के लिए क्रिप्टोग्राफिक रूप से यादृच्छिक 16-बाइट सॉल्ट और 12-बाइट बेस नॉन्स उत्पन्न होता है, हैडर में संग्रहीत
• इन-प्लेस एन्क्रिप्शन: ring के माध्यम से seal_in_place_separate_tag / open_in_place हॉट लूप में आवंटन को कम करता है
• पासवर्ड ज़ीरोइज़ेशन: कुंजियाँ और पासवर्ड उपयोग के बाद मेमोरी से सुरक्षित रूप से मिटा दिए जाते हैं
• O_DIRECT + सेक्टर-संरेखित प्रारूप: 4 KiB-संरेखित हैडर और चंक स्लॉट O_DIRECT I/O को सक्षम करते हैं, NVMe पर DMA-स्पीड रीड/राइट के लिए कर्नेल पेज कैश को बायपास करते हैं। बफर पूल 4096-बाइट संरेखण के साथ std::alloc का उपयोग करते हैं
• निर्देशिका एन्क्रिप्शन: पूरी निर्देशिकाओं को एक एकल एन्क्रिप्टेड आर्काइव के रूप में एन्क्रिप्ट करें। Tar-आधारित पैकिंग फ़ाइल नाम, अनुमतियाँ, टाइमस्टैम्प और निर्देशिका संरचना को सिफरटेक्स्ट के अंदर संरक्षित करती है। निष्कर्षण पथ ट्रैवर्सल और सिमलिंक एस्केप हमलों के खिलाफ मान्य करता है
• स्व-वर्णन फ़ाइल प्रारूप: हैडर सिफर, चंक आकार, मूल फ़ाइल आकार, सॉल्ट, बेस नॉन्स और Argon2id KDF पैरामीटर संग्रहीत करता है

प्रदर्शन

cargo bench (Criterion, 10 नमूने प्रति माप) के साथ बेंचमार्क किया गया। कुंजी व्युत्पत्ति शामिल नहीं है - संख्याएँ केवल शुद्ध क्रिप्टो थ्रूपुट दर्शाती हैं।

हार्डवेयर:

• CPU: AMD Ryzen 5 5600X (6c/12t @ 3.7 GHz बेस)
• RAM: 2x 8 GiB DDR4-2666 (डुअल चैनल, कुल 16 GiB)
• OS: Linux

I/O पर नोट: Criterion अस्थायी फ़ाइलें /tmp में लिखता है, जो इस सिस्टम पर tmpfs (RAM-समर्थित) है। O_DIRECT के साथ, कर्नेल tmpfs पर वास्तविक अतुल्यकालिक DMA का उपयोग नहीं कर सकता, इसलिए ये संख्याएँ सिफर थ्रूपुट + io_uring ओवरहेड को DMA बायपास लाभ के बिना दर्शाती हैं। एक वास्तविक Gen4 NVMe ड्राइव पर, O_DIRECT पेज-कैश डबल-बफ़रिंग को समाप्त करता है और DMA को सीधे संरेखित बफर पूल में सक्षम करता है, जिससे काफी अधिक थ्रूपुट मिलना चाहिए।

चंक आकार स्वीप (AES-256-GCM, 64 MiB फ़ाइल):

प्रदर्शन विशेषताएँ

यह इंजन सिफर संचालन के लिए ring (असेंबली-ऑप्टिमाइज्ड AES-NI / NEON / ARMv8-CE) और I/O के लिए ट्रिपल-बफर्ड io_uring पाइपलाइन का उपयोग करता है। तीन पूर्व-आवंटित बफर पूल पाइपलाइन के माध्यम से घूमते हैं: जबकि पूल A के राइट्स कर्नेल में पूरे हो रहे हैं, पूल B को Rayon द्वारा CPU पर एन्क्रिप्ट किया जा रहा है, और पूल C के रीड्स कर्नेल को सबमिट किए जा रहे हैं। यह I/O विलंबता को क्रिप्टो गणना के साथ ओवरलैप करता है।

क्यों AES-256-GCM छोटी फ़ाइलों पर ChaCha20-Poly1305 से तेज़ है: ring का AES-GCM बैकएंड x86-64 पर उपलब्ध AES-NI + CLMUL हार्डवेयर निर्देशों का शोषण करता है, जो इसे ChaCha20 (जो एक सॉफ्टवेयर सिफर है) पर हार्डवेयर लाभ देता है। बड़े आकारों पर दोनों सिफर ~1.0 GiB/s पर अभिसरित होते हैं, जो दर्शाता है कि बाधा सिफर थ्रूपुट से I/O सबमिशन ओवरहेड में स्थानांतरित हो जाती है।

क्यों पीक थ्रूपुट 1-16 MiB पर है, 256 MiB पर नहीं: छोटी फ़ाइलों (1-16 MiB) में कुछ चंक होते हैं, इसलिए Rayon समानांतरता कुशल है और कार्यशील सेट कैश में फिट होता है। 64-256 MiB पर, io_uring पाइपलाइन पूरी तरह से सक्रिय है (तीन बैच इन-फ़्लाइट), लेकिन प्रति-SQE सबमिशन और CQE पूर्णता ओवरहेड चंक गणना के साथ स्केल होता है। ट्रिपल-बफर डिज़ाइन सुनिश्चित करता है कि I/O और क्रिप्टो ओवरलैप हों, इस लागत को आंशिक रूप से छिपाते हुए।

क्यों ~1.0 GiB/s, न कि 10+ GiB/s: आधुनिक AES-NI प्रति कोर 2-4 GiB/s धक्का दे सकता है। 12 थ्रेड्स के साथ, कच्चा सिफर थ्रूपुट 10 GiB/s से अधिक हो सकता है। तीन कारक अंतर की व्याख्या करते हैं:

1. io_uring प्रति-SQE ओवरहेड: प्रत्येक चंक को एक रीड SQE और एक राइट SQE की आवश्यकता होती है। 256 MiB फ़ाइल के लिए 256 चंकों के साथ, यह 512 SQEs सबमिट और 512 CQEs प्राप्त होते हैं। जबकि io_uring pread/pwrite के प्रति-syscall कर्नेल संक्रमण लागत से बचाता है, फिर भी इसमें प्रति SQE रिंग-बफर और मेमोरी-बैरियर ओवरहेड होता है।
2. पाइपलाइन गहराई: PIPELINE_DEPTH=3 के साथ, किसी भी समय केवल तीन बैच पाइपलाइन के माध्यम से घूमते हैं। स्थिर-अवस्था ओवरलैप के लिए कम से कम तीन बैचों की आवश्यकता होती है; जो फ़ाइलें एक या दो बैचों में फिट होती हैं, उन्हें पाइपलाइनिंग से लाभ नहीं होता है।
3. कैश पदानुक्रम प्रभाव: 5600X में प्रति कोर 512 KiB L2 और 32 MiB साझा L3 है। डिफ़ॉल्ट 4 MiB चंक L2 से अधिक है, और लगभग 21 चंकों का एक बैच (84 MiB सक्रिय कार्यशील सेट) L3 से काफी अधिक है। छोटे चंक आकार (64-256 KiB) चंक स्वीप में बेहतर थ्रूपुट दिखाते हैं क्योंकि कार्यशील सेट का अधिक भाग कैश में रहता है।

बफर जीवनचक्र और सुरक्षा: बफर पूल को io_uring रिंग बनाने से पहले std::alloc::alloc_zeroed के साथ Layout::from_size_align(size, 4096) का उपयोग करके एक बार आवंटित किया जाता है, और पुनः आवंटन के बिना सभी पाइपलाइन पुनरावृत्तियों में पुन: उपयोग किया जाता है। प्रत्येक एन्क्रिप्टेड चंक को O_DIRECT राइट से पहले सेक्टर संरेखण के लिए शून्य-पैड किया जाता है। बफर पूल से पहले रिंग को स्पष्ट रूप से हटा दिया जाता है, यह सुनिश्चित करते हुए कि कर्नेल कभी मुक्त मेमोरी का संदर्भ न दे (कोई UAF नहीं)।

स्थापना

git clone https://github.com/frogsnot/concryptor.git
cd concryptor
cargo build --release

बाइनरी target/release/concryptor पर होगी।

उपयोग

एन्क्रिप्ट करें

# AES-256-GCM (डिफ़ॉल्ट), आउटपुट myfile.dat.enc
concryptor encrypt myfile.dat

# ChaCha20-Poly1305, कस्टम आउटपुट पथ
concryptor encrypt myfile.dat --cipher chacha -o encrypted.enc

# कस्टम चंक आकार (MiB में)
concryptor encrypt largefile.iso --chunk-size 8

# मजबूत KDF (512 MiB मेमोरी लागत)
concryptor encrypt secrets.tar --memory 512

# गैर-इंटरैक्टिव (पासवर्ड प्रॉम्प्ट छोड़ें)
concryptor encrypt myfile.dat -p "password"

सुरक्षा नोट: --password / -p पासवर्ड को CLI आर्गुमेंट के रूप में पास करता है, जो ps आउटपुट और शेल हिस्ट्री में दिखाई देता है। इंटरैक्टिव उपयोग के लिए, इसे छोड़ दें ताकि सुरक्षित छिपा हुआ प्रॉम्प्ट मिले। स्क्रिप्टिंग के लिए, बाद में हिस्ट्री साफ़ करना या किसी रैपर का उपयोग करना पसंद करें जो फ़ाइल डिस्क्रिप्टर से पढ़ता हो।

निर्देशिका एन्क्रिप्ट करें

# निर्देशिका एन्क्रिप्ट करें (स्वतः पहचानता है, mydir.tar.enc उत्पन्न करता है)
concryptor encrypt mydir/

# कस्टम सिफर और आउटपुट के साथ
concryptor encrypt mydir/ --cipher chacha -o secrets.enc

निर्देशिका एन्क्रिप्शन एक अस्थायी tar आर्काइव (.concryptor-*.tar, 0600 अनुमतियाँ, CSPRNG-नामित) बनाता है, इसे एन्क्रिप्ट करता है, फिर अस्थायी फ़ाइल को स्वतः हटा देता है। फ़ाइल नाम, निर्देशिका संरचना, अनुमतियाँ और टाइमस्टैम्प सभी एन्क्रिप्टेड पेलोड के अंदर होते हैं।

डिक्रिप्ट करें

# स्वतः .enc एक्सटेंशन हटाता है
concryptor decrypt myfile.dat.enc

# कस्टम आउटपुट पथ
concryptor decrypt encrypted.enc -o restored.dat

# गैर-इंटरैक्टिव
concryptor decrypt myfile.dat.enc -p "password"

निर्देशिका डिक्रिप्ट और निकालें

# एक चरण में डिक्रिप्ट और निकालें (स्वतः .tar.enc हटाता है -> निर्देशिका नाम)
concryptor decrypt mydir.tar.enc --extract

# छोटा फ़्लैग, कस्टम आउटपुट निर्देशिका
concryptor decrypt mydir.tar.enc -x -o restored_dir/

--extract के बिना, निर्देशिका आर्काइव को डिक्रिप्ट करने से मध्यवर्ती .tar फ़ाइल उत्पन्न होती है, जिसे आप निरीक्षण या मैन्युअल रूप से निकाल सकते हैं।

सहायता

concryptor --help
concryptor encrypt --help
concryptor decrypt --help

फ़ाइल प्रारूप

सभी मान लिटिल-एंडियन हैं। हैडर एक पूर्ण 4 KiB सेक्टर पर कब्जा करता है; प्रत्येक एन्क्रिप्टेड चंक स्लॉट अगली 4 KiB सीमा तक पैड किया जाता है। यह सुनिश्चित करता है कि O_DIRECT के लिए प्रत्येक ऑफ़सेट और I/O आकार सेक्टर-संरेखित हो।

ऑफ़सेट  आकार  फ़ील्ड
------  -----  ---------------------
0       10     मैजिक बाइट्स "CONCRYPTOR"
10       1     प्रारूप संस्करण (4)
11       1     सिफर प्रकार (0 = AES-256-GCM, 1 = ChaCha20-Poly1305)
12       4     चंक आकार (बाइट्स, LE)
16       8     मूल फ़ाइल आकार (बाइट्स, LE)
24      16     Argon2 सॉल्ट (क्रिप्टोग्राफिक रूप से यादृच्छिक, प्रति फ़ाइल अद्वितीय)
40      12     बेस नॉन्स (क्रिप्टोग्राफिक रूप से यादृच्छिक, प्रति फ़ाइल अद्वितीय)
52       4     Argon2 m_cost KiB में (LE, 0 = लीगेसी 64 MiB)
56       4     Argon2 t_cost / पुनरावृत्तियाँ (LE, 0 = लीगेसी 3)
60       4     Argon2 p_cost / समानता (LE, 0 = लीगेसी 4)
64    4032     आरक्षित (शून्य-पैड 4096 बाइट्स तक)
4096    ...    [चंक 0: सिफरटेक्स्ट + 16-बाइट टैग + सेक्टर सीमा तक शून्य पैडिंग]
               [चंक 1: सिफरटेक्स्ट + 16-बाइट टैग + सेक्टर सीमा तक शून्य पैडिंग]
               ...

4 MiB चंकों के लिए: प्रत्येक डिस्क स्लॉट ceil((4194304 + 16) / 4096) * 4096 = 4198400 बाइट्स (प्रति चंक 4080 बाइट्स पैडिंग) है। हैडर में 4032 आरक्षित बाइट्स भविष्य की सुविधाओं (असममित कुंजी स्लॉट, मेटाडेटा, आदि) के लिए उपलब्ध हैं।

सॉल्ट और बेस नॉन्स प्रत्येक एन्क्रिप्शन पर rand::rng() (OS CSPRNG द्वारा समर्थित) से ताज़ा उत्पन्न होते हैं। फ़ाइलों में पासवर्ड का पुन: उपयोग सुरक्षित है क्योंकि अलग-अलग सॉल्ट अलग-अलग Argon2id कुंजियाँ उत्पन्न करते हैं, और अलग-अलग बेस नॉन्स अलग-अलग प्रति-चंक नॉन्स उत्पन्न करते हैं।

सुरक्षा डिज़ाइन

• नॉन्स व्युत्पत्ति: chunk_nonce = base_nonce XOR chunk_index (TLS 1.3 शैली)। चंकों को स्वैप करने से डिक्रिप्शन विफलता होती है क्योंकि स्थिति N पर नॉन्स मूल रूप से स्थिति M पर चंक को एन्क्रिप्ट करने के लिए उपयोग किए गए नॉन्स से मेल नहीं खाएगा। नोट: XOR-आधारित नॉन्स व्युत्पत्ति में एक सैद्धांतिक कमजोरी है जब एक ही कुंजी का उपयोग कई स्ट्रीमों में किया जाता है (अलग-अलग बेस नॉन्स ओवरलैपिंग नॉन्स स्पेस उत्पन्न कर सकते हैं)। यह Concryptor पर लागू नहीं होता क्योंकि प्रत्येक एन्क्रिप्शन एक ताज़ा 128-बिट यादृच्छिक सॉल्ट उत्पन्न करता है, जो प्रति फ़ाइल एक अद्वितीय Argon2id कुंजी उत्पन्न करता है। नॉन्स अद्वितीयता केवल एक ही कुंजी के तहत मायने रखती है, और कुंजी पुन: उपयोग संभावना ~2^-128 प्रति फ़ाइल युग्म है।
• हैडर-प्रमाणित AAD: प्रत्येक चंक का AEAD कॉल AAD = full_aligned_header (4096) || chunk_index (8 LE) || is_final (1) (कुल 4105 बाइट्स) का उपयोग करता है। संपूर्ण 4 KiB हैडर सेक्टर (कोर फ़ील्ड्स, KDF पैरामीटर और आरक्षित पैडिंग) प्रत्येक चंक के प्रमाणीकरण टैग में बाध्य होता है। किसी भी हैडर बाइट (सिफर प्रकार, चंक आकार, मूल आकार, सॉल्ट, नॉन्स, KDF पैरामीटर या आरक्षित पैडिंग) को संशोधित करने से सभी चंक अमान्य हो जाते हैं। यह ट्रंकेशन हमलों को रोकता है जहाँ एक विरोधी original_size को संपादित करता है और अनुगामी चंकों को हटाता है, और आरक्षित पैडिंग क्षेत्र में डेटा की तस्करी को भी रोकता है। लीगेसी v3 फ़ाइलों को पिछड़ी संगतता के लिए 52-बाइट AAD के साथ डिक्रिप्ट किया जाता है; v4 से v3 में कोई डाउनग्रेड संभव नहीं है क्योंकि संस्करण बाइट स्वयं प्रमाणित AAD के अंदर है।
• STREAM-शैली अंतिम चंक संकेतक: AAD का अंतिम बाइट अंतिम चंक के लिए 0x01 और अन्य सभी के लिए 0x00 है। यह दो हमलों को रोकता है:
  • ट्रंकेशन: अंतिम चंक को हटाना और एक गैर-अंतिम चंक को अंत में बढ़ावा देना विफल होता है क्योंकि गैर-अंतिम चंक is_final = 0x00 के साथ एन्क्रिप्ट किया गया था लेकिन डिक्रिप्शन की अपेक्षा करता है।

परीक्षण

# पूर्ण परीक्षण सूट चलाएँ (67 परीक्षण)
cargo test

# बेंचमार्क चलाएँ (target/criterion/ में HTML रिपोर्ट)
cargo bench

# बेंचमार्क फ़िल्टर करें
cargo bench -- "encrypt/AES"
cargo bench -- "chunk_sweep"

परीक्षण सूट शामिल करता है:

• हैडर सीरियलाइज़ेशन/डिसीरियलाइज़ेशन राउंडट्रिप
• कुंजी व्युत्पत्ति निर्धारण और संवेदनशीलता
• नॉन्स अद्वितीयता और पहचान गुण
• दोनों सिफरों के लिए फ़ाइल आकारों (खाली, 1 बाइट, सीमा मामले, बहु-चंक) में एन्क्रिप्ट/डिक्रिप्ट राउंडट्रिप
• गलत पासवर्ड अस्वीकृति
• छेड़छाड़ का पता लगाना (उल्टा सिफरटेक्स्ट, दूषित टैग, दूषित सॉल्ट, छोटी फ़ाइलें)
• चंक रीऑर्डर हमले का पता लगाना
• सिफर प्रकार बेमेल का पता लगाना
• ट्रंकेशन हमले का पता लगाना (संशोधित original_size + हटाए गए चंक)
• हैडर फ़ील्ड हेरफेर का पता लगाना (संशोधित chunk_size)
• आरक्षित हैडर बाइट्स छेड़छाड़ का पता लगाना (संशोधित पैडिंग क्षेत्र)
• गैर-नियतात्मक एन्क्रिप्शन सत्यापन
• 256 छोटे चंकों के साथ तनाव परीक्षण
• निर्देशिका आर्काइव पैक/अनपैक राउंडट्रिप (दोनों सिफर)
• खाली निर्देशिका, गहरी नेस्टेड निर्देशिका, कई फ़ाइलें और बाइनरी सामग्री राउंडट्रिप
• वैध आंतरिक लिंक के लिए सिमलिंक संरक्षण
• निकासी रूट से बचने वाले सिमलिंक की अस्वीकृति (पूर्ण और सापेक्ष ट्रैवर्सल)
• ड्रॉप पर अस्थायी फ़ाइल स्वतः सफाई
• एन्क्रिप्टेड आर्काइव के लिए गलत पासवर्ड अस्वीकृति

निर्भरताएँ

स्थापित करें

# crates.io से (अनुशंसित)
cargo install concryptor

# स्रोत से
git clone https://github.com/FrogSnot/Concryptor
cd Concryptor
cargo build --release
# बाइनरी target/release/concryptor पर है

लाइसेंस

यह प्रोजेक्ट GNU Affero General Public License v3.0 के अंतर्गत लाइसेंस प्राप्त है।