LUKS2 vs LUKS1: अंतर, वर्ज़न कैसे जाँचें और कैसे बदलें

संक्षेप में: LUKS2 Linux डिस्क encryption का मौजूदा on-disk फ़ॉर्मैट है और cryptsetup 2.1 से डिफ़ॉल्ट है। LUKS1 की तुलना में यह रिडंडेंट, checksum वाला JSON मेटाडेटा हेडर, PBKDF2 की जगह memory-hard Argon2id key derivation, 8 की जगह 32 keyslots, TPM2 और FIDO2 अनलॉक के लिए टोकन, और वैकल्पिक authenticated encryption जोड़ता है। LUKS2 ही इस्तेमाल करें, जब तक किसी पुराने GRUB को खुद `/boot` decrypt न करना हो।

दोनों फ़ॉर्मैट डेटा को एक ही तरह encrypt करते हैं, आमतौर पर AES-XTS से। फ़र्क हेडर में है: keys कैसे स्टोर होती हैं, passphrase को brute-force करना कितना कठिन है, और कौन-से टूल इसे पढ़ सकते हैं। यह गाइड अंतर, आपके पास कौन-सा वर्ज़न है यह जाँचने का तरीका, और डिस्क खोए बिना `cryptsetup convert` से कन्वर्ट करने की प्रक्रिया बताता है। अगर आप छोटे VPS पर सेल्फ़-होस्टिंग स्टैक के लिए नया सर्वर encrypt कर रहे हैं, तो LUKS2 ही चुनें।

LUKS2 vs LUKS1: एक नज़र में

हेडर फ़ॉर्मैट और keyslots

LUKS1 हेडर एक निश्चित बाइनरी संरचना है जिसके बाद आठ keyslot क्षेत्र आते हैं। अगर डिवाइस के शुरुआती सेक्टर ओवरराइट हो जाएँ, जैसे गलती से चले `mkfs` या किसी पार्टिशनिंग टूल से, तो हर keyslot मिट जाता है और हेडर बैकअप के बिना डेटा खो जाता है।

LUKS2 एक बाइनरी हेडर और एक JSON मेटाडेटा क्षेत्र रखता है, और दोनों की दूसरी कॉपी भी रखता है। हर कॉपी में checksum होता है, इसलिए `cryptsetup` करप्शन पहचानकर दूसरी कॉपी पर जा सकता है। JSON क्षेत्र keyslots, segments, digests और टोकन का वर्णन करता है, और इसी वजह से फ़ॉर्मैट को दोबारा बदले बिना नए फ़ीचर जोड़े जा सकते हैं। फिर भी रिडंडेंसी हेडर बैकअप का विकल्प नहीं है: शुरुआती मेगाबाइट्स का पूरा ओवरराइट दोनों कॉपियाँ नष्ट कर देता है।

Argon2id vs PBKDF2

Passphrase को कभी सीधे key की तरह इस्तेमाल नहीं किया जाता। एक key derivation function उसे इस तरह खींचता है कि हर अनुमान महँगा पड़े। LUKS1 केवल PBKDF2 इस्तेमाल कर सकता है, जो GPU और ASIC पर सस्ता चलता है, इसलिए हेडर की कॉपी रखने वाला हमलावर तेज़ गति से समानांतर में passphrase आज़मा सकता है।

LUKS2 डिफ़ॉल्ट रूप से Argon2id इस्तेमाल करता है, जिसे हर अनुमान के लिए कॉन्फ़िगर करने योग्य मात्रा में मेमोरी चाहिए (डिफ़ॉल्ट रूप से 1 GiB तक, फ़ॉर्मैट के समय उपलब्ध RAM तक सीमित) और जिसे समानांतर करना कहीं ज़्यादा महँगा है। मज़बूत passphrase अब भी मुख्य बचाव है, लेकिन Argon2id हर अनुमान की लागत काफ़ी बढ़ा देता है।

छोटे सर्वरों पर मेमोरी लागत का ध्यान रखें। ज़्यादा RAM वाली मशीन पर बना keyslot अनलॉक होने के लिए उससे ज़्यादा मेमोरी माँग सकता है जितनी 1 GB का VPS, जैसे NoctisNode Wisp प्लान, initramfs के अंदर दे सकता है। बड़ी मशीन पर छोटी मशीन के लिए फ़ॉर्मैट करते या keys जोड़ते समय इसे `--pbkdf-memory` (KiB में) से साफ़-साफ़ सेट करें।

# Inspect PBKDF parameters of each keyslot
cryptsetup luksDump /dev/vda3 | grep -A6 '^  [0-9]*: luks2'

# Re-derive keyslot 0 with Argon2id and 512 MiB memory cost
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 \
  --pbkdf argon2id --pbkdf-memory 524288

टोकन, integrity और GRUB से जुड़ी सावधानियाँ

