Libsodium में भेद्यता

• libsodium के low-level फ़ंक्शन crypto_core_ed25519_is_valid_point() में Edwards25519 curve पर point validation की त्रुटि पाई गई
• इस फ़ंक्शन को यह जांचना चाहिए कि point मुख्य cryptographic group का हिस्सा है या नहीं, लेकिन इसने mixed order (subgroup) के कुछ points को गलत तरीके से पास कर दिया
• वजह internal coordinate validation में code bug थी, जहाँ सिर्फ X=0 की जांच की गई और Y=Z validation छूट गई, जिससे गलत points को valid माना जा सकता था
• patched version में दोनों शर्तें (X=0, Y=Z) जांची जाती हैं, और 1.0.20 या उससे नीचे के versions या 30 दिसंबर 2025 से पहले की releases प्रभावित हैं
• high-level API (crypto_sign_*) प्रभावित नहीं है, और सुरक्षा व performance के लिए Ristretto255 group का उपयोग recommended है

---

libsodium प्रोजेक्ट का अवलोकन

• libsodium 13 साल पहले शुरू हुआ प्रोजेक्ट है, जिसका उद्देश्य cryptography को आसानी से उपयोग करने के लिए simple API देना है
  • इसे इस तरह डिज़ाइन किया गया कि users को internal algorithms जाने बिना high-level operations करने की सुविधा मिले
• API की compatibility बनाए रखने पर ज़ोर दिया गया है, और NaCl API के आधार पर अब तक consistency रखी गई है
• कुछ users ने documentation में बताए गए limits से आगे बढ़कर low-level functions का सीधे उपयोग किया, जिससे library का उपयोग cryptography toolkit की तरह बढ़ा है

मिले bug का कारण

• समस्या वाला फ़ंक्शन: crypto_core_ed25519_is_valid_point()
  • इसे Edwards25519 curve पर मुख्य group (order L) में शामिल न होने वाले points को reject करना चाहिए
  • लेकिन mixed order (2L, 4L, 8L आदि) के कुछ points validation पार कर गए
• internal रूप से point का order जांचने के लिए L से गुणा किया जाता है, फिर यह देखा जाता है कि result identity है या नहीं
  • identity को X=0, Y=Z के रूप में दर्शाया जाता है, लेकिन पुराने code में सिर्फ X=0 की जांच थी
  • इसी वजह से Y≠Z वाले गलत points को भी valid माना गया
• उदाहरण: मुख्य group के point Q में order 2 वाला point (0, -1) जोड़ने पर बना Q+(0, -1) गलत point है, लेकिन fix से पहले यह पास हो जाता था

क्या बदला गया

• patch commit में यह बदलाव किया गया
  • पुराना code: return fe25519_iszero(pl.X);
  • नया code: fe25519_sub(t, pl.Y, pl.Z); return fe25519_iszero(pl.X) & fe25519_iszero(t);
• अब X=0 और Y=Z दोनों conditions की जांच करके सही validation किया जाता है

प्रभाव का दायरा

• निम्न शर्तों में प्रभाव संभव है
  • 1.0.20 या उससे नीचे का version, या 30 दिसंबर 2025 से पहले की release उपयोग में हो
  • crypto_core_ed25519_is_valid_point() से untrusted input points validate किए जा रहे हों
  • user Edwards25519 curve operations को सीधे implement कर रहा हो
• लेकिन अधिकांश users प्रभावित नहीं हैं
  • high-level API (crypto_sign_*) इस फ़ंक्शन का उपयोग नहीं करती
  • crypto_scalarmult_ed25519 में गलत public key होने पर भी information leak नहीं होता
  • crypto_sign_keypair और crypto_sign_seed_keypair से बनी keys सही group में होती हैं

सुझाए गए कदम

• Ristretto255 group का उपयोग recommended है
  • यह 2019 से libsodium में शामिल है और cofactor से जुड़ी समस्याओं को हल करता है
  • decoded points अपने-आप सुरक्षित होते हैं, इसलिए अतिरिक्त validation की ज़रूरत नहीं
  • Edwards25519 से तेज़ operation performance देता है
• यदि update संभव न हो, तो दिए गए application-level alternative function (is_on_main_subgroup) से validation किया जा सकता है

संशोधित वितरण और समर्थन

• समस्या मिलते ही तुरंत fix कर दिया गया, और 30 दिसंबर 2025 के बाद जारी सभी stable versions में यह शामिल है
  • official tarball, Visual Studio/MingW binaries, NuGet package, Android builds, swift-sodium xcframework, Rust libsodium-sys-stable, libsodium.js शामिल हैं
• नया point release भी निर्धारित है
• प्रोजेक्ट single maintainer द्वारा चलाया जाता है, और OpenCollective support के जरिए लगातार सुधार में मदद की जा सकती है

[GN⁺]

Hacker News की राय

• PHP लाइब्रेरी sodium_compat भी इस समस्या से प्रभावित हुई थी
  संबंधित जानकारी security-advisories PR #756 में देखी जा सकती है
  आज शाम मैं open source ecosystem में मौजूद अन्य Ed25519 implementations की भी जाँच करने वाला हूँ, ताकि यह पता चल सके कि कहीं वही validation छूट तो नहीं गई है

  • मैंने पाया कि कुछ लाइब्रेरीज़ में validation logic पूरी तरह गायब है
    लेकिन ऊपर बताई गई vulnerability की तरह गलत तरीके से implement किए गए मामले नहीं मिले
    अगर मैंने ईमेल नहीं भेजा है, तो संभवतः वह ianix की Ed25519 deployment list में नहीं है, या फिर मुझसे छूट गया है, या वह implementation सुरक्षित है
  • open source में योगदान देने के लिए धन्यवाद कहना चाहता हूँ

