[Folaani]

کی Cryptography کار کرده؟
من میخواستم در چند مورد همفکری کنم.
چنتا سوال.
اول اینکه شما برای تولید کلید از پسورد از چه الگوریتمی استفاده میکنید؟ مثلا بسادگی یک هش ازش میگیرید (و از چه نوعی؛ مثلا md5 یا sha1 و غیره).
دوم اینکه اگر بخوایم از یک پسورد یک کلید با طول بالاتر از خروجی تابع هش مربوطه دربیارید از چه روشی استفاده میکنید؟ مثلا خروجی md5 که ۱۲۸ بیت هست اما ما یک کلید ۲۵۶ بیتی میخوایم.
سوم اینکه در یک الگوریتمی مثل AES در حالت CBC شما IV رو آیا در یک فایلی که رمز میکنید ذخیره میکنید دیگه؟ و کجاش؟ فکر میکنم معمولا در ابتدای فایل.
چهارم اینکه از تابع MAC استانداردی استفاده میکنید (آماده یا خودتون پیاده سازی کردید؟) یا از یک روش ابداعی (و چی هست؟).
راستی درمورد نکات امنیتی ای که در اینمورد سراغ دارید و بکار میبندید هم اگر میتونید بگید.
یعنی مثلا چه نکات ظریف و پنهانی رو باید مد نظر قرار بدیم.

[آبنبات]

سلام
در مورد سوال اول اینکه در دنیای منبع آزاد علاقه شدیدی به استفاده از MD5 هست.
در مورد سوال دوم هم باید بگویم اصولا وقتی یک الگوریتم یک خروجی خاص می دهد نمی شود آن را بیشتر یا کمتر کرد مگر اینکه پارامتر ورودی برای این کار داشته باشد. اگر الگوریتم مورد نظر شما این قابلیت را ندارد، راه حلی که به نظر من می رسد این است که خروجی را گرفته و یک بار دیگر عمل hash کردن را به روش استاندارد خودتان روی آن انجام دهید.
اما نکته اینکه اطلاع دارم در پلتفرم net. کلاس های بسیار خوبی برای رمزنگاری موجود هست که احتمالا در mono هم پیاده سازی شده باشند. اما در این موارد در زبان های برنامه نویسی پر کاربرد معمولا کتابخانه هایی برای رمزنگاری موجود هستند (حال همراه زبان به عنوان کتابخانه های استاندارد یا کتابخانه های نوشته شده توسط افراد دیگر). به هر حال نوشتن و پیاده سازی این الگوریتم ها یا ابداع آن ها برای همه افراد توصیه نمی شود زیرا وقت زیادی می برد. توصیه شخصی من هم این است که اگر کار شما به گونه ایست که می توانید از موارد آماده استفاده کنید، حتما از آن ها استفاده کنید زیرا هم در زمان شما صرفه جویی می شود و هم آزمون خود را پس داده اند.

[m_pahlevanzadeh]

مورد استفادتون چیه؟

[Folaani]

سلام
در مورد سوال اول اینکه در دنیای منبع آزاد علاقه شدیدی به استفاده از MD5 هست.

منم از همین استفاده کردم چون توی خیلی مثالها هم دیدم که بسادگی از md5 استفاده میکنن.
ولی این الگوریتم طبق نظر کارشناسان دیگه امن محسوب نمیشه و حمله های موفقی بهش صورت گرفته؛ البته این موارد بیشتر در بحث پیدا کردن collision و امضاهای دیجیتالی بودن، اما بنظرم بطور کلی باعث میشن این الگوریتم از استاندارد در عموم موارد خارج بشه. هرچند هنوز خیلی جاها الگوریتمهای خیلی قویتری ساپورت نمیشن. مثلا در PHP فقط md5 , sh1 رو داریم که sha1 هم از نظر امنیتی ضعیف و شکسته شده محسوب میشه (هرچند ممکنه هنوز از md5 امن تر باشه). البته میشه جستجو کرد یا خودمون پیاده سازی الگوریتمهای دیگر رو بنویسیم و استفاده کنیم.

من یک الگوریتم تولید کلید از پسورد دیدم که جالب بود؛ یک الگوریتم استاندارد که RSA تهیه کرده.
ولی میخواستم بدونم هنوز استفاده از روش سادهء یک لایه هش مستقیم اونم با md5 متداول هست یا نه (چون میتونه تاحدی میزان امنیت عملی و فعلی اون رو نشون بده).

در مورد سوال دوم هم باید بگویم اصولا وقتی یک الگوریتم یک خروجی خاص می دهد نمی شود آن را بیشتر یا کمتر کرد مگر اینکه پارامتر ورودی برای این کار داشته باشد. اگر الگوریتم مورد نظر شما این قابلیت را ندارد، راه حلی که به نظر من می رسد این است که خروجی را گرفته و یک بار دیگر عمل hash کردن را به روش استاندارد خودتان روی آن انجام دهید.

