- Fully Homomorphic Encryption (FHE) एक ऐसी तकनीक है जो डेटा को decrypt किए बिना ciphertext की स्थिति में ही उस पर computation करने देती है
- फिलहाल FHE में अब भी कम व्यावहारिकता, computation speed में 1,000x~10,000x की गिरावट, और storage space में 40x~1,000x की वृद्धि जैसी सीमाएँ हैं
- लेकिन हाल के वर्षों में FHE algorithms की speed हर साल 8x बेहतर हो रही है, और जल्द ही cloud computing, LLM inference, blockchain smart contracts जैसे क्षेत्रों में यह व्यावहारिक स्तर पर पहुँच सकता है
- अगर FHE व्यापक हो जाता है, तो यह ऐसे औद्योगिक बदलाव को बढ़ावा देगा जहाँ पूरे computing environment में data privacy default बन जाएगी
- इसमें lattice-based cryptography, LWE, bootstrapping जैसे मुख्य concepts, FHE algorithms के विकास का इतिहास, वास्तविक implementation examples, और performance improvement trends को समग्र रूप से समझाया गया है
परिचय: Fully Homomorphic Encryption क्या है
- Fully Homomorphic Encryption (FHE) एक ऐसी विधि है जो decryption के बिना ciphertext की स्थिति में arbitrary computation संभव बनाती है, यानी encrypted data पर सीधे computation किया जा सकता है
- यानी server plaintext जाने बिना भी query और result को compute करके वापस भेज सकता है
- यह तकनीक आज कई real-world systems में वास्तव में अपनाई जा रही है
FHE की क्षमता और सीमाएँ: "FHE का Moore's Law"
- FHE नेटवर्क पर data को लगातार encrypted अवस्था में बनाए रख सकता है, इसलिए data leak के जोखिम को मूल रूप से रोकते हुए पूर्ण privacy हासिल की जा सकती है
- इसके बावजूद आज इसकी practical adoption सीमित है, क्योंकि ciphertext computation, plaintext computation की तुलना में 1,000~10,000 गुना धीमा है, और storage भी लगभग 40~1,000 गुना बढ़ जाता है
- यह स्थिति 1990 के दशक के शुरुआती इंटरनेट जैसी है
- लेकिन हाल में FHE हर साल 8x तेज हो रहा है, इसलिए उम्मीद है कि यह जल्द कई practical domains में प्रवेश करेगा
निर्णायक मोड़: FHE का व्यावहारिक उपयोग अब दूर नहीं
- अगर इसी तरह speed में यह बड़ी प्रगति जारी रहती है, तो आगे चलकर FHE निम्न क्षेत्रों में practical हो सकता है
- encrypted cloud computing
- encrypted LLM inference
- confidentiality-सक्षम blockchain smart contracts
- यह बदलाव user data collection पर आधारित इंटरनेट business model को बुनियादी रूप से हिला सकता है
- FHE की वजह से "surveillance by default" वाले इंटरनेट से "privacy by default" वाले इंटरनेट की ओर मौलिक बदलाव की उम्मीद है
Data security की Achilles' heel और FHE का समाधान
- डेटा की 3 अवस्थाएँ होती हैं: at rest, in transit, और in use; इनमें 'in use' के दौरान decryption होने से सुरक्षा कमजोरी पैदा होती है
- cloud, insiders, hackers, या कमजोर CPU—कोई भी memory के भीतर मौजूद plaintext data तक पहुँच सकता है
- बड़े data breach incidents भी अधिकांशतः 'in use' या 'at rest' अवस्था में होते हैं
- FHE पूरे data lifecycle में data को encrypted रखकर इस कमजोरी को मूल रूप से दूर करता है
पूर्ण privacy computing की परिभाषा
- आदर्श वातावरण वह है जहाँ data storage, transmission, और usage (computation) — हर स्थिति में encrypted रहे
- उदाहरण के लिए, server plaintext query को बिल्कुल नहीं देखता, encrypted query लेता है और केवल encrypted result लौटाता है
- उस result को decrypt सिर्फ user ही कर सकता है
FHE कैसे काम करता है: गणितीय संरचना और concepts
- "homomorphic" का अर्थ ऐसी mathematical transformation से है जो समान संरचना को बनाए रखती है (उदाहरण: Fourier transform जैसी धारणा)
- FHE plaintext space और ciphertext space के बीच bidirectional transformation करता है, ताकि ciphertext पर computation का decrypted result, plaintext computation के result के बराबर हो
- इन transformations में मुख्य रूप से lattice-based cryptography और LWE (Learning With Errors) का उपयोग होता है
- lattice-based cryptography बहुत high-dimensional vector problems पर आधारित है, जिन्हें quantum computers के लिए भी हल करना कठिन माना जाता है (quantum resistance)
- LWE ऐसा problem है जिसमें noise मिले linear system को reverse करना होता है, जिसे व्यवहारिक रूप से तोड़ना संभव नहीं माना जाता
Noise management और bootstrapping
- FHE में computation बढ़ने के साथ ciphertext के भीतर noise भी बढ़ता है
- addition में यह linear तरीके से बढ़ता है, जबकि multiplication में geometric तरीके से, और अंततः decryption असंभव हो सकता है
- इसे हल करने की मुख्य तकनीक bootstrapping है, जिसमें ciphertext को 'नई public key' के साथ re-encrypt करके noise को एक निश्चित स्तर तक reset किया जाता है
- यह प्रक्रिया FHE systems में performance bottleneck है, लेकिन हर साल इसमें तेज सुधार हो रहा है
FHE के अन्य मुख्य घटक
- relinearization: multiplication के बाद key degree के quadratic हो जाने की समस्या को हल करके उसे फिर linear बनाना
- modulus switching: noise management के लिए ciphertext modulus को घटाने की तकनीक
इसके अलावा algorithmic advances के साथ लगातार कई नई techniques भी सामने आ रही हैं
Homomorphic Encryption (HE) schemes का वर्गीकरण और Python उदाहरण
- Partial HE: केवल एक operation support करता है (जैसे Paillier encryption केवल addition support करता है)
- Somewhat HE: addition और multiplication दोनों support करता है, लेकिन multiplication की पुनरावृत्ति सीमित होती है
- FHE: addition और multiplication दोनों को बिना सीमा support करता है; Turing completeness सुनिश्चित होती है
Python में implemented Paillier encryption के उदाहरण के जरिए partial homomorphism को सहज रूप से समझा जा सकता है
FHE का विकास इतिहास और "FHE का Moore's Law"
- 1978: पहली बार "privacy homomorphism" का concept सामने आया
- 2009: Craig Gentry ने पहली बार FHE को वास्तविक रूप दिया (PhD thesis)
- 2011: पहला implementation, प्रति bit 30 मिनट लगते थे (बहुत धीमा)
- 2013 के बाद: bootstrapping time घटकर कुछ ms के स्तर तक आया
- 2017: CKKS जैसे schemes ने floating-point approximation support करना शुरू किया, और ML/AI में गंभीर उपयोग शुरू हुआ
FHE algorithms 2011 से हर साल 8x बेहतर हुए हैं, जिससे शुरुआती 10¹⁰x overhead घटकर हाल में 10³~10⁴x स्तर तक आ गया है
नवीनतम papers ने FHE multiplication throughput को 1,000x और latency को 10x तक घटाया है, और hardware acceleration जोड़ने पर 1,000x से अधिक अतिरिक्त speedup की संभावना है
एक ऐसा भविष्य जहाँ encryption default होगा
- बड़े data breaches अब टाली न जा सकने वाली वास्तविकता बन चुके हैं
- यदि FHE की मदद से server decryption key के बिना भी encrypted data पर केवल computation कर सके, तो यह privacy protection का नया मानक बन सकता है
- अभी यह हर क्षेत्र में पूरी तरह practical नहीं है, लेकिन हर साल आश्चर्यजनक गति से बेहतर हो रहा है
- users की privacy demands और कड़े regulations के साथ मिलकर, अंततः FHE अधिकांश cloud computing के लिए standard बन सकता है
- भविष्य की इंटरनेट computing हमेशा encrypted state में विकसित होगी
2010s: HTTPS default था
आगे: FHE default होगा — ऐसा युग आने की संभावना है
संदर्भ और अतिरिक्त सामग्री
- FHE Reference Library: academic materials का व्यापक संकलन
- Craig Gentry 2009 PhD thesis: FHE की शुरुआत
- Vitalik Buterin: FHE deep dive
- समुदाय: FHE.org (developer-centric hub)
- GitHub: awesome-he: homomorphic encryption से जुड़े projects का संग्रह
1 टिप्पणियां
Hacker News की राय
मैं यह मानकर बात कर रहा हूँ कि मुझे FHE और Cryptography बहुत पसंद हैं। FHE लगातार तेज़ हो रहा है, लेकिन जब तक यह bootstrapping पर निर्भर है, तब तक plain text पर होने वाली computation की गति को नहीं पकड़ सकता। Bootstrapping से आने वाला लगभग 1000x या उससे अधिक overhead मूल रूप से टाला नहीं जा सकता, और जब यह समझ में आने लगा कि इसे और तेज़ बनाना संभव नहीं है, तब hardware acceleration की बात शुरू हुई। लेकिन आज के समय में, जब LLM लगभग सारी computing power खा रहे हैं, यह आसान नहीं है। अगर सोचें कि FHE पर computing करते समय प्रति token लागत कितनी गुना बढ़ेगी, तो 1000x से कम कुछ भी हो तो भी व्यावहारिक संभावना लगभग नहीं दिखती। अगर लक्ष्य privacy protection है, तो अभी के लिए confidential computing ही एकमात्र practical alternative है। Hardware पर भरोसा करना अच्छा नहीं लगता, लेकिन फिलहाल हमारे पास यही सबसे अच्छा विकल्प है
FHE को arbitrary computation में इस्तेमाल करना मुश्किल होने का एक और भी बुनियादी कारण है। कुछ तरह की computations ciphertext पर plain text की तुलना में असामान्य रूप से ज़्यादा complex हो जाती हैं। उदाहरण के लिए database search: plain text में यह O(log n) हो सकती है, लेकिन encrypted key से search करने पर O(n) बन जाती है। इसलिए fully homomorphic Google search मूल रूप से असंभव है। हालांकि fully homomorphic DNN inference का मामला अलग हो सकता है
Bootstrapping के बिना भी FHE plain text computation जितना तेज़ नहीं हो सकता। Ciphertext plain text से लगभग 1000 गुना बड़ा होता है। यानी memory bandwidth और computation दोनों बहुत अधिक चाहिए। इस अंतर को बंद नहीं किया जा सकता
मैं सोचता हूँ कि क्या 1000x computation cost होने पर भी ऐसा कोई खास demand segment नहीं होगा जो verifiable privacy सच में चाहता हो। यह शायद Dropbox जितना बड़ा न हो, लेकिन कुछ बाज़ार तो हो सकता है
मुझे वह समय याद आता है जब सब कुछ PCIE expansion cards के दौर में था। GPU भी ऐसा ही था, और math coprocessor जैसे special accelerator भी अलग होते थे। आज वे general-purpose hardware में integrate हो गए हैं, इसलिए सस्ते और सुविधाजनक हैं, लेकिन किसी खास function के लिए optimized silicon chip जितना अच्छा नहीं कर सकते। इसलिए मैं कहूँगा कि AI/ML के लिए dedicated cards, GPU-आधारित approach से अलग होने चाहिए। Architecture कुछ हद तक overlap करता है, लेकिन GPU-आधारित AI card कई जगह compromise करता है। असली AI accelerator मेरे हिसाब से वह dedicated hardware है जो modern SXM socket में जाता है। लेकिन SXM socket सिर्फ server में होते हैं और सस्ते भी नहीं हैं
मैं LLM boom को मानता हूँ, लेकिन सोचता हूँ कि क्या FHE के और कोई उपयोग नहीं हैं। उदाहरण के लिए, high-speed की ज़रूरत न रखने वाले trading algorithm को FHE के साथ server पर host करके security guarantee देने का तरीका सोचा जा सकता है
FHE के महत्वपूर्ण होने की वजह यह है कि आज कंपनियों को कभी-कभी सरकार के दबाव में किसी खास target की encryption जबरन तोड़नी पड़ती है। FHE कंपनियों को साफ़ तौर पर यह कहने देता है कि "हम plain text कभी देख ही नहीं सकते।" Network carrier की भूमिका में E2E encryption वगैरह से यह कुछ हद तक संभव है, लेकिन plain text अवस्था में data processing के दौरान अभी यह संभव नहीं है। मेरा मानना है कि privacy एक बुनियादी मानव अधिकार है। सरकार की शक्ति लोकतांत्रिक गतिविधियों—जैसे voting, art, press, expression—पर बहुत सीमित रूप में ही लागू होनी चाहिए
भले ही FHE arbitrary computation संभव बना दे, ज़्यादातर services का मूल्य इस बात में है कि वे specific data उपलब्ध कराती हैं। अगर Google मेरी query के लिए security guarantee देना चाहे, तो उसे पूरा search index encrypt करना होगा, जो व्यावहारिक नहीं है। Business के नज़रिए से भी, बहुत कम high-trust, high-risk क्षेत्रों को छोड़कर FHE-आधारित service अपनाने का incentive लगभग नहीं है
मेरी जानकारी में सिर्फ sensitive data को encrypt करना काफी है (जैसे मेरी bank transaction data)। जिस function की computation करनी है, उसे encrypt करने की ज़रूरत नहीं; उसे public data के साथ मिलाकर इस्तेमाल किया जा सकता है
आखिरकार बड़ी कंपनियों के लिए revenue का स्रोत अक्सर users के data या queries को देख पाना ही होता है, इसलिए उनके पास FHE को आदतन अपनाने की कोई खास प्रेरणा नहीं है। Banking और finance में यह अच्छा लग सकता है, लेकिन उसके बाहर यह कब अपनाया जाएगा, कहना मुश्किल है
Incentive वाली बात सही है। लेकिन पहला हिस्सा अलग है। Plain text database पर private lookup कई सालों से संभव है। बस इसके लिए plain text DB को पहले काफ़ी जटिल तरीके से preprocess करना पड़ता है, या worst case में पूरे DB को linear scan करना पड़ता है
पूरी तरह private search engine के FHE implementation के उदाहरण के रूप में spiralwiki.com का परिचय दिया गया। इसमें server को बिल्कुल पता नहीं चलता कि user कौन-सा Wikipedia article पढ़ रहा है spiralwiki.com
"Client के नज़रिए" से देखें तो FHE जैसी पूरी तरह data-protecting service के लिए कुछ लोग पैसे देना चाहेंगे, लेकिन असलियत में यह बेहद महँगी होगी और subscribers बहुत कम होंगे। अगर मान लें कि आज की तुलना में computation cost कई दर्जन गुना बढ़ जाती है, तो भी privacy-focused Google alternative को सालाना $100 पर offer करने से बहुत ज़्यादा users नहीं आएँगे। लागत जितनी बढ़ेगी, subscribers उतने घटेंगे। Tor जैसे विकल्प मौजूद हैं जो perfect न सही, लेकिन काफ़ी protection मुफ्त में दे देते हैं। HE का मतलब यह नहीं कि उसका कोई उपयोग नहीं है; बात सिर्फ इतनी है कि बहुत कम लोग इसकी लागत उठाएँगे
यह बात उठी कि internet "default surveillance" से "default privacy" की ओर बदल सकता है। मैं भी लंबे समय से digital signatures जैसी privacy technologies को फैलाने की कोशिश करता रहा हूँ। लेकिन हमें यह भी देखना चाहिए कि Hacker News या Facebook जैसी सेवाएँ सबकी identity अपने हाथ में रखती हैं। क्योंकि यह बहुत आसान है और इससे पैसा बनता है। FHE भी शायद ऐसी ही technology है जिसे लोग चाहते तो हैं, लेकिन वह व्यावहारिक रूप से तेज़ी से और व्यापक रूप से इस्तेमाल नहीं होती। वजह है operational overhead और complexity का बोझ, जबकि अधिकतर मामलों में existing methods काफी अच्छा काम करती हैं
जब मैं email के अंत में digital signature जैसी चीज़ जोड़ता था, तो प्रतिक्रिया बस यही मिलती थी: "यह क्या है?" क्या किसी के पास ऐसा अनुभव है जिसमें उसने आम users को client-side encryption अपनाने के लिए राज़ी किया हो?
एक राय यह है कि जब FHE और AI मिलेंगे, तब complexity का कुछ बोझ AI उठा लेगा, और शायद यह सच में व्यापक उपयोग वाला killer combination बन सके
व्यावहारिक रूप से देखें तो कंपनियों के पास ऐसा solution अपनाने की कोई वजह नहीं होगी जो FHE service की तरह 10,00,000x ज़्यादा computation ले, debugging को कठिन बना दे, और usage pattern analysis भी न करने दे
Google का उदाहरण लेकर बात शुरू करना भ्रम पैदा कर सकता है। आम तौर पर "Google" सुनते ही लोग "web search" सोचते हैं, लेकिन दस्तावेज़ में जिस FHE की बात है, उसमें पूरे input को एक ही key से encrypt होना चाहिए, इसलिए search service के साथ उसका context मेल न भी खाए। Google का search index कई TB का होता है, और उसे किसी एक खास key से पूरा encrypt करना संभव नहीं लगता। यानी FHE तभी उपयोगी है जब user पूरे input को नियंत्रित करता हो। Google reference भ्रमित करता है
Apple CallerID जैसे मामलों में ऐसा नहीं लगता कि पूरे database को हर user के लिए encrypt करना ज़रूरी हो Apple का homomorphic encryption research / Apple का private search
Homomorphic encryption service को शुरू से encryption key जानने की ज़रूरत नहीं होती। यही इसकी खास बात है। एक बहुत सरल encryption उदाहरण में बताया गया कि key तय किए बिना भी ciphertexts के बीच addition का result निकाला जा सकता है। अगर अधिक मज़बूत encryption के साथ अधिक complex operations भी supported हों, तो बहुत तरह की functionality बनाई जा सकती है
Google से सिर्फ search ही याद नहीं आता; Gmail, Google docs जैसी privacy-संबंधित services भी हैं। जो लोग सिर्फ search सोचते हैं, शायद उन्होंने संबंधित लेख पढ़ा ही नहीं होगा
मुझे नहीं लगता कि FHE को जल्द ही general-purpose computing या internet services में सीधे लागू किया जा सकेगा। कम से कम Moore's law की कई और पीढ़ियाँ गुजरनी होंगी। लेकिन ऐसे क्षेत्र जहाँ complexity अपेक्षाकृत कम है, जबकि security और trust की ज़रूरत बहुत अधिक है—जैसे smart contracts, finance, healthcare—वहाँ FHE पहले से असर दिखाना शुरू कर सकता है। हाल की Moore's law प्रगति और software optimization की वजह से यह curve practical उपयोगिता की दिशा में मुड़ना शुरू हुआ है। उदाहरण के तौर पर Zama का hardware/Devtools काम का ज़िक्र किया गया
E2EE git पहले ही विकसित किया जा चुका है। मैंने उसके निर्माता से पूछा था कि क्या server-side protected branches या force push रोकने जैसी ज़रूरतों को हल किया जा सकता है, लेकिन अगर client ही malicious हो तो कोई स्पष्ट समाधान नहीं था। सोचता हूँ कि क्या यह कभी E2EE Github में विकसित हो सकता है संबंधित Hacker News लिंक
FHE की speed improvement आगे भी जारी रहेगी, ऐसी बातें सुनकर मुझे average speed से जुड़ी एक पुरानी गणितीय समस्या याद आती है। उदाहरण के लिए, अगर आप 1 mile की चढ़ाई 15 mph की रफ्तार से चलें, तो अगली 1 mile की ढलान कितनी तेज़ चलनी होगी ताकि पूरे 2 mile की average speed 30 mph हो जाए? अतीत में हुई प्रगति भविष्य की संभावना की गारंटी नहीं देती। यह physical limitation नहीं, algorithmic limitation है
अगर ढलान सीधी खाई हो तो? अगर कार की terminal velocity 200-300 mph मानें, तो हिसाब से 1 mile free-fall को 15 second में पार करना संभव लग सकता है। पूरे 2 mile पर 30 mph की average के लिए 4 minute लगते हैं, इसलिए बचे समय के अनुसार चढ़ाई की रफ्तार भी समायोजित की जा सकती है, लेकिन व्यवहार में कई variables के कारण यह संभव नहीं होगा
सख्ती से गणना करें तो ढलान पर 41 mph से चलने पर कुल average 30 mph बनती है। यानी मानना पड़ेगा कि सवाल में number rounding या measurement error शामिल था, तभी ऐसा परिणाम निकलता है