پیشرفته کریپتو پدیا

توضیحاتی جامع و کامل پیرامون مفهوم هش کش (hashcash)

در این نوشتار به توضیح هش کش (Hashcash) و نحوه استفاده بیت کوین از آن پرداخته می شود. بیت کوین از عملکرد گواه اثبات کار هش کش به عنوان اساس استخراج استفاده می کند. همه ماینر های بیت کوین خواه سی پی یو، کارت گرافیک، FPGA یا ایسیک باشند، در حال تلاش برای ایجاد گواه اثبات کار هش کش می باشند که در تکامل بلاک چین به عنوان رای عمل می کند و گزارش تراکنش های بلاک چینی را اعتبار سنجی می کند.

هش کش مانند بسیاری از الگوریتم های رمزنگاری از یک عملکرد هش به عنوان یک بلاک ساختاری استفاده می کند، به همان روشی که امضا های HMAC یا RSA بر روی یک عملکرد هش قابل اتصال تعریف می شوند (معمولا با یک مجموعه نامگذاری شده از الگوریتم و هش مانند HMAC-SHA1، HMAC-MD5، HMAC-SHA256، RSA-SHA1 و غیره نشان داده می شوند)، هش کش را می توان با عملکرد های مختلفی مانند hashcash-SHA1 (اولیه)، hashcash-SHA256^2 (بیت کوین) و hashcash-Scrypt(iter=1) ارائه داد.

تاریخچه هش کش

تاریخچه هش کش

عملکرد گواه اثبات کار هش کش در سال ۱۹۹۷ توسط آدام بک (Adam Back) اختراع شد و برای استفاده در برابر حملات DoS پیشنهاد شد که از جمله آنها می توان به جلوگیری (سوء استفاده از درگاه remailer و mail2news ناشناس، قرار گرفتن نام nym بر روی nymserver ها) و همچنین آنتی اسپم ایمیل عمومی و کنترل سوء استفاده های عمومی شبکه را نام برد. هش کش قبل از بیت کوین توسط SpamAssasin و با فرمت ناسازگاری توسط مایکروسافت و با نام email postmark در هات میل، exchange، outlook و غیره و توسط شبکه ناشناس i2p، مولفه های remailer ناشناس mixmaster و دیگر سیستم ها مورد استفاده قرار می گرفت.

هش کش همچنین توسط گواه اثبات کار قابل استفاده مجدد Hal Finney که از پیشروان بیت کوین بود به عنوان روشی برای استخراج کوین ها مورد استفاده قرار می گرفت. پیشنهاد B-money توسط Wei Dai و پیشنهاد مشابهBit Gold توسط Nick Szabo نیز در فضای استخراج هش کش مطرح شدند.

گزینه‌های عملکرد هش

در هش کش الگوریتم اولیه سال ۱۹۹۷ از SHA1 استفاده می شد زیرا در آن زمان پذیرفته شده و هش توصیه شده NIST بود و هش بالفعل قبلی یعنی MD5 به تازگی شروع به نشان دادن نشانه هایی از ضعف کرده بود. در ۲۰۰۸ تا ۲۰۰۹، بیت کوین با استفاده از SHA256 در حال بیرون داده شدن بود. در واقع دلیل محکمی مبنی بر اینکه SHA1 نیز کار نکرده، وجود ندارد. هش کش تنها متکی بر ویژگی مقاومت پیش نمایش ناقص هش می باشد و بر سختی برخورد مرحله ظهور متکی نیست،

بنابراین هش SHA1 به اندازه کافی بزرگ است. بیت کوین به هر صورت با امنیت ۱۲۸ بیت ساخته شده است زیرا ECDSA ۲۵۶ بیت استفاده می شود که همچنین امنیت ۱۲۸ بیت ارائه می دهد. با این وجود SHA۲۵۶ صحیح و انتخاب محافظه کارانه تری است زیرا حتی SHA1 شروع به نشان دادن مقداری ضعف کرده است، اگرچه این تنها در برخورد مرحله پیدایش است و در دومین پیش نمایش نمی باشد.

ریسک‌های Cryptanalytic