آیا منظورت این طور هست:

کد :

key=md5(pass) | md5(md5(pass))

توضیح: علامت | به معنای concatenate هست.

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

بنده از crypto++ استفاده میکنم که فکر میکنم معروف ترین و حرفه ای ترین کتابخانهء رمزنگاری تحت سی++ باشه. خوشبختانه تونستم با mingw هم کامپایلش کنم و در یک برنامهء Qt تحت ویندوز ازش استفاده کنم.
البته بازم آدم مجبوره بعضی کارها رو خودش انجام بده. مثلا این کتابخانه فقط یک تابع داره که یک فایل با تمام محتویات لازم تولید میکنه و بعد میتونی به همون راحتی هم بخونیش، که این تابع/کلاس از الگوریتم 3DES استفاده میکنه. من میخواستم از AES در مد CBC استفاده کنم و بنابراین مجبور شدم ساختار فایل رو خودم بسازم و مثلا IV رو در ابتدای اون درج کنم. ضمنا MAC هم بکار نبردم.

[Folaani]

مورد استفادتون چیه؟

خب رمز کردن یک فایل
میخواید چی باشه چه فرقی میکنه مگه؟

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

بطور کلی Cryptography یکی از جالبترین مباحثی بود که تاحالا خونده بودم و کلی چیز برای بحث کردن داره. از نظر ریاضی هم جالب و غنی هست (قابل توجه کسانی که دنبال کاربرد مستقیم ریاضی در برنامه نویسی میگردن). ولی خیلی کم در این زمینه بحث شده ظاهرا. میشه ازش کتاب های آکادمیک جالبی درآورد :wink: (داریم؟)

[آبنبات]

ولی این الگوریتم طبق نظر کارشناسان دیگه امن محسوب نمیشه و حمله های موفقی بهش صورت گرفته؛ البته این موارد بیشتر در بحث پیدا کردن collision و امضاهای دیجیتالی بودن، اما بنظرم بطور کلی باعث میشن این الگوریتم از استاندارد در عموم موارد خارج بشه. هرچند هنوز خیلی جاها الگوریتمهای خیلی قویتری ساپورت نمیشن. مثلا در PHP فقط md5 , sh1 رو داریم که sha1 هم از نظر امنیتی ضعیف و شکسته شده محسوب میشه (هرچند ممکنه هنوز از md5 امن تر باشه). البته میشه جستجو کرد یا خودمون پیاده سازی الگوریتمهای دیگر رو بنویسیم و استفاده کنیم.

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

من یک الگوریتم تولید کلید از پسورد دیدم که جالب بود؛ یک الگوریتم استاندارد که RSA تهیه کرده.

اگر لطف کنید و معرفی کنید که خوب است شاید به کار فردی آمد و شما را هم دعا کرد.

key=md5(pass) | md5(md5(pass))

اگر اشتباه نکنم شما چند بار hash ساخته اید و آن را به هم متصل کرده اید. در نگاه اول که ایده بدی به نظر نمی آید. اما منظور من دقیقا این نبود. بعد از آن هم باید ببنید این روش شما در کجا استفاده می شود. مثلا اگر در قسمت ورود یک سایت برای ایجاد یک session جدید استفاده شود و این سایت تعداد کاربران زیادی داشته باشد، مناسب نیست. زیرا این کار فشار زیادی بر روی CPU می آورد و باعث مختل شدن سرور خواهد شد. بنابراین هر روش جایی و هر نکته مکانی.

نده از crypto++ استفاده میکنم که فکر میکنم معروف ترین و حرفه ای ترین کتابخانهء رمزنگاری تحت سی++ باشه. خوشبختانه تونستم با mingw هم کامپایلش کنم و در یک برنامهء Qt تحت ویندوز ازش استفاده کنم.

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

(داریم؟)

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

[مهمان]

آبنبات شما فروم تکنوتاکس رو با فروم کاربران ساده ویندوز اشتباه نگرفتی ؟

[Folaani]

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

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

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

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

اگر لطف کنید و معرفی کنید که خوب است شاید به کار فردی آمد و شما را هم دعا کرد.