• मैं पिछले 4 महीनों से Lean4 के लिए sodium bindings विकसित कर रहा हूँ
  अब मैं Ristretto255 चरण तक पहुँच गया हूँ, और अब समझ पा रहा हूँ कि लेखक इस तकनीक को लेकर इतना उत्साहित क्यों है
  Ristretto, Curve25519 के ऊपर arbitrary polynomials बनाने के लिए एक परिष्कृत API है, और इस पर प्रयोग करना सच में बहुत मज़ेदार है
  अगर लेखक यह पोस्ट देख रहे हों, तो मैं उन्हें दिल से धन्यवाद कहना चाहूँगा

  • क्या इस प्रोजेक्ट का कोई public repository है?

• Libsodium का लक्ष्य low-level functions नहीं, बल्कि high-level API देना था
  इसे इस तरह डिज़ाइन किया गया था कि users को अंदरूनी algorithms जानने की ज़रूरत न पड़े, लेकिन समय के साथ लोग low-level functions सीधे इस्तेमाल करने लगे
  आखिरकार Libsodium का इस्तेमाल एक algorithm toolkit की तरह होने लगा
  महत्वपूर्ण बात यह है कि users जिस दिशा में जाना चाहते हैं, उसे समझा जाए और प्रोजेक्ट को सिर्फ एक ही तरीके से न थोपा जाए
  कुछ प्रोजेक्ट्स इसी तरह हठधर्मी होकर विफल हो जाते हैं

  • दिलचस्प बात है। लेकिन उल्टा भी हो सकता है कि जो users चाहते हैं ऐसा लगता है और जो उन्हें वास्तव में चाहिए, वे अलग हों
    non-experts के लिए cryptographic primitives को सीधे इस्तेमाल करना खतरनाक है
    Libsodium को इस तरह बनाया गया था कि users खुद को खतरे में न डालें
    आदर्श रूप से लाइब्रेरी ऐसी होनी चाहिए कि गलत इस्तेमाल करना संभव ही न हो
    इस विषय पर “If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong” पढ़ने की सलाह दूँगा
  • अगर हर internal function को API contract मान लिया जाए, तो लगभग हर बदलाव compatibility break बन जाएगा
    इसलिए कुछ features को private या internal तक सीमित रखना कई बार सही विकल्प होता है
    Libsodium ने वह सीमा ठीक से तय की या नहीं, यह मैं नहीं कह सकता, लेकिन संतुलन महत्वपूर्ण है
  • मैंने पहले CeeFIT नाम का एक C++ test framework बनाया था, और compile time पर fixture register करने के तरीके पर मुझे काफ़ी गर्व था
    लेकिन कुछ users ने उसे batch runner की तरह इस्तेमाल किया
    उनकी ज़रूरतों को support करने के लिए मैंने कुछ bugs ठीक किए
    अंत में मुझे बस इस बात की खुशी थी कि उसे इस्तेमाल करने वाले लोग मौजूद थे

• यह bug सूक्ष्म है, लेकिन एक महत्वपूर्ण cryptographic validation error है
  “valid है या नहीं” जैसी साधारण जाँच वास्तव में बहुत जटिल होती है
  अगर prime-order subgroup के बाहर के points को अनुमति दे दी जाए, तो भले तुरंत vulnerability न दिखे, यह ऊपर की layers की assumptions को तोड़ सकता है
  साथ ही low-level primitives अक्सर इरादे से कहीं ज़्यादा व्यापक रूप से reuse हो जाते हैं, इसलिए validation में छोटी सी कमी भी बड़ा प्रभाव डाल सकती है

  • लेकिन X25519 और Ed25519 को शुरू से ही इस तरह डिज़ाइन किया गया था कि ऐसी validation की ज़रूरत न पड़े
    subgroup की समस्या तभी आती है जब Curve25519 पर और जटिल protocols बनाए जाते हैं
    इसलिए मैं जहाँ तक संभव हो, सभी points को फिर से prime-order subgroup में map कर देता हूँ
    Monocypher में ऐसे advanced functions मौजूद हैं
    उदाहरण के लिए crypto_x25519_dirty_fast() या crypto_elligator_map() जैसे functions
    ये “dirty” functions ऐसे public keys बनाते हैं जो पूरी curve को cover करते हैं, ताकि वे randomness से अलग न पहचाने जा सकें
    इसके बाद X25519 key exchange के दौरान भी वही shared secret प्राप्त किया जा सकता है
    यह DJB के डिज़ाइन की वजह से संभव है, क्योंकि public key असामान्य हो तब भी shared secret prime-order subgroup में map हो जाता है
    अंततः Ristretto की ज़रूरत केवल तब पड़ती है जब ऐसा remapping संभव न हो
    बेशक prime-order group abstraction उपयोगी है, लेकिन अगर कोई ऐसे protocols डिज़ाइन कर सकता है, तो उसे non-trivial cofactor संभालना भी आना चाहिए

• अगर आप किसी बड़ी कंपनी में काम करते हैं, तो Frank को कंपनी स्तर पर sponsor करने पर विचार करना चाहिए

  • मैं Apple में काम करता हूँ, लेकिन मुझे नहीं पता Frank कौन हैं, और sponsorship की प्रक्रिया क्या है
    और अगर पता भी हो, तो शायद मुझे कंपनी के खाते से नहीं बल्कि अपने निजी पैसे से support करना होगा

• क्या libnacl भी प्रभावित है?
  मैं रोज़ libnacl से compiled software इस्तेमाल करता हूँ, लेकिन “libsodium” से compiled कुछ भी नहीं

• यह सचमुच एक शानदार लाइब्रेरी है
  Frank Denis के प्रति आभार व्यक्त करता हूँ