PDA

View Full Version : چرا نباید در زمینهء امنیت و رمزنگاری از خودمان الگوریتم اختراع کنیم!



eshpilen
پنج شنبه 08 خرداد 1393, 11:21 صبح
در این زمینه یه عبارت یا عبارتهای معروف مشابهی هست.
میتونید این عبارت رو در گوگل سرچ کنید تا براتون کلی نتیجه بیاره: don't roll your own crypto
من سعی میکنم چند توضیح خوب در این مورد رو پیدا و ترجمه کنم.

مثلا در این منبع: http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

یک نفر به پرسشی در این زمینه اینطور پاسخ داده (در بخش کامنت ها):

تعدادی افرادی که فکر میکردند بقدر کافی میدانند جمع شدند و یک روش رمزگذاری بنام WEP را برای شبکه های بی سیم ایجاد کردند. شما میتوانید WEP را در فقط چند دقیقه بشکنید. یک روش «مال خودتان را درست کنید» استفاده شده بود.

یک پاسخ دیگر:

شما میتوانید مال خودتان را درست کنید، اما اگر یک متخصص در امنیت/رمزنگاری نباشید یا روشتان توسط چند متخصص تحلیل نشود، احتمالا مرتکب یک اشتباه بزرگ امنیتی خواهید شدید. من بیشتر مایل هستم که روی یک روش رمزگذاری بازمتن که بصورت عمومی شناخته شده است و همه میتوانند آن را ببینند و تحلیل کنند شرط بندی کنم. چشمهای بیشتر به معنای احتمال کمتر آن است که نسخهء جاری آسیب پذیری مهمی داشته باشد نسبت به چیزی که در خانه توسط غیرمتخصصان توسعه داده شده است.
Phil Zimmermann (مخترع PGP) در کتاب آشنایی با رمزنگاری (صفحه 54) میگوید: «وقتی من در اوایل دهه 1970 در دبیرستان بودم، یک چیزی را طراحی کردم که فکر میکردم یک روش رمزگذاری نبوغ آمیز است. یک جریان عددی شبه رندوم به جریان متنی اضافه میشد تا یک متن رمزی را ایجاد کند. بنظر میرسید که این هر نوع تحلیل فرکانس متن رمزی را عقیم میگذارد، و حتی برای مجهزترین آژانس های امنیتی حکومت غیرقابل شکستن خواهد بود. من از این دستاورد خودم بسیار خرسند بودم.
سالها بعد، روش یکسانی را در چندین کتاب مقدماتی و مقاله های خودآموز رمزنگاری کشف کردم. چقدر جالب. دیگر رمزنگارها به روش یکسانی فکر کرده بودند. متاسفانه، آن روش بعنوان یک تمرین در خانه دربارهء اینکه چطور میتوان تحلیل های ابتدایی را برای شکستن آن بسادگی استفاده کرد مطرح شده بود. این برای روش نبوغ آمیز من خیلی زیاد بود.
من از این تجربهء فروتن کننده آموختم که چقدر ساده است که هنگام طراحی یک الگوریتم رمزنگاری به یک توهم اشتباه از امنیت دچار شد. بیشتر مردم درنمی یابند که چقدر بطور شیطانی ای دشوار است که یک الگوریتم رمزنگاری طراحی کرد که بتواند دربرابر یک حملهء طولانی و مصمم از جانب یک دشمن کاردان/مجهز مقاومت کند.»

اگر شما دربارهء «الگوریتم رمزنگاری خودتان را درست نکنید» قانع نشده اید، پس شما احتمالا یک متخصص نیستید و اشتباهات بسیاری وجود دارند که احتمالا مرتکب خواهید شد.

منبع: http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

خب فعلا تا همین جا :چشمک:

eshpilen
پنج شنبه 08 خرداد 1393, 11:50 صبح
Bruce Scheier در 1998 نوشت:
هرکس، از نادان ترین آماتور تا بهترین متخصص رمزنگاری، میتواند الگوریتمی ایجاد کند که خودش نتواند بشکند. آن حتی سخت نیست. آنچه سخت است درست کردن الگوریتمی است که هیچ کس دیگری حتی بعد از سالها تحلیل نتواند بشکند. و تنها راه اثبات آن، در معرض گذاشتن الگوریتم برای سالها تحلیل بوسیلهء بهترین متخصصان رمزنگاری که پیدا میشوند است.

eshpilen
یک شنبه 18 خرداد 1393, 10:48 صبح
«اجزاء اولیه رمزنگاری» الگوریتم های رمزنگاری بخوبی جا افتاده و سطح پایینی هستند که بصورت مکرر برای ساخت پروتکل های امنیتی یا سیستمهای امنیت رایانه استفاده میشوند. این روتین ها شامل، ولی نه محدود به، توابع هش یک طرفه و توابع رمزگذاری هستند.
در هنگام ایجاد سیستمهای رمزنگاری، طراحان اجزاء اولیه را بعنوان پایه ای ترین بلاک های سازنده خودشان استفاده میکنند. بخاطر این، اجزاء اولیه برای انجام یک وظیفهء خیلی خاص به شکلی با حد بالایی از اطمینان طراحی میشوند.
از آنجاییکه اجزاء اولیه بعنوان بلاک های سازنده استفاده میشوند، آنها باید بسیار قابل اطمینان باشند، یعنی مطابق مستندات فنی خود عمل کنند. برای مثال، اگر یک روتین رمزگذاری ادعا کند که فقط با تعداد X عملیات رایانه قابل شکستن است، سپس اگر آن بتواند با مقداری به حد قابل توجهی کمتر عملیات شکسته شود، گفته میشود که آن جزء اولیه شکسته شده است. اگر یک جزء اولیه شکسته شود، تقریبا هر پروتکلی که از آن استفاده میکند آسیب پذیر میشود. از آنجاییکه ایجاد روتین های رمزنگاری بسیار دشوار است، و تست آنها برای قابلیت اطمینان زمان طولانی ای میطلبد، اساسا نامعقول (و همچنین ناامن) است که برای تامین نیازهای یک سیستم رمزنگاری جدید یک جزء اولیه جدید طراحی شود. دلایل آن شامل این موارد میشود:

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