<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/PBKDF2">http://en.wikipedia.org/wiki/PBKDF2</a><!-- m -->
<!-- m --><a class="postlink" href="http://www.rsa.com/rsalabs/node.asp?id=2127">http://www.rsa.com/rsalabs/node.asp?id=2127</a><!-- m -->
البته من خودم هنوز از این الگوریتم استفاده نکردم. یخورده تنبلی کردم و پیاده سازیش رو باید در PHP هم مینوشتم (شاید هم موجود باشه).
نیاز به یک HMAC هم هست در PHP
بعد تازه الگوریتم های هش PHP فقط md5 و sha1 هست که احتمالا باید یا یک پیاده سازی تحت PHP از یک الگوریتم قویتر گیر بیارم یا خودم بنویسم.
چون ما اگر بخوایم مثلا در پیاده سازی PBKDF2 مثلا از md5 استفاده کنیم بنظرم زیاد جالب نباشه (اینکه آیا خود استاندارد الگوریتمهای خاصی رو معرفی کرده یا نه یادم نیست).

اگر اشتباه نکنم شما چند بار hash ساخته اید و آن را به هم متصل کرده اید. در نگاه اول که ایده بدی به نظر نمی آید. اما منظور من دقیقا این نبود.

پس منظورت چی بود؟

بعد از آن هم باید ببنید این روش شما در کجا استفاده می شود. مثلا اگر در قسمت ورود یک سایت برای ایجاد یک session جدید استفاده شود و این سایت تعداد کاربران زیادی داشته باشد، مناسب نیست. زیرا این کار فشار زیادی بر روی CPU می آورد و باعث مختل شدن سرور خواهد شد. بنابراین هر روش جایی و هر نکته مکانی.

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

خوش به حالتان زیرا من فقط یک برنامه را توانستم با mingw و QT در ویندوز کامپایل و اجرا کنم و در سایر موارد به مشکلات آنچنانی که پوست از سر هر برنامه نویسی می کند برخورد کردم.

چه مشکلاتی؟! بگید شاید بتونم حل کنم.
منکه هیچ مشکلی نداشتم. نسخه های جدید Qt SDK هم مجهز به امکان انجام تمامی کار در محیط برنامه نویسی ویژوالش هستن که کار رو برای همهء افراد راحتتر کرده (البته من همچنان مستقیما با خط فرمان کار میکنم).
البته اگر شما بخواید از کتابخانه های غیر کیوت در برنامهء خودتون استفاده کنید بحثش فرق میکنه خب! چون اون کتابخانه ها هم باید با mingw کامپایل شده باشن (که در اکثر موارد اینطور نیست، بخصوص درمورد کتابخانه های مختص ویندوز). البته یک راه حل کلی برای این مسئله وجود داره و اونم اینه که از ابتدا خود کیوت رو خودتون با MSVC کامپایل کنید (ولی بنده شخصا تاحالا مجبور نشدم و انجام ندادم). اونی که دانلود میکنید و نسخهء اوپن سورس کیوت هست با mingw کامپایل شده.

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

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

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

هفته نامهء شما چیه؟

این موضوع جالب است اما بدون داشتن راهنما (از نوع انسانی) یا یک مغز فعال و بی دغدغه اصلا کار جالبی نیست.

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

[kakilik]

بعد تازه الگوریتم های هش PHP فقط md5 و sha1 هست که احتمالا باید یا یک پیاده سازی تحت PHP از یک الگوریتم قویتر گیر بیارم یا خودم بنویسم.

php بیش از سی الگوریتم hash رو ساپورت می‌کنه. اینها رو ببینید:
<!-- m --><a class="postlink" href="http://www.php.net/manual/en/function.hash.php">http://www.php.net/manual/en/function.hash.php</a><!-- m -->
<!-- m --><a class="postlink" href="http://www.php.net/manual/en/function.hash-algos.php">http://www.php.net/manual/en/function.hash-algos.php</a><!-- m -->

[Folaani]

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

[kakilik]

روی هاستی که من دارم php 5.2.9 وجود داره. فکر کنم دیگه همه‌ی هاست‌ها php5 داشته باشند.
تابع hash هیچ dependency نداره و پیش‌فرض در php فعاله.
در ضمن لیست کامل اکستنشن‌های استاندارد کریپتوگرافی php را در اینجا ببینید:
<!-- m --><a class="postlink" href="http://www.php.net/manual/en/refs.crypto.php">http://www.php.net/manual/en/refs.crypto.php</a><!-- m -->

[آبنبات]

رمزنگاری مقولهء حساسی هست. و این الگوریتم از نظر خبره های اینکار Broken هست.

من هنوز هیچ منبعی که به طور کلی این الگوریتم را زیر سوال ببرد ندیده ام. اما به طور کلی هر الگوریتم رمزنگاری یک به یک با روش brute force قابل شکستن است و تنها مسئله در آن ها زمان شکسته شدن است. مثلا یک الگوریتم با یک CPU معمولی در یک ساعت و یک الگوریتم با هزار CPU زنجیر شده در عرض 10 سال.

تقریبا هیچکس در سراسر جهان محتمل نیست بتونه اون رو بشکنه

