মূল কন্টেন্টে যান
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 (কেক্যাক-২৫৬) হিসেবে দেওয়া হয়।

সিক্রেট কী ফাইলগুলো সরাসরি ~/.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-এ পাস করা সল্ট (salt);
  • dklen: প্রাপ্ত কী-এর দৈর্ঘ্য। অবশ্যই >= 32 হতে হবে।

একবার ফাইলের কী বের করা হয়ে গেলে, এটি MAC ডেরিভেশনের মাধ্যমে যাচাই করা উচিত। প্রাপ্ত কী-এর বাম দিক থেকে দ্বিতীয় 16 বাইট এবং ciphertext কী-এর বিষয়বস্তুর কনক্যাটেনেশন হিসেবে গঠিত বাইট অ্যারের SHA3 (কেক্যাক-২৫৬) হ্যাশ হিসেবে MAC গণনা করা উচিত, অর্থাৎ:

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-এর ফাইলের বিষয়বস্তু:

ইন্টারমিডিয়েট:

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 অপ্রয়োজনীয় (এটি শুধু Salt থেকে বের করা যায়)।
  • কী ডেরিভেশন ফাংশন দেওয়া আছে, তবুও ক্রিপ্টো অ্যালগরিদম কঠোরভাবে নির্দিষ্ট করা হয়েছে।
  • Version মূলত সংখ্যাসূচক হওয়া সত্ত্বেও এটি একটি স্ট্রিং (একটি স্ট্রিং দিয়ে স্ট্রাকচার্ড ভার্সনিং সম্ভব হতে পারে, তবে খুব কম পরিবর্তন হওয়া কনফিগারেশন ফাইল ফরম্যাটের জন্য এটিকে স্কোপের বাইরে বিবেচনা করা যেতে পারে)।
  • KDF এবং cipher ধারণাগতভাবে সমতুল্য ধারণা হওয়া সত্ত্বেও এগুলো ভিন্নভাবে সাজানো হয়েছে।
  • MAC একটি হোয়াইটস্পেস অ্যাগনোস্টিক ডেটার মাধ্যমে গণনা করা হয়(!)

আগে লিঙ্ক করা পৃষ্ঠায় দেওয়া উদাহরণের কার্যকরী সমতুল্য হিসেবে নিচের ফাইলটি দেওয়ার জন্য ফরম্যাটে পরিবর্তন করা হয়েছে:

সংস্করণ 2 থেকে পরিবর্তনসমূহ

সংস্করণ 2 ছিল বেশ কয়েকটি বাগসহ একটি প্রাথমিক C++ ইমপ্লিমেন্টেশন। এর থেকে সমস্ত প্রয়োজনীয় বিষয় অপরিবর্তিত রয়েছে।