टोकन LUKS2 हेडर में मौजूद JSON ऑब्जेक्ट हैं जो टूल्स को बताते हैं कि key अपने-आप कैसे प्राप्त करें। `systemd-cryptenroll` इनका उपयोग किसी keyslot को TPM2 चिप, FIDO2 सिक्योरिटी key या PKCS#11 स्मार्टकार्ड से बाँधने के लिए करता है, और Clevis इन्हें Tang सर्वर के साथ नेटवर्क-आधारित अनलॉक के लिए इस्तेमाल करता है। LUKS1 में इनमें से कुछ भी नहीं है।

Integrity मोड (`cryptsetup luksFormat --integrity hmac-sha256`) encryption को dm-integrity के साथ जोड़ता है, ताकि छेड़छाड़ किए गए सेक्टर चुपचाप बदला हुआ डेटा देने की बजाय read error दें। इसकी कीमत डिस्क स्पेस और write स्पीड है, फ़ॉर्मैट के समय पूरा wipe ज़रूरी है, और यह अब भी प्रायोगिक माना जाता है। ज़्यादातर सर्वर इसे इस्तेमाल नहीं करते।

लोगों को अब भी LUKS1 मिलने की मुख्य वजह GRUB है। Upstream GRUB 2.06 और उसके बाद के वर्ज़न LUKS2 खोल सकते हैं, लेकिन केवल PBKDF2 वाले keyslots, क्योंकि Argon2 सपोर्ट upstream GRUB का हिस्सा नहीं है। अगर GRUB को खुद encrypted `/boot` decrypt करना हो, तो LUKS1 या `--pbkdf pbkdf2` वाला LUKS2 keyslot इस्तेमाल करें। Debian और Ubuntu इंस्टॉलर `/boot` को unencrypted रखते हैं, इसलिए अनलॉक kernel और initramfs करते हैं और Argon2id काम करता है, SSH पर रिमोट अनलॉक में भी।

कैसे जाँचें कि वॉल्यूम LUKS1 है या LUKS2

चलते सिस्टम पर root के रूप में इनमें से कोई भी तरीका काम करता है। `cryptsetup luksDump` की `Version:` लाइन ही प्रामाणिक उत्तर है; dump में keyslots, PBKDF प्रकार और टोकन भी दिखते हैं।

# Find encrypted partitions (FSVER column shows 1 or 2)
lsblk -f

# Authoritative: header version
cryptsetup luksDump /dev/vda3 | grep -E '^Version'
# Version:        2

# Exit code 0 only if the device is LUKS2
cryptsetup isLuks --type luks2 /dev/vda3 && echo LUKS2

cryptsetup convert से कन्वर्ट करना

`cryptsetup convert` हेडर को उसी जगह दोबारा लिखता है; encrypted डेटा को छुआ नहीं जाता। डिवाइस बंद होना चाहिए, इसलिए root फ़ाइलसिस्टम के लिए इसे rescue या live सिस्टम से चलाएँ। कन्वर्ज़न के बीच विफलता या बिजली जाने से हेडर बेकार हो सकता है, इसलिए बैकअप वाला कदम वैकल्पिक नहीं है।

1. 01.Rescue या live सिस्टम बूट करें और सुनिश्चित करें कि LUKS डिवाइस खुला नहीं है (ज़रूरत हो तो `cryptsetup close`)।
2. 02.`cryptsetup luksHeaderBackup` से हेडर का बैकअप लें और फ़ाइल को सर्वर से बाहर कॉपी करें। इस फ़ाइल और किसी पुराने passphrase वाला कोई भी व्यक्ति डिस्क अनलॉक कर सकता है, इसलिए इसे encrypted रूप में रखें।
3. 03.`cryptsetup convert --type luks2` से LUKS1 को LUKS2 में बदलें। मौजूदा keyslots PBKDF2 ही रहते हैं।
4. 04.हर keyslot को `cryptsetup luksConvertKey --pbkdf argon2id` से Argon2id में अपग्रेड करें, जब तक GRUB को उसे पढ़ना न हो।
5. 05.जाँचें कि डिवाइस खुलता है, फिर `update-initramfs -u` से initramfs दोबारा बनाएँ और रीबूट करें।
6. 06.LUKS2 से वापस LUKS1 पर जाने के लिए पहले हर keyslot को PBKDF2 में बदलें और टोकन व LUKS2-only फ़ीचर हटाएँ; वरना `cryptsetup convert --type luks1` मना कर देता है।

# From a rescue system, device closed
cryptsetup luksHeaderBackup /dev/vda3 --header-backup-file /root/vda3-luks-header.img

cryptsetup convert --type luks2 /dev/vda3
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 --pbkdf argon2id

cryptsetup open /dev/vda3 cryptroot && cryptsetup close cryptroot

# Emergency restore (overwrites the current header!)
# cryptsetup luksHeaderRestore /dev/vda3 --header-backup-file /root/vda3-luks-header.img

Note · हेडर restore करने के बाद बैकअप के समय मान्य passphrase फिर से काम करने लगते हैं, उनमें वे भी जिन्हें आपने बाद में हटा दिया था। Passphrase बदलते समय पुराने हेडर बैकअप डिलीट करें। मौजूदा बैकअप को अलग जगह रखें, उदाहरण के लिए restic बैकअप गाइड में बताई गई repository में।

अक्सर पूछे जाने वाले सवाल