چنین چیزی در مورد الگوریتم های یک به یک قابل پیاده سازی نیست حتی اگر الگوریتم بازگشت ناپذیر باشد زیرا روش brute force وجود دارد.

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

خیالتان راحت باشد. اگر از کلید های هشت حرفی بدون معنی برای انسان و با حروف ترکیبی استفاده کنید، با سخت افزار معمول به سادگی شکستنی نیست.

اما برای کاربردهای حساس الگوریتم ها از اینهم پیچیده تر شدن و نمک که چه عرض کنم بجز نمک فلفل هم بهش میزنن

مسلما

<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/PBKDF2">http://en.wikipedia.org/wiki/PBKDF2</a><!-- m -->
<!-- m --><a class="postlink" href="http://www.rsa.com/rsalabs/node.asp?id=2127">http://www.rsa.com/rsalabs/node.asp?id=2127</a><!-- m -->

خدا خیرتان دهد. من که به دلیل مشغله زیاد نتوانستم همه را مطالعه کنم اما شاید به کار یک نفر بیاید.

پس منظورت چی بود؟

ایده اولیه ای که به ذهن من رسید این بود که یک کانتینر به اندازه مورد نظر خودتان ایجاد کنید و hash را در آن قرار دهید و مابقی آن را با الگوریتم ابداعی خودتان پرکنید. مثلا می توانید بیت های کنترلی را در آن قرار دهید. یا hash را تکه تکه کنید و در میان آن بیت های رمز شده قرار دهید. در واقع شاید بتوان نام آن را حجیم سازی گذارد.

نه برآورد شما اشتباه هست.

من مطلبی مستند را سه سال پیش در این مورد خواندم که در مورد MD5 یک کار مستند انجام داده بود. عملیات رمزنگاری و از رمز خارج کردن از آن دسته عملیات هایی است که بر پایه استفاده از CPU است و بنا بر الگوریتم میزان این مصرف متغییر است. اما زیاد سخت نیست. یک برنامه با حداقل هزار ریسمان بنویسید که ریسمان ها همزمان آغاز شوند و یک عملیات رمزنگاری MD5 را انجام دهد و مصرف CPU را ثبت کنید.

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

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

(از نظر وقت و انرژی برنامه نویسی صرف نداره و درست هم نیست چیزهای دیگری رو فدای بهینه سازیهایی بکنیم که در عمل تاثیر مشهودی نخواهند داشت).

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

چه مشکلاتی؟! بگید شاید بتونم حل کنم.

من مدتی پیش با آن کار کردم و در حال حاضر مشکلات را دقیق به خاطر ندارم و مطرح کردن آن هم در اینجا باعث انحراف از موضوع می شود

نسخه های جدید Qt SDK هم مجهز به امکان انجام تمامی کار در محیط برنامه نویسی ویژوالش هستن که کار رو برای همهء افراد راحتتر کرده

بله. نسخه های جدیدتر آن بسیار user friendly تر نسبت به گذشته شده اند.

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

بله با این حرف شما کاملا موافقم. من هم به دلیل همین مستقل از پلتفرم بودنش سراغ آن رفتم. اما اینکه گفتم به کسی توصیه نمی کنم منظورم استفاده از آن برای توسعه برنامه های ویندوزی بود. با تجربه ای که کسب کرده ام توسعه برنامه های ویندوزی با زبان های بومی ویندوز راحت تر و بی دردسر تر خواهد بود و حجم برنامه نهایی منتقل شده به کاربر هم کمتر خواهد بود زیرا نیازی نیست کتابخانه های لازم را هم منتقل کنید. مثال برای نوشتن برنامه های گرافیکی در QT باید dll های بزرگی را جابه جا کنید که برنامه را مناسب دانلود از طریق اینترنت نمی کند. اما نکته دیگری که متوجه شدم این است که می توان کامپایلر را به MVC تغییر داد که با این کار توانستم برنامه را کامپایل کنم اما مشکلاتی با برنامه هایی که دارای cmake بودن داشتم و در واقع کامپایل کردن برنامه های لینوکسی در ویندوز.

هفته نامهء شما چیه؟

<!-- m --><a class="postlink" href="http://www.abnabatmag.com">http://www.abnabatmag.com</a><!-- m -->
این هم لینک کتاب مذبور
<!-- m --><a class="postlink" href="http://www.cacr.math.uwaterloo.ca/hac/index.html">http://www.cacr.math.uwaterloo.ca/hac/index.html</a><!-- m -->

اطلاعات خوبی در دسترس هست. ویکیپیدا هم مقاله های خوبی داره.
منظور شما از راهنمای انسانی چیه؟
کلاس خصوصی که نمیخواد!!

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

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

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

