DuckDB में stored data encryption फीचर

• DuckDB 1.4 version से stored data encryption (Data-at-Rest Encryption) फीचर जोड़ा गया है, जिससे पूरे database file को AES-आधारित standard encryption से सुरक्षित किया जा सकता है
• supported algorithms हैं AES-GCM-256 और AES-CTR-256; इनमें GCM में data integrity verification के लिए authentication tag शामिल होता है
• encryption database file, WAL(Write-Ahead Log), temporary files—तीनों पर लागू होती है, और key management व memory protection के लिए secure cache structure भी शामिल है
• OpenSSL और Mbed TLS की दो implementations दी गई हैं, और OpenSSL उपयोग करने पर hardware acceleration की वजह से performance impact लगभग नहीं के बराबर है
• encrypted DuckDB files security और portability दोनों सुनिश्चित करती हैं, और cloud या CDN environment में भी data को सुरक्षित रूप से distribute किया जा सकता है

---

एन्क्रिप्शन का अवलोकन

• DuckDB 1.4 से पूरे database file को transparent encryption के साथ एन्क्रिप्ट किया जा सकता है
  • store करते समय AES-GCM-256 या AES-CTR-256 encryption का उपयोग होता है
  • AES-GCM integrity verification के लिए tag calculate करता है, जबकि AES-CTR तेज़ है लेकिन उसमें authentication फीचर नहीं है
• AES एक symmetric-key encryption algorithm है, जिसमें एक ही key से encryption और decryption दोनों किए जाते हैं
• IV(Initialization Vector) और nonce का उपयोग करके यह सुनिश्चित किया जाता है कि वही plaintext अलग ciphertext में बदले
• NIST standard requirements अभी पूरी तरह satisfy नहीं होतीं

DuckDB की internal implementation संरचना

• database file का main header plaintext में रहता है, और उसमें encryption status दिखाने वाला flag तथा encryption metadata stored रहता है
  • metadata में database identifier(salt), encryption algorithm information, और encrypted canary शामिल होते हैं
• key derivation function (KDF) के जरिए user input key को 32-byte secure key में बदला जाता है
  • derived key को secure cache में stored रखा जाता है ताकि वह disk पर swap न हो
  • original key को memory से तुरंत delete कर दिया जाता है
• data blocks default रूप से 256KB units में stored होते हैं, और encryption के समय block header में nonce/IV और tag जुड़ते हैं, जिससे वह 40 bytes तक expand होता है
  • checksum encrypted form में stored होता है

WAL(Write-Ahead Log) encryption

• WAL transaction recovery के लिए log file है, और DuckDB में यह entry-level encryption के साथ सुरक्षित किया जाता है
  • हर entry में nonce और tag जोड़कर AES-GCM तरीके से protection दी जाती है
  • encrypted WAL entry का क्रम होता है: length(plaintext) → nonce → encrypted checksum एवं data → tag
• जिन databases में encryption key specify की गई हो, उनमें WAL encryption अपने-आप enable हो जाती है

temporary file encryption

• sorting, join, window functions जैसी large-scale operations के दौरान बनने वाली temporary files भी अपने-आप encrypt होती हैं
  • encrypted database attach करने पर या SET temp_file_encryption = true setting के साथ यह enable होती है
  • DuckDB internally temporary key generate करता है, और टकराव होने पर decryption संभव नहीं होता
• temporary files में .tmp या .block extension होता है, और size information header में शामिल रहती है
  • checksum को computation cost कम रखने के लिए छोड़ा गया है

encryption उपयोग करने का तरीका

• तीन तरीके supported हैं:
  1. existing database को encrypt करना
  2. नया encrypted database बनाना
  3. existing encrypted database को re-encrypt करना
• example command:

  ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
  COPY FROM DATABASE unencrypted TO encrypted;
  

• encryption enabled है या नहीं, यह FROM duckdb_databases(); command से check किया जा सकता है
• default encryption algorithm AES-GCM है, और ज़रूरत पड़ने पर AES-CTR specify किया जा सकता है
• encrypted data में entropy अधिक होती है, इसलिए वह random data जैसा दिखता है

implementation और performance

• external dependencies को कम रखने के लिए DuckDB में Mbed TLS और OpenSSL की दो encryption implementations शामिल हैं
  • Mbed TLS में hardware acceleration disabled होने से performance कम है, और random number generator vulnerability मिलने के कारण write functionality disabled (1.4.1 के बाद) है
  • OpenSSL hardware acceleration और secure random number generator का उपयोग करता है, और httpfs extension load होने पर अपने-आप switch हो जाता है
• performance test results:
  • बिना encryption का SUMMARIZE query: 5.4 सेकंड
  • Mbed TLS encryption: 6.2 सेकंड
  • OpenSSL encryption: 5.4 सेकंड (कोई performance degradation नहीं)
• TPC-H Power/Throughput test में भी encryption उपयोग करने पर performance difference बहुत मामूली रहा
  • Power@Size: 624,296 → 571,985
  • Throughput@Size: 450,409 → 145,353 (disk I/O बढ़ने पर थोड़ा कम)

निष्कर्ष