یک مسئله عملی در مورد انتقال به hashcash-SHA3 این است که آن در کل سخت افزار استخراج ایسیک موجود را بی اعتبار می کند و بنابراین این تغییر برای وقوع غیر محتمل است، مگر این که ریسک امنیتی در میان باشد. هیچ نشانه ای وجود ندارد که SHA1، SHA256 یا SHA256^2 به نسبت حمله پیش نمایش آسیب پذیر باشند، بنابراین انگیزه به دلیل فقدان توسعه های cryptanalytic جدید از میان می رود.

علاوه بر این، حتی اگر SHA256^2 به دلیل حمله Cryptanalytic آسان تر شود و ماینر ها استفاده از رویکرد الگوریتم جدید را شروع کرده باشند، آن ضرورتا اهمیت پیدا نمی کند زیرا سختی با آن تطابق پیدا می کند. اما احتمالا یک تاثیر جانبی این خواهد بود که آن حافظه بیشتر یا مبادلات پیش محاسباتی را معرفی می کند و این می تواند ایسیک ها را غیر سودآور سازد و یا مزیت هایی را برای افراد با منابع بزرگ برای انجام پیش محاسبات فراهم آورند.

مزیت های پیش محاسباتی شاید انگیزه کافی برای جایگزین کردن هش با SHA3 باشد. به هر حال، این همه گمانه زنی ها تا زمانی است که پیش نمایش حملات cryptanalytic را که بر روی SHA256 پیدا شده، تحت تاثیر قرار دهد.

عملکرد هش کش

دلیل کاهش هش ریت بیت کوین

درک الگوریتم هش کش نسبتا ساده می باشد. این ایده بر اساس یک ویژگی امنیتی هش های رمزنگاری ساخته می شود که آنها طوری طراحی شده اند که برای معکوس کردن سخت می باشند (به اصطلاح ویژگی مقاومت پیش نمایش یا یک طرفه نام دارد). می توان y را از x به آسانی محاسبه کرد y=H(x) اما پیدا کردن x تنها با y خیلی سخت است. یک معکوس هش کامل دارای یک زمان اجرای آزمون و خطای ناممکن محاسباتی می باشد (O(2^k) که k اندازه هش است مانند SHA256، k=256)، و اگر یک پیش نمایش پیدا می شد، هرکس می توانست به شیوه ای خیلی موثر از طریق محاسبه یک هش، آن را تایید کند. بنابراین عدم تقارن خیلی بزرگی در استخراج پیش نمایش کامل (از لحاظ محاسباتی غیر ممکن) در برابر تایید (نوعی فراخوانی هش خاص) وجود دارد.

پیش نمایش هش دوم به این معنی است که پیش نمایش اول داده شده x از هش y به شیوه y=H(x) است، این کار برای پیدا کردن پیش نمایش دیگری از هش y:x` می باشد به طوری که y=H(x`). این را نباید با برخورد مرحله پیدایش قاتی کرد که آن برای پیدا کردن دو ارزش x و x` می باشد که خواهیم داشت H(x)= H(x`). این را می توان با کار بسیار کمتری انجام داد زیرا می توان از طریق محاسبه تعداد زیادی ارزش های H(x) و ذخیره آنها تا پیدا کردن یک جفت مطابق، آن را انجام داد. این حافظه زیادی می گیرد اما مبادلات memory-time در این میان موجود می باشد.

نسخه 0 از پروتکل هش کش از یک پیش نمایش دوم ناقص استفاده می کرد، اما نسخه بعدی یعنی نسخه ۱ (۲۰۰۲) از یک پیش نمایش ناقص از یک رشته نسبتا انتخاب شده استفاده می کند، بجای ارقام pi یا چیزی اختیاری، 0^k برای راحتی به کار می رود، بنابراین کار برای پیدا کردن x به شیوه ای است که H(x)=0. این نیز به همان شیوه عادلانه است و تنها نیازمند یک فراخوانی هش برای تایید در برابر دو با پیش نمایش ناقص دوم است. برای آسان تر کردن کار، تعریف یک پیش نمایش ناقص به صورت پیدا کردن x به شیوه ای است که H (x)/2^(n-k)=0 باشد که / خارج قسمت صحیح تقسیم می باشد، n اندازه خروجی هش و k عامل کار است یعنی اولین بیت های k از خروجی هش ۰ می باشند. پس به عنوان مثال k=20 نیازمند به طور متوسط یک میلیون سعی می باشد. آن در واقع خروجی ای می باشد که تا حدودی تطابق دارد و پیش نمایش نیست. بنابراین شاید بتوان به طور دقیق تری آن را پیش نمایش با تطابق خروجی ناقص نامید که جهت سهولت، آن را پیش نمایش ناقص می نویسند.