به هر حال از اینکه به دور از خود بزرگ بینی، محتوای فارسی خوب تولید کردید و باعث کمک به همنوعان خود شدید از شما تشکر می کنم. +1

[Folaani]

من هنوز هیچ منبعی که به طور کلی این الگوریتم را زیر سوال ببرد ندیده ام. اما به طور کلی هر الگوریتم رمزنگاری یک به یک با روش brute force قابل شکستن است و تنها مسئله در آن ها زمان شکسته شدن است. مثلا یک الگوریتم با یک CPU معمولی در یک ساعت و یک الگوریتم با هزار CPU زنجیر شده در عرض 10 سال.

خب حتما مطالعه نکردید که ندیدید!
الان دیگه در هر مقاله ای اینطور چیزها رو نوشته.
دیگه هیچ مرجع معتبری در پیاده سازیهای جدید از md5 استفاده نمیکنه.
شاید بدونید از نظر عملی تا اینجا پیش رفتن که تونستن گواهینامهء دیجیتال یکی از شرکتهای معروف رو با استفاده از آسیب پذیری md5 جعل کنن (فکر کنم مربوط به پلی استیشن سونی).
[ltr]
Later that year, MD5's designer Ron Rivest wrote, "md5 and sha1 are both clearly broken (in terms of collision-resistance),"[16] and RSA Laboratories wrote that "[n]ext-generation products will need to move to new algorithms."
[/ltr]
<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/Md5">http://en.wikipedia.org/wiki/Md5</a><!-- m -->

چنین چیزی در مورد الگوریتم های یک به یک قابل پیاده سازی نیست حتی اگر الگوریتم بازگشت ناپذیر باشد زیرا روش brute force وجود دارد.

از نظر تئوریک فقط one time pad کاملا امن هست.
اما الگوریتمهای قوی موجود چون وقتی به روش brute force شکسته میشن که دیگه خیلی دیر شده (مثلا بعد از 200 سال چه اهمیتی داره که رمز شما شکسته بشه؟) بنابراین امن محسوب میشن. مسلما در این محاسبات سرعت رشد قدرت پردازش بشر هم بحساب آمده.

خیالتان راحت باشد. اگر از کلید های هشت حرفی بدون معنی برای انسان و با حروف ترکیبی استفاده کنید، با سخت افزار معمول به سادگی شکستنی نیست.

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

ایده اولیه ای که به ذهن من رسید این بود که یک کانتینر به اندازه مورد نظر خودتان ایجاد کنید و hash را در آن قرار دهید و مابقی آن را با الگوریتم ابداعی خودتان پرکنید. مثلا می توانید بیت های کنترلی را در آن قرار دهید. یا hash را تکه تکه کنید و در میان آن بیت های رمز شده قرار دهید. در واقع شاید بتوان نام آن را حجیم سازی گذارد.

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

من مطلبی مستند را سه سال پیش در این مورد خواندم که در مورد MD5 یک کار مستند انجام داده بود. عملیات رمزنگاری و از رمز خارج کردن از آن دسته عملیات هایی است که بر پایه استفاده از CPU است و بنا بر الگوریتم میزان این مصرف متغییر است. اما زیاد سخت نیست. یک برنامه با حداقل هزار ریسمان بنویسید که ریسمان ها همزمان آغاز شوند و یک عملیات رمزنگاری MD5 را انجام دهد و مصرف CPU را ثبت کنید.

