# زبان های اسکریپتی > PHP > امنیت در PHP >  امنیت ریاضیات است!

## SZsXsZS

در پاییز 1995، در سال دوم تحصیلم بعنوان یک دانشجو در دانشگاه Simon Fraser، یک دورهء درسی بنام Math 242 داشتم که عنوانش «آشنایی با تحلیل» بود. این یک دورهء اجباری برای دانشجویان ریاضی بود (و هنوز هست)، و به دلایل خیلی خوبی اغلب بعنوان «دوره ای که مشخص میکند آیا شما مدرک ریاضی را خواهید گرفت» توصیف میشود، و نخستین دوره ای است که دقت و سختگیری ریاضی را جدی میگیرد. آیا درس حسابان سال اول را که مباحث دنباله ها، سری ها، همگرایی، پیوستگی توابع، حد را در خود داشت بیاد دارید؟ این دوره ای است که شما یاد میگیرید هرچیزی را که فکر میکنید از پیش میدانید اثبات کنید.

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

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

این چیزی است که Bruce Schneier «ذهنیت امنیتی» مینامد -- و همهء ریاضیدان ها آن را دارند. در نخستین فصل تز دکترای من، یک صفحه را به اثبات قضیه ای درمورد توزیع اعداد اول اختصاص دادم (این قضیه که بین ‎x و x * (1 + 2 / log(x))‎ حداقل x / log(x)^2 عدد اول وجود دارد؛ یعنی حداقل نصف تعداد مورد انتظار). من این را تنها بخاطر این انجام ندادم چون از آن خوشم می آمد، بلکه آن را انجام دادم چون بدون آن نمیتوانستم یک محدودهء خطا برای الگوریتم تصادفی خودم را ثابت کنم. بیشتر دانشمندان علوم رایانه بسادگی دستان خود را تکان میدهند  و این فرض متداول را بعنوان پیشفرض قرار میدهند که اعداد اول به شکل تصادفی رفتار میکنند؛ اما با آموزش ریاضی که من دیده بودم، یک اثبات میخواستم که بر روی فرض های خارجی بنا نشده باشد.

Knuth بخاطر این گفته که «مراقب باگ ها در کد بالا باشید؛ من تنها ثابت کرده ام که آن درست است، اما آن را امتحان نکرده ام» مشهور است، و من با بیان ضمنی اینکه یک اثبات درستی برای اطمینان از اینکه کد درست عمل خواهد کرد کافی نیست مطلقا موافقم؛ اما، مهم است که ماهیت باگ هایی را که از چشم کسی که اثبات را مینویسد فرار میکنند مورد توجه قرار دهیم. این باگ ها -- که من فرض میکنم باگ های بالقوه ای بوده اند که Knuth درمورد آنها هشدار میداد -- بیشتر اشتباهاتی هستند موقع انتقال ایده ها از مغز به کیبورد: بطور مثال جا انداختن یک سمیکالن یا پرانتز، یا قاطی کردن نام دو متغییر. این باگها براحتی با حداقل میزان تست کردن پیدا میشوند. بنابراین نه تست و نه اثبات به تنهایی خیلی موثر نیستند، و در ترکیب هر دو است که تاثیر به حداکثر میرسد.

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

Bruce Schneier درست میگوید که امنیت نیازمند یک ذهنیت غیرعادی است؛ و درست میگوید که دانشکده های علوم کامپیوتر جای خوبی برای آموزش دادن این ذهنیت نیستند. اما او در اشتباه است که این ذهنیت نمیتواند آموزانده شود: اگر شما میخواهید کسی امنیت را درک کند، کافیست او را به مدت چهار سال به دانشکدهء ریاضی یک دانشگاه بفرستید.

منبع: http://www.daemonology.net/blog/2008...thematics.html

نکته: این ترجمه با مقداری حذف های جزیی میباشد.

----------


## SZsXsZS

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

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

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

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

----------


## intheway

