मुख्य आशयावर जा
Change page

Web3 सीक्रेट स्टोरेज व्याख्या

तुमचे ॲप इथेरियमवर काम करण्यासाठी, तुम्ही Web3.js लायब्ररीद्वारे प्रदान केलेला web3 ऑब्जेक्ट वापरू शकता. अंतर्गतरीत्या, हे RPC कॉल्सद्वारे स्थानिक नोडशी संवाद साधते. web3 (opens in a new tab) कोणत्याही इथेरियम नोडसोबत काम करते जे RPC लेयर एक्सपोज करते.

web3 मध्ये eth ऑब्जेक्ट समाविष्ट आहे - web3.eth.

हे Web3 सीक्रेट स्टोरेज व्याख्येच्या आवृत्ती 3 चे दस्तऐवजीकरण करते.

व्याख्या

फाइलचे प्रत्यक्ष एन्कोडिंग आणि डिकोडिंग आवृत्ती 1 पासून बहुतांश अपरिवर्तित राहिले आहे, फक्त क्रिप्टो अल्गोरिदम आता AES-128-CBC वर निश्चित नाही (AES-128-CTR आता किमान आवश्यकता आहे). बहुतांश अर्थ/अल्गोरिदम आवृत्ती 1 सारखेच आहेत, फक्त mac वगळता, जे डिराइव्ह केलेल्या कीच्या डावीकडून दुसऱ्या 16 बाइट्स आणि संपूर्ण ciphertext च्या एकत्रीकरणाचे SHA3 (केकाक-256) म्हणून दिले जाते.

सीक्रेट की फाइल्स थेट ~/.web3/keystore (Unix-सारख्या सिस्टीमसाठी) आणि ~/AppData/Web3/keystore (Windows साठी) मध्ये स्टोअर केल्या जातात. त्यांना कोणतेही नाव दिले जाऊ शकते, परंतु एक चांगली पद्धत म्हणजे <uuid>.json वापरणे, जिथे <uuid> हे सीक्रेट कीला दिलेले 128-बिट UUID आहे (सीक्रेट कीच्या पत्त्यासाठी गोपनीयता जपणारा प्रॉक्सी).

अशा सर्व फाइल्सचा एक संबंधित पासवर्ड असतो. दिलेल्या .json फाइलची सीक्रेट की मिळवण्यासाठी, प्रथम फाइलची कूटलेखन की मिळवा; हे फाइलचा पासवर्ड घेऊन आणि kdf की द्वारे वर्णन केल्याप्रमाणे की डिरायव्हेशन फंक्शनमधून पास करून केले जाते. KDF फंक्शनसाठी KDF-अवलंबित स्टॅटिक आणि डायनॅमिक पॅरामीटर्सचे वर्णन kdfparams की मध्ये केले आहे.

PBKDF2 ला सर्व किमान-सुसंगत अंमलबजावणींद्वारे समर्थन दिले गेले पाहिजे, जे याद्वारे दर्शविले जाते:

  • kdf: pbkdf2

PBKDF2 साठी, kdfparams मध्ये हे समाविष्ट आहे:

  • prf: hmac-sha256 असणे आवश्यक आहे (भविष्यात वाढवले जाऊ शकते);
  • c: इटरेशन्सची संख्या;
  • salt: PBKDF ला पास केलेले सॉल्ट;
  • dklen: डिराइव्ह केलेल्या कीची लांबी. >= 32 असणे आवश्यक आहे.

एकदा फाइलची की डिराइव्ह झाल्यानंतर, MAC च्या डिरायव्हेशनद्वारे तिची पडताळणी केली पाहिजे. MAC ची गणना डिराइव्ह केलेल्या कीच्या डावीकडून दुसऱ्या 16 बाइट्स आणि ciphertext की मधील सामग्रीच्या एकत्रीकरणातून तयार झालेल्या बाइट ॲरेचा SHA3 (केकाक-256) हॅश म्हणून केली पाहिजे, म्हणजेच:

KECCAK(DK[16..31] ++ <ciphertext>)

(जिथे ++ हा कॉनकेटिनेशन ऑपरेटर आहे)

या मूल्याची तुलना mac की च्या सामग्रीशी केली पाहिजे; जर ते भिन्न असतील, तर पर्यायी पासवर्डची विनंती केली पाहिजे (किंवा ऑपरेशन रद्द केले पाहिजे).

फाइलच्या की ची पडताळणी झाल्यानंतर, सायफर टेक्स्ट (फाइलमधील ciphertext की) cipher की द्वारे निर्दिष्ट केलेल्या आणि cipherparams की द्वारे पॅरामीटराइज केलेल्या सिमेट्रिक कूटलेखन अल्गोरिदमचा वापर करून डिक्रिप्ट केले जाऊ शकते. जर डिराइव्ह केलेल्या कीचा आकार आणि अल्गोरिदमच्या कीचा आकार जुळत नसेल, तर डिराइव्ह केलेल्या कीचे झिरो पॅडेड, सर्वात उजवीकडील बाइट्स अल्गोरिदमची की म्हणून वापरले जावेत.