ببین دوست عزیز؛ اگر چیزی داری همینجا ارائه کن و ما رو دنبال نخود سیاه نفرست.
بنده میدونم دارم چی میگم و اینها حاصل تجربیات و مطالعات زیاد هست و مبناش رو بعضی از معروف ترین و قدیمی ترین و ماهرترین برنامه نویسان دنیا تایید کردن و اصولا از توصیه های خودشون خیلی از این مسائل رو یاد گرفتم یا استنباط کردم. حتی این مسائل در برنامه نویسی اسمبلی هم مطرح شده، چه برسه به زبانها و اپلیکیشن های سطح بالا.
امروز خیلی جاها حتی خوانایی کد به بهینه سازی های جزیی اولویت داره. بعد شما انتظار داری بیایم مثلا از فلان الگوریتم برای رمزنگاری استفاده نکنیم چون چند بار از تابع md5 بصورت تودرتو استفاده میکنه. تازه اصلا بدون این روشها امنیت ما ممکنه شدیدا خدشه دار بشه.
اون روش استانداردی رو که رفرنسش رو معرفی کردم اگر میخوندی عملیاتی پیچیده تر از اونی که من گفتم رو توصیه کرده و گفته باید مثلا حداقل 1000 بار تکرار کنیم تا امنیت هرچه بیشتر بالا بره؛ چون یک کرکر هم اینطور مجبور میشه برای هر نوع نفوذ و عملیات brute force همین کار رو انجام بده و این قدرت پردازشی مورد نیازش رو هزار برابر میکنه! (که عملا براش غیرممکنه) بعد شما روش یک خطی بنده رو میفرمایید بهینه نیست و نباید استفاده کنیم؟! واقعا حرفهایی میزنیدا!!
شما اگر میخواید برنامه هاتون هرچه بیشتر بهینه باشن چرا مثلا نمیایید همهء برنامه ها رو با سی یا اسمبلی بنویسید؟ چرا مثلا در وب از PHP استفاده میکنیم؟ میدونید خود این لایهء انتزاع و سیستم که مفسر داره با اونهمه امکانات و انعطاف و راحتی برنامه نویسی سطح بالا، خودش چقدر منابع و پردازش از سیستم مصرف میکنه؟ بنظرم خیلی بیشتر از چند الگوریتم جزیی که چندجا و برای مدت خیلی محدودی بکار میرن تاثیر داره.
یک تعادلی و روش استدلال منطقی وجود داره که باید تمام پارامترها رو درنظر بگیره. نه اینکه فقط کدام الگوریتم مثلا چند برابر دیگری سرعت داره یا کمتر منابع مصرف میکنه. گاهی حتی 1000 برابر سرعت کمتر و مصرف منابع بیشتر هم درمقابل پارامترهای دیگه اصلا بحساب نمیاد چون اولویت های مهمی وجود دارن و ضریب های بالایی برای بقیهء پارامترها. ضمنا 1000 گرم هزار برابر 1 گرم هست، اما بازم شما میتونید 1000 گرم رو براحتی بلند کنید یا اتومبیل شما میتونه این بار اضافه رو تحمل کنه. در اکثر جاها هم قدرت پردازشی و منابع لازم و محدودیت های بار برای الگوریتم های مختلف وجود دارن و ضمنا برنامهء ما فقط از اون الگوریتم خاص تشکیل نشده و مدام اون الگوریتم رو اجرا نمیکنه و بنابراین سنگین ترین قسمتش یا بقول معروف bottleneck که کارایی برنامه رو در کل محدود میکنه اصلا در اونجا نیست که بهینه سازی ما اثر چندانی روش داشته باشه. مطمئن باش خیلی قبل از اینکه برنامهء شما بخواد به جایی برسه که پردازش تابع md5 مشکل ایجاد کنه سیستم از منابع دیگه و الگوریتم های دیگری کم میاره. تازه شما مسئله رو خیلی بزرگ کردی. در بیشتر کاربردها اینطور عملیات فقط در زمان و مکانهای خیلی محدود و کوچکی درمقابل کل یک سیستم صورت میگیرن.

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

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

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

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

من مدتی پیش با آن کار کردم و در حال حاضر مشکلات را دقیق به خاطر ندارم و مطرح کردن آن هم در اینجا باعث انحراف از موضوع می شود

بهرحال بنده در خدمتتون هستم اگر خواستید جای دیگه یا به روش دیگه تماس بگیرید.

بله با این حرف شما کاملا موافقم. من هم به دلیل همین مستقل از پلتفرم بودنش سراغ آن رفتم. اما اینکه گفتم به کسی توصیه نمی کنم منظورم استفاده از آن برای توسعه برنامه های ویندوزی بود. با تجربه ای که کسب کرده ام توسعه برنامه های ویندوزی با زبان های بومی ویندوز راحت تر و بی دردسر تر خواهد بود و حجم برنامه نهایی منتقل شده به کاربر هم کمتر خواهد بود زیرا نیازی نیست کتابخانه های لازم را هم منتقل کنید. مثال برای نوشتن برنامه های گرافیکی در QT باید dll های بزرگی را جابه جا کنید که برنامه را مناسب دانلود از طریق اینترنت نمی کند. اما نکته دیگری که متوجه شدم این است که می توان کامپایلر را به MVC تغییر داد که با این کار توانستم برنامه را کامپایل کنم اما مشکلاتی با برنامه هایی که دارای cmake بودن داشتم و در واقع کامپایل کردن برنامه های لینوکسی در ویندوز.

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

<!-- m --><a class="postlink" href="http://www.abnabatmag.com">http://www.abnabatmag.com</a><!-- m -->
این هم لینک کتاب مذبور
<!-- m --><a class="postlink" href="http://www.cacr.math.uwaterloo.ca/hac/index.html">http://www.cacr.math.uwaterloo.ca/hac/index.html</a><!-- m -->

متشکرم؛ حتما سر میزنم.

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

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

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

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

به هر حال از اینکه به دور از خود بزرگ بینی، محتوای فارسی خوب تولید کردید و باعث کمک به همنوعان خود شدید از شما تشکر می کنم.

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