• DuckDB के stored data encryption फीचर से पूरे database file को सुरक्षित रूप से protect किया जा सकता है
• WAL और temporary files तक encrypt होने से cloud environment में भी data leakage का जोखिम घटता है
• OpenSSL-based implementation में performance loss लगभग नहीं के बराबर है, इसलिए इसे production environment में भी प्रभावी ढंग से उपयोग किया जा सकता है
• encrypted DuckDB files CDN जैसे external distribution के लिए भी उपयुक्त हैं, और multi-table storage जैसी existing features बनी रहती हैं
• DuckDB team आगे user feedback के आधार पर इस फीचर को बेहतर बनाने की योजना रखती है

[GN⁺]

Hacker News टिप्पणियाँ

• AES-GCM में nonce reuse के प्रति संवेदनशीलता implementation के दौरान एक पेचीदा हिस्सा है
  दस्तावेज़ में इसका उल्लेख है, लेकिन इसका समाधान साझा नहीं किया गया
  हेडर में 12-byte की जगह 16-byte nonce शामिल है, और यह स्पष्ट नहीं है कि कौन-से byte random हैं, इसलिए भ्रम होता है। सोच रहा हूँ कि कहीं मैं कुछ मिस तो नहीं कर रहा

  • यह static key का उपयोग करता है, 12-byte random nonce बनाता है, और temporary buffer के लिए session-specific key का उपयोग नहीं करता

• DuckDB टीम की उपलब्धियों पर लगातार हैरानी होती है
  मैंने पहले OpenSSL के साथ DuckDB फ़ाइलों को encrypt करने का एक साधारण solution बनाया था, लेकिन पहली query पर 2x execution time लगता था और memory भी बहुत ज़्यादा इस्तेमाल होती थी
  इसके उलट DuckDB page-level encryption और CPU के AES acceleration का उपयोग करता है, इसलिए read/write cost लगभग नगण्य है

  • यह समझ नहीं आता कि बस LUKS का उपयोग क्यों नहीं करते
    यह kernel level पर acceleration का उपयोग करता है और ऊपर के application के लिए transparently काम करता है
    जब तक कई apps को अलग-अलग ACL और keys की ज़रूरत न हो, DB-level encryption अनावश्यक है
  • सच कहूँ तो मुझे नहीं लगता कि DuckDB का काम “हैरतअंगेज़” स्तर का है
    साधारण full-file encryption तरीके से तुलना करें तो यह निश्चित ही बेहतर दिखता है, लेकिन यह बुनियादी स्तर का implementation है
    हमें खुद भी इसी स्तर की quality को लक्ष्य बनाना चाहिए
  • आखिरकार यह pipelining की वजह से है
    storage I/O की तुलना में encryption cost लगभग मुफ्त जैसी है

• MotherDuck के अलावा multi-user cloud-based DuckDB को अच्छी तरह चलाने वाला कोई model है क्या, यह जानना चाहता हूँ
  मैं ऐसी संरचना ढूँढ रहा हूँ जहाँ कई users सामान्य DB की तरह एक साथ access कर सकें और DuckDB के फ़ायदे भी बने रहें

  • अगर सिर्फ़ pure DuckDB इस्तेमाल करना है, तो सामने Arrow Flight server रखा जा सकता है या httpserver extension इस्तेमाल किया जा सकता है
    .duckdb फ़ाइल कहाँ store की जाती है (S3 vs EFS), इससे performance में बड़ा फ़र्क पड़ता है
    लेकिन DuckLake बेहतर multiplayer option लगता है
    हम अपने product में DuckLake का उपयोग कर रहे हैं, और performance गिरावट कम करने के लिए analytics tables को GCP Filestore जैसे तेज़ storage में रखते हैं
    एक ही DuckLake catalog के अंदर कई storage methods को mix करना संभव है, इसलिए यह flexible है
  • आजकल “DuckDB inside Postgres” के बारे में बहुत-से लेख दिख रहे हैं, शायद वही आपके काम की चीज़ हो
  • GizmoSQL भी देखने लायक है

• DuckDB अब तक इस्तेमाल किए गए AI tools से ज़्यादा उपयोगी रहा है
  मुझे LLM पसंद हैं, लेकिन वास्तविक काम की दक्षता में DuckDB ने कहीं ज़्यादा मदद की है

• keys की indexing कैसे संभाली जाती है, यह जानने की जिज्ञासा है
  खोज के समय क्या keys को encrypted अवस्था में ही ढूँढते हैं, या हर block को decrypt किया जाता है?

• अक्सर कहा जाता है कि “SQLite encryption extension 2000-dollar का paid add-on है”, लेकिन
  SQLiteMultipleCiphers बहुत पहले से मुफ़्त उपलब्ध है
  इसके अलावा Turso Database default रूप से encryption support करता है

  • वास्तव में Python या Go में इस तरह के modified SQLite को plugins के साथ build करके इस्तेमाल कैसे किया जाए, यह जानना चाहता हूँ
    language-specific linking process काफ़ी पेचीदा लगती है
  • SQLCipher भी है
    यह 2009 से विकसित हो रहा है और स्थिर रूप से काम करने वाला solution है