خلاصه کلام امنیت و اینها یک ذهن زیبا میخواد! یاد فیلم فرار از زندان افتادم اونجا که دوربین زوم میکرد روی خالکوبیهای مایکل و بعد از یک دنیای دیگری سر در میآورد. بخشی از ریاضیات ، و بخشی از برنامه نویسی ، و علم فلسفه ، این سه تا چیز به نظرم من به یک ذهن احتیاج دارن که بتونه بخوبی انواع راههای ممکن و محتمل رو در ذهنت تصور بکنه. یک ذهنی که وقتی بهش سرنخ قضیه رو میدی if و else ها رو تا تهش بتونه تو ذهن ترسیم بکنه. و یک غریضه خوب که اگر نمی تونی انتهای یک if و else تو در تو رو ببینی ، حداقل خط قرمز هاش رو حسگرهات به موقع بهت آلارم بدن و متوجهشون بشی  :لبخند گشاده!:

----------


## intheway

تعریف از خود نباشه !  :لبخند گشاده!:  ولی من تو ریاضیات دوره دبیرستان پادشا بودم واسه خودم تو حسابان 20 گرفته بودم 1 نمراه بیشتر از شاگرد ممتاز مدرسمون. و تو هندسه 2 با اینکه نمرم پایین بود ولی به دلیل اثبات یک سوال به 3 روش که یکیش کاملا برای معلمم جدید بود بیشتر از بارم اون سوال بهم نمره داده بود. یادش بخیر دوران شیرینی بود..
بعدهام کاملا اهمیت ریاضی رو تو برنامه نویسیم احساس کردم مثلا اگر مثلثات بدونی رسم یه نیمدایره با جاوا اسکریپت یا اکشن اسکریپت به مراتب برات راهت تر میشه..
یا مثلا تو بازی ها  میزان این SALT یا SEED ای که برای تولید مقادیر رندم بکار میره بسیار مهم هست. یک برنامه نویس با درک ریاضی و آماری خوب میتونه یک بازیکن فوتبال درست کنه که با اینکه مشخصاتی از قبیل Speed یا Power اش کاملا مشخص هست اما خودش هم نمیتونه بگه در یک بازی PC با PC کدوم تیم فوتبال با چه احتمالی برنده خواهد شد.
یا همین === بجای == که شما قبلن تو این انجمن مطرح کرده بودی این به نظرم یک ذهنیت خوب میخواد که بتونه اینجور چیزهارو تفکیک و تحلیل بکنه..این یک سنسور ذهنی خوب میخواد..

----------


## golbafan

متن قشنگی بود. تشکر...
بعنوان مثال تفاوت در امنیت رمزنگاری RSA با انواع مختلف ECC رو فقط یک ریاضی دان میتونه درک کنه...
مثلا امنیت در RSA از لحاظ ریاضی بر اساس این مطلب گذاشته شده که پیدا کردن دو عامل جبری اول بزرگ (دو تا عدد اول بزرگ) برای یک عدد صحیح بزرگ *کار سختی هست*! دقت کنید که نگفته ناممکن، بلکه گفته مشکل است. این جزئیات در ادبیات خیلی مهمه و همین جمله نشون میده که میشه راهی برای کشف رمز کلید ها انجام داد که البته خیلی کوتاه تر از روش بروت-فورس باشه!
اما مبنای ECC بر این پایه ریاضی هست که میگه پیدا کردن لگاریتم گسسته از یک عنصر تصادفی منحنی بیضوی با توجه به یک نقطه پایهٔ عمومی شناخته شده *غیر عملی می‌باشد
*بناربراین از لحاظ تئوری میشه بجای استفاده از RSA که برای تامین امنیت نیاز به کلید های طولانی (4096 بیتی) داره از ECC با کلید های کوتاه (128 بیتی) استفاده کرد.

دقیقتر بخوام بگم امنیت RSA 3072 با ECC 128 قابل مقایسه است. بنا براین امنیت ECC 256  رو میشه با RSA 15360 بیتی مقایسه کرد!!!

----------


## SZsXsZS

> همین جمله نشون میده که میشه راهی برای کشف رمز کلید ها انجام داد که البته خیلی کوتاه تر از روش بروت-فورس باشه!