[آبنبات]

ظاهرا هر بار نوشته های ما دار حال بزرگتر شدن هستند پس اگر اجازه دهید این بار خلاصه تر بحث کنم تا خوانندگان هم راحتر بحث را دنبال کنند.

خب حتما مطالعه نکردید که ندیدید!
الان دیگه در هر مقاله ای اینطور چیزها رو نوشته.

بله. آخرین باری که در مورد MD5 تحقیق کردم مروبط به سه سال پیش بود و می خواستم خودم MD5 را پیاده سازی کنم.

دیگه هیچ مرجع معتبری در پیاده سازیهای جدید از md5 استفاده نمیکنه.

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

<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/Md5">http://en.wikipedia.org/wiki/Md5</a><!-- m -->

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

از نظر تئوریک فقط one time pad کاملا امن هست.

هر الگوریتم جایی دارد. مثلا شما نمی توانید برای کاربران انجمن یک وب سایت که تعدادشان هم بسیار زیاد است از این روش استفاده کنید. این کار بدرد بانکداری الکترونیک می خورد.

اما الگوریتمهای قوی موجود چون وقتی به روش brute force شکسته میشن که دیگه خیلی دیر شده (مثلا بعد از 200 سال چه اهمیتی داره که رمز شما شکسته بشه؟) بنابراین امن محسوب میشن. مسلما در این محاسبات سرعت رشد قدرت پردازش بشر هم بحساب آمده.

بنده هم خدمت شما عرض کردم که خیالتان راحت باشد.

البته جسارت نباشه ولی این نکته رو یادآوری کنم که بصورت تخصصی در مبحث رمزنگاری وقتی از کلید صحبت میکنیم، منظور کلید درونی تولید شدهء الگوریتم هست که مثلا 128 بیت 256 بیت 1024 بیت (درمورد الگوریتمهای asymmetric) و غیره هست (واحد بیت هست و با چنین طولهایی). اما وقتی میگیم پسورد یا passphrase، منظور ورودی کاربر هست.

بله دقیقا حرف شما صحیح است. این را به حساب مشغله کاری من بگذارید که فرصت کافی برای تمرکز نداشتم و گرنه به مسئله ای که گفتید آگاه هستم و بابت دقت شما تشکر می کنم.

بنده میدونم دارم چی میگم و اینها حاصل تجربیات و مطالعات زیاد هست و مبناش رو بعضی از معروف ترین و قدیمی ترین و ماهرترین برنامه نویسان دنیا تایید کردن و اصولا از توصیه های خودشون خیلی از این مسائل رو یاد گرفتم یا استنباط کردم. حتی این مسائل در برنامه نویسی اسمبلی هم مطرح شده، چه برسه به زبانها و اپلیکیشن های سطح بالا.
امروز خیلی جاها حتی خوانایی کد به بهینه سازی های جزیی اولویت داره. بعد شما انتظار داری بیایم مثلا از فلان الگوریتم برای رمزنگاری استفاده نکنیم چون چند بار از تابع md5 بصورت تودرتو استفاده میکنه. تازه اصلا بدون این روشها امنیت ما ممکنه شدیدا خدشه دار بشه.
اون روش استانداردی رو که رفرنسش رو معرفی کردم اگر میخوندی عملیاتی پیچیده تر از اونی که من گفتم رو توصیه کرده و گفته باید مثلا حداقل 1000 بار تکرار کنیم تا امنیت هرچه بیشتر بالا بره؛ چون یک کرکر هم اینطور مجبور میشه برای هر نوع نفوذ و عملیات brute force همین کار رو انجام بده و این قدرت پردازشی مورد نیازش رو هزار برابر میکنه! (که عملا براش غیرممکنه) بعد شما روش یک خطی بنده رو میفرمایید بهینه نیست و نباید استفاده کنیم؟! واقعا حرفهایی میزنیدا!!
شما اگر میخواید برنامه هاتون هرچه بیشتر بهینه باشن چرا مثلا نمیایید همهء برنامه ها رو با سی یا اسمبلی بنویسید؟ چرا مثلا در وب از PHP استفاده میکنیم؟ میدونید خود این لایهء انتزاع و سیستم که مفسر داره با اونهمه امکانات و انعطاف و راحتی برنامه نویسی سطح بالا، خودش چقدر منابع و پردازش از سیستم مصرف میکنه؟ بنظرم خیلی بیشتر از چند الگوریتم جزیی که چندجا و برای مدت خیلی محدودی بکار میرن تاثیر داره.
یک تعادلی و روش استدلال منطقی وجود داره که باید تمام پارامترها رو درنظر بگیره. نه اینکه فقط کدام الگوریتم مثلا چند برابر دیگری سرعت داره یا کمتر منابع مصرف میکنه. گاهی حتی 1000 برابر سرعت کمتر و مصرف منابع بیشتر هم درمقابل پارامترهای دیگه اصلا بحساب نمیاد چون اولویت های مهمی وجود دارن و ضریب های بالایی برای بقیهء پارامترها. ضمنا 1000 گرم هزار برابر 1 گرم هست، اما بازم شما میتونید 1000 گرم رو براحتی بلند کنید یا اتومبیل شما میتونه این بار اضافه رو تحمل کنه. در اکثر جاها هم قدرت پردازشی و منابع لازم و محدودیت های بار برای الگوریتم های مختلف وجود دارن و ضمنا برنامهء ما فقط از اون الگوریتم خاص تشکیل نشده و مدام اون الگوریتم رو اجرا نمیکنه و بنابراین سنگین ترین قسمتش یا بقول معروف bottleneck که کارایی برنامه رو در کل محدود میکنه اصلا در اونجا نیست که بهینه سازی ما اثر چندانی روش داشته باشه. مطمئن باش خیلی قبل از اینکه برنامهء شما بخواد به جایی برسه که پردازش تابع md5 مشکل ایجاد کنه سیستم از منابع دیگه و الگوریتم های دیگری کم میاره. تازه شما مسئله رو خیلی بزرگ کردی. در بیشتر کاربردها اینطور عملیات فقط در زمان و مکانهای خیلی محدود و کوچکی درمقابل کل یک سیستم صورت میگیرن.

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

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