اجزاء اولیه رمزنگاری از بعضی جهات به زبانهای برنامه نویسی شباهت دارند. یک برنامه نویس رایانه به ندرت وقتی که یک برنامهء جدید مینویسد یک زبان برنامه نویسی جدید اختراع میکند؛ بجایش، او یکی از زبانهای برنامه نویسی جاافتاده را برای برنامه نویسی استفاده میکند.

چند نمونه از اجزاء اولیه رمزنگاری متداول:

- توابع هش یک طرفه.
- رمزنگاری کلید خصوصی (م: متقارن).
- رمزنگاری کلید عمومی (م: نامتقارن).
- امضاهای دیجیتال.
- توابع تولید اعداد شبه رندوم امنیتی (CSPRNG).

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

========================

منبع: http://en.wikipedia.org/wiki/Cryptographic_primitive

abbas.oveissi
پنج شنبه 26 تیر 1393, 05:42 صبح
دوست عزیز خیلی جالب بود،نمیخواستم اسپم بدم اما گفتم نظر بدم که این تاپیک یادتون بیافته و ادامه بدید

احسان!
پنج شنبه 26 تیر 1393, 10:32 صبح
البته میشه که الگوریتم خودمون رو هم اختراع کنیم!چرا که نه؟:) فقط باید از لحاظ ریاضی اثبات کنیم که این الگوریتم امنه.:)

abbas.oveissi
جمعه 27 تیر 1393, 00:24 صبح
البته میشه که الگوریتم خودمون رو هم اختراع کنیم!چرا که نه؟:) فقط باید از لحاظ ریاضی اثبات کنیم که این الگوریتم امنه.:)
خب مهمترین که این تاپیک هم روش تاکید داشت همین قضیه اثبات هست :متفکر: اثبات این قضیه خیلی مشکل هست

احسان!
جمعه 27 تیر 1393, 00:55 صبح
خب مهمترین که این تاپیک هم روش تاکید داشت همین قضیه اثبات هست :متفکر: اثبات این قضیه خیلی مشکل هست بله.من فقط خلاصه مطلب رو گفتم.:)

Akhoundi
شنبه 28 تیر 1393, 22:18 عصر
میشه یه خورده بیشتر راجع به روش های ضعیف توضیح بدید؟
یعنی کمی ریاضی-منطقی توضیح بدید(روال رمز شدن و رمز نگاری ضعیف)

eshpilen
یک شنبه 29 تیر 1393, 09:19 صبح
به گمانم اثبات این توصیه (عنوان تاپیک) بیشتر بر اساس تجربه هست تا تئوری.
همونطور که در متن اشاره شده، طراحی الگوریتم ها و پروتکل ها و سیستمهای رمزنگاری کاری هست که بطور تجربی مشخص شده نیاز به تخصص و تجربهء کافی داره و بعدش هم باید اون الگوریتم و سیستم برای مدت کافی از زیر بررسی و دسترسی عمومی (بخصوص توسط متخصصان این رشته) جان سالم به در ببره تا بشه بهش اطمینان خوبی داشت (بخصوص که اثبات های ریاضی در این زمینه در خیلی موارد بسیار دشوار هستن و در خیلی موارد تاکنون پیدا نشدن).
البته مسلما تخصص و طراحی و تحلیل در این رشته، به تئوری ها و ریاضیاتش هم نیاز داره.

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

eshpilen
یک شنبه 29 تیر 1393, 09:29 صبح
مثلا الگوریتم هش SHA-256 اثبات ریاضی نداره (در واقع فکر کنم تمام الگوریتم های هش).
یا حتی AES هم اثبات نداره!
حتی RSA که بر مسائل دشوار ریاضی بنا شده هم میشه گفت اثبات محکم ریاضی نداره، چون بر این بنا شده که برای فلان مسئله در ریاضی تاکنون راه حل بقدر کافی سریعی پیدا نشده، و نه اینکه اثبات بکنه که چنین راه حلی اصولا وجود نداره (ممکنه وجود داشته باشه ولی تاحالا کشف نشده).

اما نداشتن اثبات های ریاضی و تئوریک قاطع به این معنی نیست که به تئوری و ریاضی در طراحی این الگوریتم ها نیازی نیست! اتفاقا تئوری و ریاضی در این حیطه خیلی مهمه و نقش عمده ای داره. پس فکر نکنید همینطور بدون بلد بودن تئوری هاش و ریاضیاتش، صلاحیت طراحی الگوریتم ها و سیستمهای رمزنگاری رو دارید.