افزودن منظور

اگر پیش نمایش ناقص x از y=H(x) تصادفی باشد، آن فقط یک گواه اثبات کار غیر مرتبط بدون هیچ منظوری می باشد. همه می توانند ببینند که شما کار را انجام داده اید اما آنها نمی دانند چرا و بنابراین کاربران می توانند همان کار را برای سرویس های مختلف مورد استفاده مجدد قرار دهند. برای مقید ساختن گواه اثبات کار به یک سرویس یا یک منظور، هش باید شامل s باشد که یک رشته سرویس است و بنابراین این کار تبدیل به پیدا کردن H (s,c)/2^(n-k)=0 می شود. ماینر counter c را تغییر می دهد تا این درست شود. رشته سرویس می تواند یک نام دامنه سرور وب باشد یا یک آدرس ایمیل گیرنده و یا در بیت کوین بلاکی از دفتر کل بلاک چین بیت کوین باشد.

یک مشکل اضافی این است که اگر افراد متعددی در حال استخراج باشند و از همین رشته سرویس استفاده کنند، آنها نباید با همان x شروع کنند و یا باید در نهایت مدرک مشابهی داشته باشند و در این حالت، هر کس که به آن نگاه کند، از یک کپی از آن برخوردار نخواهد شد زیرا آن می تواند بدون کار هم کپی شده باشد. اولین فردی که آن را ارائه دهد، پاداش خواهد گرفت و از کار افراد دیگر امتناع می شود. برای اجتناب از ریسک اتلاف کار به این شیوه، لازم است که یک نقطه شروع تصادفی موجود باشد و بنابراین کار تبدیل به پیدا کردن H(s,x,c)/2^(n-k)=0 می شود که x تصادفی است و c شمارشگر تغییر داده شده است و s نیز رشته سرویس است.

این چیزی است که هش کش نسخه ۱ و بیت کوین انجام می دهند. در واقع در بیت کوین، رشته سرویس coinbase است و شامل آدرس پاداش گیرنده ها به علاوه تراکنش های موجود برای اعتبار سنجی در بلاک می باشد. بیت کوین در واقع شامل یک نقطه شروع تصادفی x نمی باشد و از آدرس پاداش به عنوان عامل تصادفی سازی برای اجتناب از برخورد ها برای این منظور نقطه شروع تصادفی استفاده مجدد می کند که ۱۶ بایت فضا را در coinbase ذخیره می کند. بیت کوین برای مقاصد حریم خصوصی انتظار دارد که ماینر از آدرس پاداش متفاوتی در هر بلاک موفق استفاده کند.

کار دقیق تر

هش کش همچنان که در ابتدا پیشنهاد شد دارای کار 2^k است که k یک عدد صحیح می باشد. این یعنی که سختی تنها می تواند با توان 2 سنجیده شود، همچنان که می بینید این کار نسبتا آسان تر است و سختی را تنها با شمردن صفر ها در شش/دوتایی ها می توان کاملا اندازه گیری کرد و این برای کاربرد های قبلی کافی بود (تعداد زیادی از انتخاب های طراحی هش کش توسط سادگی انگیزه می گیرند).

اما به دلیل اینکه بیت کوین به کنترل کار پویا تر و دقیق تری نیاز دارد (برای هدف گرفتن فاصله بلاک ۱۰ دقیقه ای به طور صحیح)، k به صورت کسری تغییر داده می شود، بنابراین کار تبدیل به پیدا کردن H(s,x,c)<2^(n-k) می شود که اگر k عدد صحیح باشد، مساوی می باشد. بیت کوین هدف 2^(n-k) را تعریف می کند، بنابراین این کار را به طور ساده تر می توان نوشت تا H(s,x,c)<target را پیدا کرد. البته به دلیل شانس، زمان بلاک در واقع واریانس نسبتا بالایی دارد اما میانگین هنوز به طور دقیق تری با معرفی k کسری هدف قرار گرفته است.

