XAES-256-GCM विस्तारित nonce AEAD

 (words.filippo.io)
1 पॉइंट द्वारा GN⁺ 2024-06-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें

XAES-256-GCM का परिचय

  • XAES-256-GCM एक authenticated encryption algorithm (AEAD) है जो 256-बिट key और 192-बिट nonce का उपयोग करता है
  • मुख्य लक्ष्य:
    • रैंडम तरीके से जनरेट किए गए nonce को सुरक्षित रूप से सपोर्ट करना
    • FIPS 140 अनुपालन
    • सामान्य encryption libraries में आसानी से implement किया जा सके

XAES-256-GCM के डिज़ाइन लक्ष्य

  • बड़े nonce का उपयोग करके असीमित messages के लिए सुरक्षित रूप से रैंडम जनरेशन संभव
  • FIPS 140 अनुपालन के ज़रिए विभिन्न environments में उपयोग संभव
  • सरल implementation के माध्यम से उपयोगकर्ता का बोझ कम करना

XAES-256-GCM कैसे काम करता है

  • AES-256-GCM पर आधारित विस्तारित nonce संरचना का उपयोग
  • input key और nonce का उपयोग करके derived key की गणना
  • message processing के लिए AES-256 को तीन बार कॉल किया जाता है

implementation और optimization

  • Go reference implementation 100 लाइनों से कम code में बनी है
  • केवल standard library के crypto/cipher और crypto/aes का उपयोग
  • NIST SP 800-108r1 KDF और NIST AES-256-GCM AEAD का उपयोग करके इसे समझाया जा सकता है

थर्ड-पार्टी implementation और compatibility

  • .NET 8+, pyca/cryptography, Web Cryptography API में थर्ड-पार्टी implementations मौजूद हैं
  • FIPS 140 अनुपालन के लिए rounds की संख्या बदली नहीं जा सकती

विकल्प और test vectors

  • AES-GCM-SIV जैसे विभिन्न विकल्प मौजूद हैं
  • प्रमुख code paths के लिए test vectors शामिल हैं

सारांश

  • XAES-256-GCM को सुरक्षित, compliant और interoperable AEAD के रूप में डिज़ाइन किया गया है
  • यह XChaCha20Poly1305 और AES-GCM-SIV को पूरक करने की भूमिका निभाता है
  • इसे Go standard library में जोड़े जाने की उम्मीद है

GN⁺ की राय

  • XAES-256-GCM में बड़े nonce का उपयोग करके सुरक्षा बढ़ाने का पहलू उल्लेखनीय है
  • FIPS 140 अनुपालन के कारण इसका उपयोग विभिन्न environments में किया जा सकता है
  • Go जैसी भाषाओं में इसे आसानी से implement किया जा सकता है, इसलिए यह developers के लिए उपयोगी है
  • AES-GCM-SIV जैसे विकल्पों पर भी विचार करना उचित है
  • नई तकनीक अपनाते समय performance और compatibility की सावधानी से समीक्षा करनी चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-30
Hacker News राय

  • डिज़ाइन बहुत चतुर है: यह CMAC-आधारित है, इसलिए जब lower-level primitive उपलब्ध न हों तब AES-CBC का उपयोग करके key derive की जा सकती है

    • इसे AES-CBC शब्दावली में समझाएँ तो: 
      1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
2. MSB₁(L) = 0 ho to, K1 = L << 1;
   anyatha K1 = (L << 1) ⊕ 0¹²⁰10000111
3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
6. Nₓ = N[12:]
    • AES-CBC-256 पहला 128-बिट ब्लॉक लौटाता है, और padded block को छोड़ दिया जाता है
    • key derive करने के बाद इसे standard AES-GCM के साथ इस्तेमाल किया जाता है
    • WebCrypto API पर आधारित JS implementation उदाहरण: GitHub लिंक
    • यह AES-CBC के लिए intended उपयुक्त CryptoKey को स्वीकार करता है, और IndexedDB में store किया जा सकता है

  • Filippo का काम शानदार है: यह random nonce इस्तेमाल करने पर लगभग हर 2^32 संदेशों के बाद key rotate करनी पड़ने वाली समस्या को हल करता है

    • AES-GCM में nonce collision घातक है (यह attacker को मनचाहे message पर sign करने में सक्षम बना देता है)
    • random nonce का उपयोग करना अनिवार्य नहीं है, लेकिन आम तौर पर इसकी सिफारिश की जाती है
    • इसे FIPS-compliant बनाने के लिए दो primitives (counter-based KDF और सामान्य GCM) का उपयोग करना बहुत चतुराई भरा है

  • काश यह फ़ीचर कुछ साल पहले मौजूद होता जब मैं encrypted file system लिख रहा था

    • बड़े पैमाने पर file system deployment में nonce collision एक बड़ी समस्या है
    • 2^32 बड़ा लग सकता है, लेकिन प्रति सेकंड 100k IOPS लिखने वाले PB array में अगर आप PRNG randomness पर निर्भर हैं तो collision की संभावना लगभग तय है

  • उम्मीद है कि archive file encryption के लिए FIPS-compliant age[1] variant में इसका उपयोग होगा

    • banking industry auditors ने ChaCha की जगह AES का उपयोग न करने के कारण age का विरोध किया था (X25519 public key हिस्सा हाल ही में NIST द्वारा approved हुआ है)
    • मुझे golang का अनुभव नहीं है, लेकिन age spec के अनुसार इसे आसानी से लागू किया जा सकता है
    • अगर समय मिला तो मैं इसे आज़माऊँगा
    • मैं इसे "cage" कहूँगा ("compliant actually good encryption" का संक्षेप)

  • एक non-cryptographer का सवाल: 192-बिट nonce क्यों उपयोग किया गया है, 256-बिट क्यों नहीं?

    • practical application में extra bits की लागत ज़्यादा नहीं लगती

  • (2⁸⁰ संदेशों पर collision risk 2⁻³²)

    • चूँकि AES block size 128 बिट है, क्या उससे पहले कोई समस्या आ सकती है यह जानने की जिज्ञासा है