میشه نه، ممکنه!
ممکن هم هست چنین روشی موجود نباشه. کسی نمیدونه راه حل polynomial time برای فاکتورگیری اعداد صحیح خیلی بزرگ در حالت عمومی وجود داره یا نه.
البته ما داریم درمورد رایانه های کلاسیک صحبت میکنیم (بحث کوانتمی نداریم).




> اما مبنای ECC بر این پایه ریاضی هست که میگه پیدا کردن لگاریتم گسسته از یک عنصر تصادفی منحنی بیضوی با توجه به یک نقطه پایهٔ عمومی شناخته شده [COLOR=#ff0000][B]غیر عملی می‌باشد


تاجاییکه میدونم وضعیت درمورد ECC هم مثل RSA است. یعنی کسی نمیدونه الگوریتم polynomial براش وجود داره یا نه. ممکنه وجود داشته باشه و ممکنه وجود نداشته باشه.
مزیت ECC بر RSA عمدتا در کوتاه تر بودن طول کلیدهاش است که در بعضی کاربردها مفیده، وگرنه از نظر وضعیت امنیت ذاتی تفاوت چندانی با RSA نداره.

----------


## SZsXsZS

The introduction of elliptic curve cryptography by Neal Koblitz and Victor Miller, independently and simultaneously in the mid-1980s, has yielded new public key algorithms based on the discrete logarithm problem

در این متن میگه که ECC بر discrete logarithm problem بنا شده.

https://en.wikipedia.org/wiki/Public-key_cryptography

Unsolved problem in computer science:
Can the discrete logarithm be computed in polynomial time on a classical computer?

در اینجا اشاره میکنه که پیدا کردن الگوریتم polynomial time برای حل کردن discrete logarithm یک مسئلهء حل نشده در علوم کامپیوتر است. نمیگه چنین الگوریتمی وجود نداره، بلکه میگه مشخص نیست میشه یا نمیشه.

https://en.wikipedia.org/wiki/Discre...m#Cryptography

اگر شک دارید یا ویکیپدیا رو قبول ندارید، منابع دیگر هم میشه پیدا کرد!

حقیقت دربارهء ECC مقداری تبلیغات و جوگیری وجود داشته و اغراق شده. گفتم که مزیت ECC عمدتا کوتاهتر بودن طول کلیدهاش است، و البته کمی هم سریعتر از RSA است (ولی فکر نمیکنم این در بیشتر کاربردها اهمیت زیادی داشته باشه).
یه چیز دیگه هم بهتون بارها گفته بودم چی بود؟ گفتم الگوریتم های جدید مقداری محل ابهام و تردید هم هستن و نباید جوگیر شد و عجله کرد که حالا حتما از جدیدترین الگوریتم ها استفاده کنیم! فیلد رمزنگاری یک تفاوتش با فیلدهای دیگر اینه که هرچی الگوریتمی سابقهء بیشتری داشته باشه و درش ضعف جدی پیدا نشده باشه، اعتبارش بالاتر میره، ضریب اطمینان بهش بالا میره، چون سالها انگیزه و تلاش و محک براش بوده و چشم ها و مغزهای زیادی نتونستن درش ضعف جدی پیدا کنن. به همین علت هست که RSA اعتبار زیادی برای خودش دست و پا کرده، همینطور هم AES، همینطور هم HMAC. و تنها در مواردی که دلایل خوب و روشنی داریم که از الگوریتم های جدید استفاده کنیم باید این کار رو بکنیم. البته مطالعه و یادگیری الگوریتم های جدید مسلما نیازه و خوب است و باید در این رشتهء بروز بود (از نظر اطلاعات و توانایی)، ولی لزوما به این معنا نیست که صرفا بخاطر جدیدتر بودن استفاده از الگوریتم های جدید رو ترجیح بدیم.

In contrast with its current standing over RSA, elliptic curve cryptography is expected to be more vulnerable to an attack based on Shor's algorithm.[39] In theory, making a practical attack feasible many years before an attack on an equivalently secure RSA scheme is possible.[40] This is because smaller elliptic curve keys are needed to match the classical security of RSA. The work of Proos and Zalka show how a quantum computer for breaking 2048-bit RSA requires roughly 4096 qubits, while a quantum computer to break the equivalently secure 224-bit Elliptic Curve Cryptography requires between 1300 and 1600 qubits.

برخلاف RSA، انتظار میرود رمزنگاری ECC در برابر حمله بوسیلهء الگوریتم Shor (کوانتمی) آسیب پذیرتر باشد. در تئوری، یک حملهء عملی در مقابل ECC سالها قبل از آنکه یک حمله بر روی RSA با امنیت برابر ممکن شود شدنی است. این بخاطر آن است که کلیدهای ECC کوچکتر هستند. کار Proos و Zalka نشان میدهد که یک کامپیوتر کوانتمی برای شکستن RSA ی 2048 بیتی به حدودا 4096 کیوبیت نیاز دارد، درحالیکه یک کامپیوتر کوانتمی برای شکستن ECC ی 224 بیتی (که دارای امنیت (کلاسیک) برابر با RSA ی 2048 بیتی است) چیزی بین 1300 تا 1600 کیوبیت نیاز دارد.

https://en.wikipedia.org/wiki/Ellipt...raphy#Security

پس ملاحظه میکنید که درواقع از این جهت امنیت ECC از RSA کمتر هم هست.
البته در مواردی سعی کردن این مشکل رو بوسیلهء ترفندهایی حل کنن.

----------


## SZsXsZS

> اما مبنای ECC بر این پایه ریاضی هست که میگه پیدا کردن لگاریتم گسسته از یک عنصر تصادفی منحنی بیضوی با توجه به یک نقطه پایهٔ عمومی شناخته شده [COLOR=#ff0000][B]غیر عملی می‌باشد


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

----------


## SZsXsZS

> پیدا کردن دو عامل جبری اول بزرگ (دو تا عدد اول بزرگ) برای یک عدد صحیح بزرگ *کار سختی هست*! دقت کنید که نگفته ناممکن، بلکه گفته مشکل است.


منظور از سخت و مشکل در این موارد، اینه که اگر اعداد بقدر کافی بزرگ باشن، حل کردن این مسئله حتی روی قوی ترین ابررایانه ها زمان خیلی زیادی مطلبه (اونقدر زیاد که عملا شدنی نیست یا زمانیکه جواب بدست بیاد اونقدر گذشته که سودی نخواهد داشت).
مثلا 500 سال!
یعنی غیرممکن نیست، ولی الگوریتمی که بتونه با سرعت بقدر کافی زیاد این کار رو انجام بده تاحالا کشف نشده (برای رایانه های کلاسیک/غیرکوانتمی البته).

The strength of a public key cryptography system relies on the degree of difficulty (computational impracticality) for a properly generated private key to be determined from its corresponding public key.

توی این متن هم اشاره کرده که منظور از سختی یعنی از نظر پردازشی غیرعملی است. وگرنه از نظر ریاضی که شدنیه.

https://en.wikipedia.org/wiki/Public-key_cryptography

----------


## nerset

اگر در مورد ساختار زیبا و ساده توزیع اعداد اول می خواهید بدانید
و از  چرایی اینکه از فرمول عمومی توابع پلی نرمال برای بدست آوردن اعداد اول  استفاده می شود بدون اینکه از ماهیت حقیقی این فرمول ها اطلاع داشته باشید
و همچنین کمی هم در مورد ساختار توزیع اعداد اول دوقلو بدانید
به وبلاگ زیر مراجعه نمایید:
http://nvm.blogsky.com
و  اگر روزی توانستید که توابع مکمل تولید کننده اعداد با یکان 9*1 را که یکی  از سه بخش اصلی باقی مانده برای تولید صد در صدی اعداد اول به صورت کاملا  جبری است و در مقاله اعداد اول به آن اشاره شده است را پیدا کنید به شما  تبریک میگویم چون کلید راز سومین حلقه تولید اعداد اول با یکان 9 را بدست  آورده اید.
و یا شاید هم بتوانید توابع مکمل دیگر را هم که با یکان 1 و 3  و 7 هستند را هم پیدا کرده و توابع تولید کننده اعداد اول این سه گروه  بزرگ عددی را هم بدست آورید.

----------