کار، سختی و امنیت رمزنگاری

رمزگذاری و رمزنگاری

هش کش حاشیه امنیتی را در اصطلاحات امنیتی رمزنگاری استاندارد O(2^k) ابراز می کند که برای مقایسه، DES مقدار k=56 bits از امنیت را ارائه می دهد، ECDSA-256 مقدار k=128 bits از امنیت را ارائه می دهد و به دلیل استفاده گسترده آن از روش log2 برای اظهار کار و امنیت، می تواند همچنین برای انجام مقایسات امنیتی مفید باشد.

سرعت کار بیت کوین هش ریت شبکه نامیده می شود و مقیاس آن GH/sec می باشد. همچنان که می دانید فاصله بلاک هدف ۱۰ دقیقه است که قابل تغییر به یک امنیت رمزنگاری به صورت log2 می باشد، هش ریت در نوامبر ۲۰۱۳ برابر ۴ petahash/sec بود و گواه های اثبات کار هش کش ۲۵۶^۲  بیت کوین ۶۲ بیت بودند.

بیت کوین همچنین مفهوم جدیدی از سختی نسبی را تعریف می کند که کار مورد نیاز است و بنابراین در هش ریت شبکه حال حاضر، انتظار می رود که هر ده دقیقه یک بلاک پیدا شود. آن در ارتباط با یک واحد کاری مینیمم ۳۲^۲ تکراری اظهار می شود (تقریبا، کار مینیمم فنی به دلیل جزئیات سطح پیاده سازی بیت کوین 0xFFFF0000 می باشد). سختی بیت کوین برای تبدیل تقریبی به امنیت رمزنگاری log2 ساده می باشد. سختی به طور ساده ای مرتبط با هدف می باشد و می توان گفت که difficulty=target/0xFFFF0000.

شاید اسان تر باشد که با سختی های بالا در مقیاس log2 دست و پنجه نرم کرد و آنها را با دیگر اظهارات امنیتی رمزنگاری قابل مقایسه ساخت. به عنوان مثال، پروژه EFF deepcrack DES cracker یک دستگاه آزمون و خطای سخت افزاری ساخت که قادر به شکستن یک کلید DES در ۵۶ ساعت برای ایجاد یک نکته سیاسی بود که DES ۵۶ بیت در سال ۱۹۹۸ با هزینه ۲۵۰۰۰۰ دلار بسیار ضعیف بود. شبکه بیت کوین در مقایسه با آن هر ده دقیقه ۶۲ بیت انجام می دهد و ۵۳۷۰۰۰ بار قدرتمند تر از deepcrack می باشد و یا می تواند چنین باشد به شرطی که بجای SHA256 بر DES متمرکز باشد که یک کلید DES را در ۹ ثانیه می شکافد و این در حالی است که deepcracks آن را در ۵۶ ساعت انجام می داد.

حریم خصوصی ماینر

در تئوری، یک ماینر باید جهت حفظ حریم خصوصی خود از آدرس پاداش متفاوتی برای هر بلاک استفاده کند (و شمارشگر را به صورت ۰ تنظیم مجدد نماید). دلیل اینکه بیت کوین های اولیه ایجاد شده توسط ساتوشی احتمالا مرتبط بوده اند این است که در حالی که آدرس پاداش را تغییر می داده است، فراموش کرده که بعد از هر ماین موفق شمارشگر را تنظیم مجدد نماید که این یک باگ حریم خصوصی استخراج بیت کوین است. در واقع در مورد بیت کوین شمارشگر باید تار و مبهم شود، در غیر این صورت سطح تلاش فرد آشکار می شود و اگر قدرت استخراج زیادی داشته باشید، آن ممکن است تلویحا اشاره کند که کوین متعلق به چه کسی است.

بیت کوین این را از طریق nonce و extra-nonce انجام می دهد. Nonce از ۰ شروع می شود اما extra-nonce تصادفی است. اینها با هم یک شمارشگر تصادفی را ایجاد می کنند که مقدار تلاشی که برای مدرک انجام شده است را پنهان می کنند، بنابراین کسی نمی تواند بگوید که آیا آن یک ماینر قدرتمند اما بدشانس بوده که به سختی کار کرده یا یک ماینر ضعیفی بوده که خیلی خوش شانس بوده است.