باید تعادل در یک سیستم عملی بررسی شود.

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

مسلما در هر شرایطی راه حل هم متفاوت خواهد بود اما راه رستگاری تعادل، تعادل، تعادل.

حتما سر میزنم.

یادتان نرود که نظرتان را هم ایمیل کنید.

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

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

اشتباه خودتون رو بپذیرید

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

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

با نظر شما موافقم. به هر حال مدتی بود مطالب مربوط به رمزنگاری در ذهن من زیر رو نشده بود. باز هم متشکرم.

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

چرا روی منابع بخش خصوصی حساب نمی کنید.

[Folaani]

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

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

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

باید تعادل در یک سیستم عملی بررسی شود.

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

یادتان نرود که نظرتان را هم ایمیل کنید.

همان موقع داشتم مجله تان را با دایالاپ دانلود میکردم. حجم دانلود شده به 7 8 مگابایت رسیده بود ولی حجم کل را نشان نمیداد (ظاهرا سرورتان به علتی مقدار حجم کلی را ارسال نمیکند) و بنده هم کنسلش کردم. فکر نمیکردم اینقدر حجیم باشد.

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

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

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

در بالا توضیح دادم اما بازهم میگویم.

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

آیا شما با این اصول مخالفت دارید؟

چرا روی منابع بخش خصوصی حساب نمی کنید.

دقیقا چه منابعی و چطور؟

---------------------------------------

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

[Folaani]

داشتم فصل 10 کتاب Handbook of Applied Cryptography رو میخوندم که به یک مطلب جالب برخوردم.
به این تصویر که از بخشی از کتاب گرفتم نگاه کنید: <!-- m --><a class="postlink" href="http://www.fastuploader.com/images/hashcrack.png">http://www.fastuploader.com/images/hashcrack.png</a><!-- m -->
این کتاب قدیمی هست و با توجه به اعدادی که قبلا دربارهء سرعت متداول CPU ها توش دیدم حدس میزنم باید زمانها رو چند ده بار کاهش بدیم! البته از طرف دیگه میتونیم پیچیده تر بودن الگوریتم های استاندارد امروزی برای هش کردن رو در مقایسه با UNIX crypt به این برآوردها اضافه کنیم، ولی بازم فکر میکنم سرعت پردازش نهایی روی سیستم های امروزی حداقل 10 برابر شده باشه.

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

مورد دیگه:
فرض کنید یک پسورد داریم که از حروف کوچک و اعداد تشکیل شده، که مورد خیلی متداولی هست.
در این صورت کرک کردن هش این پسورد با استفاده از یک سیستم معمولی امروزی با کار 24 ساعته حدودا 2 سال زمان میبره.
با استفاده از یک شبکهء کرک اینترنتی این زمان میتونه حداقل مثلا 700 برابر کمتر بشه؛ یعنی حدود 1 روز!
و شاید برآورد من از قدرت این شبکه ها خیلی کمتر از میزان واقعی بوده باشه.
بهرحال به دقت بالایی نیاز نیست؛ هدف این بود که ببینیم امنیت پسوردهایی حتی با 8 کاراکتر متشکل از حروف و اعداد (البته فقط حروف کوچک) چقدر پایین هست.

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

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

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