सर्व किमान-सुसंगत अंमलबजावणींनी AES-128-CTR अल्गोरिदमला समर्थन दिले पाहिजे, जे याद्वारे दर्शविले जाते:

  • cipher: aes-128-ctr

हा सायफर खालील पॅरामीटर्स घेतो, जे cipherparams की ला कीज म्हणून दिले जातात:

  • iv: सायफरसाठी 128-बिट इनिशियलायझेशन वेक्टर.

सायफरसाठी की ही डिराइव्ह केलेल्या कीचे सर्वात डावीकडील 16 बाइट्स असते, म्हणजेच, DK[0..15]

सीक्रेट की तयार करणे/कूटलेखन करणे हे मूलत: या सूचनांच्या उलट असावे. uuid, salt आणि iv खरोखरच रँडम असल्याची खात्री करा.

version फील्ड व्यतिरिक्त, जे आवृत्तीचे "हार्ड" आयडेंटिफायर म्हणून कार्य केले पाहिजे, अंमलबजावणी फॉरमॅटमधील लहान, नॉन-ब्रेकिंग बदलांचा मागोवा घेण्यासाठी minorversion देखील वापरू शकतात.

टेस्ट वेक्टर्स

तपशील:

  • Address: 008aeeda4d805471df9b2a5b0f38a0c3bcba786b
  • ICAP: XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67
  • UUID: 3198bc9c-6672-5ab3-d9954942343ae5b6
  • Password: testpassword
  • Secret: 7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d

PBKDF2-SHA-256

AES-128-CTR आणि PBKDF2-SHA-256 वापरून टेस्ट वेक्टर:

~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json ची फाइल सामग्री:

मध्यवर्ती (Intermediates):

Derived key: f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551 MAC Body: e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46 MAC: 517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2 Cipher key: f06d69cdc7da0faffb1008270bca38f5

Scrypt

AES-128-CTR आणि Scrypt वापरून टेस्ट वेक्टर:

मध्यवर्ती (Intermediates):

Derived key: 7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d MAC Body: edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2 MAC: 337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c Cipher key: 7446f59ecc301d2d79bc3302650d8a5c

आवृत्ती 1 मधील बदल

ही आवृत्ती येथे (opens in a new tab) प्रकाशित झालेल्या आवृत्ती 1 मधील अनेक विसंगती दूर करते. थोडक्यात ते खालीलप्रमाणे आहेत:

  • कॅपिटलायझेशन अयोग्य आणि विसंगत आहे (scrypt लोअरकेस, Kdf मिक्स्ड-केस, MAC अप्परकेस).
  • पत्ता अनावश्यक आहे आणि गोपनीयतेशी तडजोड करतो.
  • Salt हे मूळतः की डिरायव्हेशन फंक्शनचे पॅरामीटर आहे आणि ते त्याच्याशी संबंधित असणे आवश्यक आहे, सामान्यतः क्रिप्टोशी नाही.
  • SaltLen अनावश्यक आहे (फक्त ते Salt मधून डिराइव्ह करा).
  • की डिरायव्हेशन फंक्शन दिले आहे, तरीही क्रिप्टो अल्गोरिदम हार्ड-स्पेसिफाय केले आहे.
  • Version हे मूळतः अंकीय आहे तरीही ती एक स्ट्रिंग आहे (स्ट्रिंगसह स्ट्रक्चर्ड व्हर्जनिंग शक्य होईल, परंतु क्वचितच बदलणाऱ्या कॉन्फिगरेशन फाइल फॉरमॅटसाठी ते कक्षेबाहेरचे मानले जाऊ शकते).
  • KDF आणि cipher या संकल्पना सैद्धांतिकदृष्ट्या समान आहेत तरीही त्या वेगळ्या प्रकारे आयोजित केल्या आहेत.
  • MAC ची गणना व्हाईटस्पेस ॲग्नोस्टिक डेटाच्या तुकड्याद्वारे केली जाते(!)

पूर्वी लिंक केलेल्या पृष्ठावर दिलेल्या उदाहरणाच्या कार्यात्मकदृष्ट्या समतुल्य असलेली खालील फाइल देण्यासाठी फॉरमॅटमध्ये बदल केले गेले आहेत:

आवृत्ती 2 मधील बदल

आवृत्ती 2 ही अनेक बग्स असलेली सुरुवातीची C++ अंमलबजावणी होती. त्यातील सर्व आवश्यक गोष्टी अपरिवर्तित राहिल्या आहेत.