علاوه بر این، با معرفی استخر های استخراج، اگر ماینر از یک آدرس پاداش برای همه کاربران استفاده کند که پروتکل های ماینینگ حال حاضر هم چنین می کنند، این ریسک وجود دارد که کاربران ممکن است دوباره کار را انجام دهند. برای اجتناب از این که کاربران دوباره کار را انجام دهند، ماینر ها کار تعیین شده را به کاربران می دهند تا انجام دهند. اما این یک حرکت رفت و برگشتی ارتباطی غیر ضروری را ایجاد می کند و در نسخه های پروتکل اولیه شاید عاملی در تصمیم گیری بود که استخر را وادار به فرستادن بلاک واقعی برای ماین می کرد و این یعنی ماینر ها بلاک های خود را اعتبار سنجی نمی کنند و اعتبار سنجی (نه کار) را به اپراتور استخر محول می کنند که این امنیت شبکه بیت کوین را کاهش می دهد. نسخه پروتکل ماینینگ جدید تر به کاربر اجازه می دهد که تعریف بلاک خود را اضافه نماید و در واقع نیازی به صحبت با استخر برای اختصاص کار نیست.

از آنجا که این پروتکل استخراج جمعی جدید دارای extraNonce انتخاب شده توسط ماینر می باشد، این به عنوان یک عامل شروع تصادفی عمل می کند، بنابراین در واقع نیازی به صحبت با استخر برای اختصاص کار نیست. یک استخر می تواند آدرس منتشر شده استاتیک داشته باشد و ماینر ها می توانند به انتخاب خود کار کنند و آن را به عنوان بسته UDP به استخر ارائه دهند. (اگر حریم خصوصی توسط ماینر مورد نیاز باشد، آن می تواند از روش مشتق عمومی از BIP ۳۲ استفاده کند تا به نود اجازه دهد از طریق یک پیام رمزگذاری شده با کار ماینینگ با ماینر ارتباط برقرار کند که کلید عمومی استاتیک را با کدام فاکتور ضرب کند.)

گواه اثبات کار Scrypt

صحبت کردن در مورد گواه اثبات کار Scrypt یک سوء تفاهم می باشد. Scrypt به عنوان یک عملکرد گواه اثبات کار طراحی نشده است بلکه یک عملکرد اشتقاق کلیدی گسترش یافته است. و در حالی که از لحاظ طراحی محاسبه آن با تکرار های بالا گران است اما نمی توان آن را برای ایجاد یک گواه اثبات کار قابل بازرسی عمومی موثر مورد استفاده قرار داد، زیرا که هزینه های تایید همانند هزینه های ایجاد می باشد.

هش کش با عملکرد هش داخلی Scrypt ممکن است به صورت hashcash-scrypt (1) نشان داده شود. Scrypt از منظر Collin Percival یک عملکرد اشتقاق کلیدی برای تغییر عبارت های گذر انتخابی کاربر به داخل کلید ها می باشد. به این ترتیب در برابر حملات گوناگون مقاومت ایجاد می شود و هش چندین بار تکرار می شود تا قطعه قطعه کردن عبارت ورود به آهستگی انجام گیرد. Scrypt از لحاظ هدف مشابه عملکرد اشتقاق کلیدی استاندارد PBKDF2 می باشد. نقطه تفاوت و این که چرا مردم ممکن است Scrypt را بر PBDF2 ترجیح دهند این است که هش درونی Scrypt حافظه بیشتری را مورد استفاده قرار می دهد و بنابراین مزیت کارت گرافیک در خرد کردن رمز عبور در مقایسه با سی پی یو ها کاهش پیدا می کند.

این از ویژگی توسعه کلید Scrypt استفاده نمی کند، بنابراین ماینینگ در واقع به طور مستقیم از Scrypt استفاده نمی کند و تنها هش Scrypt درونی مورد استفاده قرار می گیرد. بنابراین این عملکرد اصلا برای مشارکت در سختی به کار نمی رود و بر خلاف استفاده نرمال آن برای محافظت کلید می باشد (مثلا در مشتق کردن کلید رمزگذاری از عبارت گذر کاربر برای رمزگذاری کردن کیف پول های بیت کوینی). دلیل اینکه این عملکرد نمی تواند برای استخراج مورد استفاده قرار گیرد این است که تایید آن توسط همان عامل به طور همزمان گران تر تمام می شود. این نوع دیگر هش کش را می توان به صورت hashcash-Scrypt (iter=1, mem=128KB) نشان داد و یا به صورت hashcash-Scrypt (1) خلاصه نویسی کرد. پارامتر برجسته دیگر Scrypt مقدار حافظه مورد استفاده را مشخص می کند.

