مرکزی مواد پر جائیں
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 bytes اور مکمل ciphertext کے ملاپ کے SHA3 (کیچاک-۲۵۶) کے طور پر دیا گیا ہے۔

خفیہ کلید کی فائلیں براہ راست ~/.web3/keystore (یونکس جیسے سسٹمز کے لیے) اور ~/AppData/Web3/keystore (Windows کے لیے) میں محفوظ کی جاتی ہیں۔ ان کا کوئی بھی نام رکھا جا سکتا ہے، لیکن ایک اچھی روایت <uuid>.json ہے، جہاں <uuid> خفیہ کلید کو دیا گیا 128-bit UUID ہے (خفیہ کلید کے پتہ کے لیے رازداری کو برقرار رکھنے والی پراکسی)۔

ایسی تمام فائلوں کا ایک متعلقہ پاس ورڈ ہوتا ہے۔ کسی دی گئی .json فائل کی خفیہ کلید اخذ کرنے کے لیے، سب سے پہلے فائل کی خفیہ کاری کی کلید اخذ کریں؛ یہ فائل کا پاس ورڈ لے کر اور اسے کلید اخذ کرنے والے فنکشن (KDF) سے گزار کر کیا جاتا ہے جیسا کہ kdf کلید کے ذریعے بیان کیا گیا ہے۔ KDF فنکشن کے لیے KDF پر منحصر جامد اور متحرک پیرامیٹرز kdfparams کلید میں بیان کیے گئے ہیں۔

PBKDF2 کو تمام کم از کم مطابقت رکھنے والے نفاذات کے ذریعے سپورٹ کیا جانا چاہیے، جسے اس طرح ظاہر کیا جاتا ہے:

  • kdf: pbkdf2

PBKDF2 کے لیے، kdfparams میں شامل ہیں:

  • prf: hmac-sha256 ہونا چاہیے (مستقبل میں اس میں توسیع کی جا سکتی ہے)؛
  • c: تکرار کی تعداد؛
  • salt: PBKDF کو پاس کیا گیا سالٹ (salt)؛
  • dklen: اخذ کردہ کلید کی لمبائی۔ = 32 ہونی چاہیے۔

ایک بار جب فائل کی کلید اخذ کر لی جائے، تو اسے MAC کے اخذ کے ذریعے تصدیق کیا جانا چاہیے۔ MAC کا حساب اخذ کردہ کلید کے بائیں سے دوسرے 16 bytes اور ciphertext کلید کے مندرجات کے ملاپ سے بننے والے بائٹ ایرے کے SHA3 (کیچاک-۲۵۶) ہیش کے طور پر کیا جانا چاہیے، یعنی:

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

(جہاں ++ ملاپ کا آپریٹر ہے)

اس قدر کا موازنہ mac کلید کے مندرجات سے کیا جانا چاہیے؛ اگر وہ مختلف ہیں، تو ایک متبادل پاس ورڈ طلب کیا جانا چاہیے (یا عمل منسوخ کر دیا جائے)۔

فائل کی کلید کی تصدیق کے بعد، سائفر ٹیکسٹ (فائل میں ciphertext کلید) کو cipher کلید کے ذریعے متعین کردہ اور cipherparams کلید کے ذریعے پیرامیٹرائزڈ سمیٹرک خفیہ کاری الگورتھم کا استعمال کرتے ہوئے ڈیکرپٹ کیا جا سکتا ہے۔ اگر اخذ کردہ کلید کا سائز اور الگورتھم کی کلید کا سائز مماثل نہیں ہیں، تو اخذ کردہ کلید کے زیرو پیڈڈ، دائیں جانب کے بائٹس کو الگورتھم کی کلید کے طور پر استعمال کیا جانا چاہیے۔

تمام کم از کم مطابقت رکھنے والے نفاذات کو AES-128-CTR الگورتھم کو سپورٹ کرنا چاہیے، جسے اس طرح ظاہر کیا جاتا ہے:

  • cipher: aes-128-ctr

یہ سائفر درج ذیل پیرامیٹرز لیتا ہے، جو cipherparams کلید کی کلیدوں کے طور پر دیے گئے ہیں:

  • iv: سائفر کے لیے 128-bit انیشلائزیشن ویکٹر۔

سائفر کے لیے کلید اخذ کردہ کلید کے بائیں جانب کے 16 bytes ہیں، یعنی DK[0..15]

خفیہ کلید کی تخلیق/خفیہ کاری بنیادی طور پر ان ہدایات کے برعکس ہونی چاہیے۔ اس بات کو یقینی بنائیں کہ uuid، salt اور iv واقعی بے ترتیب (random) ہیں۔

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 کے فائل مندرجات:

درمیانی مراحل:

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

Scrypt

AES-128-CTR اور Scrypt کا استعمال کرتے ہوئے ٹیسٹ ویکٹر:

درمیانی مراحل:

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

ورژن 1 سے تبدیلیاں

یہ ورژن یہاں (opens in a new tab) شائع شدہ ورژن 1 کے ساتھ کئی تضادات کو دور کرتا ہے۔ مختصراً یہ ہیں:

  • کیپیٹلائزیشن غیر منصفانہ اور متضاد ہے (scrypt چھوٹے حروف میں، Kdf ملے جلے حروف میں، MAC بڑے حروف میں)۔
  • پتہ غیر ضروری ہے اور رازداری سے سمجھوتہ کرتا ہے۔
  • Salt بنیادی طور پر کلید اخذ کرنے والے فنکشن کا ایک پیرامیٹر ہے اور اس کے ساتھ منسلک ہونے کا مستحق ہے، نہ کہ عام طور پر کرپٹو کے ساتھ۔
  • SaltLen غیر ضروری ہے (اسے صرف سالٹ سے اخذ کریں)۔
  • کلید اخذ کرنے کا فنکشن دیا گیا ہے، پھر بھی کرپٹو الگورتھم سختی سے متعین ہے۔
  • Version بنیادی طور پر عددی ہے پھر بھی ایک سٹرنگ ہے (سٹرنگ کے ساتھ سٹرکچرڈ ورژننگ ممکن ہو سکتی ہے، لیکن اسے شاذ و نادر ہی تبدیل ہونے والے کنفیگریشن فائل فارمیٹ کے دائرہ کار سے باہر سمجھا جا سکتا ہے)۔
  • KDF اور cipher تصوراتی طور پر ہم منصب تصورات ہیں پھر بھی انہیں مختلف طریقے سے منظم کیا گیا ہے۔
  • MAC کا حساب ڈیٹا کے ایک وائٹ اسپیس ایگنوسٹک حصے کے ذریعے کیا جاتا ہے(!)

درج ذیل فائل دینے کے لیے فارمیٹ میں تبدیلیاں کی گئی ہیں، جو عملی طور پر پہلے لنک کیے گئے صفحے پر دی گئی مثال کے مساوی ہے:

ورژن 2 سے تبدیلیاں

ورژن 2 ایک ابتدائی C++ نفاذ تھا جس میں کئی بگز تھے۔ تمام ضروری چیزیں اس سے غیر تبدیل شدہ رہتی ہیں۔