غیر متمرکز سازی: hashcash-Scrypt در برابر hashcash-SHA256

اثر حافظه Scrypt 128 کیلوبیتی ادعا می شود که آن را به نسبت تمرکز قدرت استخراج کمتر آسیب پذیر می کند که این تمرکز قدرت از دسترسی محدود به مالکیت تجهیزات ایسیک توسط کاربران ناشی می شود. صحت این ادعا مشخص نیست زیرا بحث هایی در مقابل آن وجود دارد از جمله اینکه hashcash-SHA256^2 بسیار ساده است، بنابراین یک فرد ماهر با پس انداز شخصی خود و یا یک پروژه kickstarter کوچک می تواند به طراحی و سفارش گذاری با یک سازنده تراشه بپردازد. این سادگی تضمین می کند که بسیاری از افراد آن را انجام خواهند داد و ایسیک ها باید در دسترس قرار بگیرند. برعکس، در مقایسه با سخت ایسیک hashcash-Scrypt (1) تا حدودی دشوار تر می باشد، شاید در میان مدت ثابت شود که این برای تمرکز بدتر هم می باشد. اگر یک موجودیت مالی توانمند با داشتن ایسیک های سریع تر اما انحصاری، بازار را به حاشیه براند، استخراج کارت گرافیکی Scrypt غیر سودآور خواهد شد.

توجه داشته باشید که یک عامل کاهش دهنده در اینجا این است که hashcash-Scrypt (1) چنین در نظر گرفته می شود که باید سرعت کمتری را از پیاده سازی ایسیک در برابر کارت گرافیک ها از hashcash-SHA256^2 ارائه دهد. این ادعا به این دلیل می شود که اظهار می شود که ناحیه مرده 128kB رم را اشغال کرده است که ممکن است فکر شود که آن باید به هر هسته Scrypt (1) اختصاص داده شود و این تعداد هسته های Scrypt (1) را که با هر تراشه تناسب دارد، کاهش می دهد. اما توجه داشته باشید که Scrypt (1) در واقع یک هارد حافظه ایمن نیست و تلاشی برای جلوگیری از مبادلات time-memory به عمل نمی آورد. بنابراین در واقع تکرار محاسبه دور های داخلی برای محاسبه برای کاهش نیازمندی حافظه ممکن است. بنابراین در تئوری ممکن می باشد اگرچه پیاده سازی Scrypt (iter=1, mem=128kB) با مینیمم حافظه و با کار بیشتر از لحاظ محاسباتی گران تر است. مبادلات time-memory در سخت افزار بهینه می شود تا مقدار بهینه حافظه برای استفاده پیدا شود و کاملا ممکن است که مقدار بهینه کمتر از 128kB باشد.

Hashcash-Scrypt (1) همچنین در مقایسه با hashcash-SHA256^2 دارای یک عیب می باشد و آن این است که هزینه تایید یک تکرار Scrypt بسیار بالاتر از دو هش SHA256 می باشد. این بلاک چین های Scrypt اعتبار سنج را برای همه نود های کامل در استفاده از سی پی یو و حافظه تشدید می کند. توجه داشته باشید که کار اعتبار سنجی سی پی یو غالب است و آن تایید امضا های ECDSA هر تراکنش از مجموعه تراکنش ها در یک بلاک می باشد. حتی یک امضای ECDSA آهسته تر از یک تایید Scrypt (1) می باشد که یکبار در هر بلاک انجام می شود. و تراکنش های بسیار زیادی (همچنین تایید های امضای ECDSA) برای تایید در داخل یک بلاک موجود هستند.

آخرین بروزرسانی ۱۳۹۹/۰۷/۰۶

منبع
en.bitcoin.it

نوشته های مشابه

اشتراک
اطلاع از
0 دیدگاه
Inline Feedbacks
View all comments
دکمه بازگشت به بالا