رمزنگاری/6-تقسیم‌بندی الگوریتم‌های رمزنگاری

پست قبلی: الگوریتم های سزار و اِنیگما

در پست های قبلی این مجموعه، ابتدا با الگوریتم‌های درهم‌نگاری(Hash) و الگوریتم‌های Encoding/Decoding آشنا شدیم، تفاوت آن‌ها را با الگوریتم های رمزنگاری (Encryption/Decryption) بررسی کردیم و در نهایت پس از بررسی مقدمات توسعه‌ی رمزنگاری و علل نیاز به آن، در این پست قرار است به تقسیم‌بندی های الگورتیم های رمزنگاری امروزی بپردازیم.

واژگان رمزنگاری:

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

• Plain Text: متن رمز نشده ای که قرار است برای رمزشدن به تابع Encryption وارد شود و همچنین متن رمزنشده ای از تابع Decryption بازگردانده می‌شود.
• Cipher Text: متن رمز شده ای که از تابع Encryption بازگردانده می‌شود و همچنین متن رمزشده ای که برای خارج شدن از رمز به تابع Decryption وارد می‌شود. 
• Cipher: الگوریتمی که برای Encrypt یا Decrypt استفاده می‌شود. با این تعریف، در بعضی موارد از Encipher و Decipher به ترتیب به جای Encoding و Decoding استفاده می‌شود.
• Key: یک اطلاعات محرمانه که فقط و فقط فرستنده و گیرنده‌ی پیام رمز شده از آن اطلاع دارند. Cipher از این کلید، برای انجام عملیات Encrypt و/یا Decrypt استفاده می‌کند.
•  Cryptanalysis: به مطالعات و فعالیت هایی که روی یک الگوریتم رمزنگاری یا داده‌های آن انجام می‌شود تا به واسطه‌ی آنها امکان استخراج کلید رمزنگاری از داده های در دسترس یا امکان استخراج داده‌های رمزنشده بدون داشتن کلید، بررسی شود. نام دیگر این فیلد Codebreaking می‌باشد.
• Salt, Nonce, Initial Vector: در پست‌های بعدی!

و اما تقسیم بندی:

 الگوریتم‌های رمزنگاری را می‌توان از چند بُعد تقسیم‌بندی کرد که مهمترین این ابعاد یکی تعداد کلیدهای لازم برای یکبار رمزکردن و خارج کردن از رمز و دیگری نوع پردازش شدن Plaintext در تابع Encrypt است.  

• تقسیم بر اساس تعداد کلیدهای لازم:

فرایند رمزکردن یک Plaintext و خارج کردن آن از رمز، روندی طبق شکل زیر دارد:

حال، با توجه به ماهیت الگوریتم، ممکن از مقدار  Encryption Key با مقدار Decryption Key برابر باشد یا متفاوت از همدیگر باشند. الگوریتم‌هایی که مقدار این دو کلید با همدیگر یکسان است را Secret Key Algorithm یا Symmetric Algorithm یا Single Key Algorithm یا Conventional Algorithm الگوریتم‌های متقارن می‌نامیم و الگوریتم‌هایی که در آن‌ها مقدار کلیدها از همدیگر متمایز است را Public Key Algorithm یا Asymmetric Algorithm یا Two Key Algorithm یا الگوریتم های نامتقارن می‌نامیم. (از آنجا که روند کار الگوریتم‌های نامتقارن ممکن است [به خاطر تفاوت کلیدها] در ذهن غیرممکن به نظر برسد، در پست‌های بعدی احتمالا نمونه ای از این الگوریتم‌ها را با هم به صورت جزیی‌تر بررسی خواهیم کرد).

• تقسیم‌ بر اساس نوع پردازش Plaintext:

در بعضی از الگوریتم‌های رمزنگاری، طول پیامی که قرار است رمزشود، حتما باید مضرب صحیحی از یک عدد طبیعی خاص بزرگتر از یک باشد. به عنوان مثال طول پیام ورودی باید مضربی از 16 بایت باشد. به این نوع الگوریتم‌های رمزنگاری، Block Cipher می‌گویند و آن عدد طبیعی خاص بزرگتر از یک Block Size نامیده می‌شود. مشخصا هنگامی که قرار است با استفاده از این نوع الگوریتمها پیامی را رمز کنیم که طول آن مضرب صحیحی از طول Block نیست، ناچاریم که تا رسیدن به طول لازم به آن داده اضافه کنیم. مکان و نوع داده‌ای که به پیام اضافه می‌شود می‌تواند دلخواه باشد، لیکن، برای سهولت امر و برای این که گیرنده‌ی Ciphertext بتواند به سادگی پیام را از داده‌ی اضافه شده تمییز دهد، استانداردهای مختلفی ارائه شده است که خود به خود به انتهای پیام، مقداری را اضافه می‌کنند. به عمل اضافه کردن داده‌ به پیام تا رسیدن به طول طول مجاز، Padding می‌گویند. در مقابل این نوع الگوریتم‌ها، نوع دیگری از الگورتیم‌های رمزنگاری را داریم که طول پیام هر‌ مقدار دلخواهی می‌تواند باشد، به این نوع الگوریتم‌ها که در اقلیت هستند، Stream Cipher می‌گویند.

مقایسه الگوریتم‌های متقارن و نامتقارن:

ممکن این سوال برای خواننده پیش بیاید که کاربرد هر کدام از این دو نوع الگوریتم در چه مواقعی است و آیا مزیتی از نظر امنیتی به یکدیگر دارند؟

در پاسخ به این سوال ابتدا روند استفاده از الگوریتم‌های نامتقارن را بررسی می‌کنیم. گفتیم که در الگوریتم های نامتقارن،  Encryption Key  و Decryption Key با هم متفاوتند. نام این کلیدها Public Key و Private Key است. پیامی که با یکی از این دو کلید رمزشود، فقط و فقط با کلید دیگر از رمز خارج می‌شود و استفاده از مقدار دیگری جز کلید دوم، منجر به دریافت داده‌های چرند(:دی!) می‌شود. با توجه به این ساختار، هر موجودیتی باید یک جفت کلید برای خودش تولید کند و یکی را محرمانه نزد خود نگه دارد (Private Key) و دیگری را به شخصی که قصد دارد با اون ارتباط برقرار کند ارسال کند(Public Key). 

برای روشن شدن فرآیند، تصویر زیر را مشاهده کنید:

همانطور که در تصویر فوق می‌بینید، Alice در مرحله‌ی 1، یک جفت کلید تولید می‌کند و در مرحله‌ی 2، کلید عمومی خود را به Bob می‌دهد. سپس در مرحله‌ی 3، یک پیام که با کلید خصوصی خودش رمز شده است به باب ارسال می‌کند. از آنجا که این پیام با کلید خصوصی Alice رمز شده است، فقط و فقط با کلید عمومی او قابل رمزگشایی است[کلید عمومی را هر کسی می‌تواند با درخواست از Alice دریافت کند، بنابرین هر کسی می‌تواند این پیام را رمزگشایی کند]. Bob که کلید عمومی Alice را دارد، پیام او را از رمز خارج می کند، و در جواب به او، مجدد پیام خود را در مرحله‌ی 4 با کلید عمومی Alice رمز می‌کند. بدیهتا، از آنجا که پیام Bob با کلید عمومی Alice رمز شده است، تنها با کلید خصوصی Alice از رمز خارج می‌شود[و از آنجا که Alice کلید خصوصی اش را به هیچ کسی نمی‌دهد، فقط و فقط خودش قادر به رمزگشایی پیام Bob است]. در مرحله‌ی 6 هم Alice پیام Bob را با کلید خصوصی خودش از رمز خارج می‌کند.

دو نکته ای که باید متوجه آن شده باشید:

1. برای این که یک ارتباط دو طرفه‌ی کاملا امن بین Alice و Bob برقرار باشد، Bob هم باید یک جفت کلید تولید کند و کلید عمومی خودش را به Alice بدهد تا Alice به جای استفاده از کلید خصوصی خودش در مرحله‌ی 2، از کلید عمومی Bob استفاده کند(تا هیچکسی جز Bob قادر به رمزگشایی آن نباشد).
2. برخلاف الگوریتم‌های متقارن که در آنها لازم بود گیرنده و فرستنده از قبل به صورت مخفیانه با هم یک کلید را به اشتراک بگذارند، در الگوریتم‌های نامتقارن، برای این که Alice و Bob بتوانند یک پیام محرمانه به همدیگر ارسال کنید، نیازی به اشتراک گذاشتن کلید به صورت مخفیانه نیست، بلکه به صورت کاملا واضح، کلیدهای عمومی خود را به همدیگر ارسال میکنند و کسی با استفاده از آنها نمی‌تواند به داده های رمزشده دست پیدا کند، زیرا در یک ساختار صحیح از Public Key تنها برای رمزکردن (Encrypt) و از Private Key تنها برای رمزگشایی (Decrypt) استفاده می‌شود.

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

سوال: نهایتا کدام یک استفاده می‌شوند؟

جواب: هر دو! گذشته از این که ممکن است یک سیستم کلا استفاده از یکی را بر دیگری ترجیح دهد، روند متداول این است که ترکیبی از این دو استفاده می‌شود. به این صورت که در ابتدای ارتباط، از طریق الگوریتم‌های نامتقارن یک کلید متقارن(Secret Key) را یکی به دیگری ارسال می‌کند و پس از ارسال این کلید، روند رمزنگاری ارتباط به الگورتیم‌های متقارن Switch می‌کند. در واقع بعد از ارسال کلید متقارن که با رمزنگاری نامتقارن رمز شده است، مابقی ارتباط به صورت متقارن رمز می‌شود.

سوال: آیا صحیح است بگوییم الگوریتم‌های نامتقارن از الگوریتم‌های متقارن امنیت بیشتری دارند؟

جواب: خیر، امنیت یک الگوریتم رمزنگاری را ساختار الگورتیم آن (مشخص کننده ی زمان و تعداد کلیدهایی که باید امتحان شوند تا کلید رمزنگاری بدست آید)، طول کلید آن و نبود خطای منطقی(باگ) در الگوریتم آن تعیین می‌کنند. در واقع در صورتی که در ساختار یک الگوریتم متقارن و یک الگوریتم نامتقارن باگ وجود نداشته باشد، الگوریتمی امنیت بالاتری دارد که طول کلید آن بزرگتر باشد. از نگاه دیگر، همانقدر که محرمانه نگه داشتن Secret Key در الگوریتم متقارن اهمیت دارد، محرمانه نگه داشتن Private Key هم در الگوریتم نامتقارن اهمیت دارد.  در این مورد در پست های بعدی توضیحات کاملتری خواهیم داشت.

اصولی در مورد الگوریتم‌های رمزنگاری:

با گذشت زمان و پیدا شدن نقاط ضعف الگورتیم‌های اولیه، رفته رفته اصولی برای الگوریتم‌های رمزنگاری تدوین شد که در زیر به دو مورد اصلی آن‌ها اشاره می‌کنیم:

1. طول خروجی باید با طول ورودی الگوریتم برابر باشد (بر طبق اصل لانه‌ی کبوتری، خروجی نمی‌تواند از ورودی کوتاه تر باشد. بلندتر بودن خروجی هم مزیتی ندارد و لازم نیست)
2. فاش شدن الگوریتم نباید موجب شود Attacker بتواند داده‌های رمز شده را رمزگشایی کند؛ و به عبارت دیگر باید تنها مبتنی بر محرمانه نگه داشتن کلید باشد. (یکی از اصول کرکهافس).

سوال: Security via Obscurity چیست؟ 

جواب: به مخفی نگه داشتن الگوریتم رمزنگاری به منظور افزایش امنیت (مثلا با کاهش احتمال پیدا شدن ایراد منطقی در الگوریتم)، Security by Obscurity گفته می‌شود.

الگوریتم‌های رمزنگاری مشهور:

در زیر به چند مورد از الگوریتم‌های رمزنگاری متقارن و نامتقارن مشهور اشاره شده است. لازم به ذکر است که کدام از این‌ الگوریتم‌ها می‌توانند بر اساس طول کلید به زیر مجموعه‌هایی تقسیم شوند. به عنوان مثال برای الگوریتم RSA زیر مجموعه های RSA-512, RSA-1024 .... RSA-4096 مرسوم هستند و برای الگوریتم AES سه زیر مجموعه‌ی AES-192, AES-128و AES-256 را داریم (اندازه‌ی بلاک در هر سه مورد 128 بیت است). 

نامتقارن:

• RSA یا Rivest-Shamir-Adleman
• ECC یا Elliptic Curve Cryptography
• DH یا Diffie–Hellman
• ElGamal 

متقارن:

• DES یا Data Encryption Standard
• TDES یا 3DES یا Triple DES
• AES یا Advanced Encryption Standrad

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

قسمت بعدی: کاربرد و روند استفاده از امضای دیجیتال (به زودی)

---

بی مهری انسان معاصر در توست

تنهایی انسان نخستین در من ...

#میلاد_عرفان_پور

دنیای من برای دیدنِ دوباره‌ی یه دوست خیلی بزرگ و دست نیافتنی هست ولی برای دیدن دوباره‌ی آدم‌های نچسب، خیلی خیلی کوچیک ...

رمزنگاری/5-الگوریتم های Caesar و Enigma (سِزار و اِنیگما)

قسمت قبلی: معیارهای امنیت

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

الگوریتم سزار:

"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوه‌ی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب می‌خواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ... 

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

[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]

شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی

نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن می‌توان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.

ماشین Enigma:

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

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

قسمت بعدی: بررسی تقسیم بندی الگوریتم‌های رمزنگاری

---

دیدار تو گر صبح ابد هم دَهَدَم دست

من سرخوشم از لذتِِ این چشم به راهی ...

#فریدون_مشیری

رمزنگاری/4-معیارهای امنیت

قسمت قبلی: مشکلات مربوط به Encoding

تا پیش از این با Hash کردن و Encoding و Decoding آشنا شدیم و دانستیم که Hashing استفاده از تابعی است که یک طرفه می‌باشد و پس از Hash کردن داده ها قابلیت بازیابی مجدد آن‌ها را نداریم، و در مقابل دانستیم که Encoding و Decoding تابع هایی دو طرفه برای تغییر Form داده ها هستند؛ که برای استفاده از آن‌ها نیاز به چیزی تحت عنوان کلید یا رمز نیست و هر فردی که از الگوریتم مطلع باشد می‌تواند داده های Encode شده را با استفاده از تابع Decode به داده های اصلی تبدیل کند.(لازم به ذکر است که ماهیت Public بودن قریب به اتفاق الگوریتم های Encoding/Decoding باعث می‌شود همه بتوانند از آن‌ها استفاده کنند).

معیارهای امنیت:

 در این قسمت ابتدا یک سناریو تعریف می‌کنیم و سپس بر اساس آن، علت نیاز به الگوریتم‌هایی فراتر از الگوریتم‌های Hash و Encoding/Decoding را متوجه خواهیم شد و در خلال قسمت های بعدی روند توسعه‌ی این الگوریتم‌های مورد نیاز را توضیح می‌دهیم.

در این سناریو شما فرمانده ی یک سپاه جنگی هستید و به سبب لزوم نظارت بر اتفاقات خط نبردِ نیروهایتان و نیز مدیریت کارهای مملکتی، ناچارید که مدام بین میدان کارزار و مقرّ فرماندهی آمد و شد کنید(بگذارید حداقل در این داستان سناریو را طوری تعریف کنیم که گویا نعلین فرماندهان نیز گَرد خطوط نبرد را به شیارهای خود دیده است!). بنابرین شما نیاز دارید که گاهی از این مقر، به یکی از سربازان عالی‌رتبه‌ی خود که وِی را به عنوان جانشین بر مسند فرماندهی گمارده‌اید نامه ای ارسال کنید و او را در جریان کارهایی که باید انجام دهد قرار دهید. همچنین، فرمانده ی مذکور، باید گزارشاتی از عملکرد خودش و اوضاع به شما ارسال کند. پیش از این که ادامه‌ی داستان را تعریف کنیم، یک نام برای شما، و یک نام برای آن افسر عالی‌رتبه انتخاب می‌کنیم. نام شما Bob است، و نام آن افسر Alice (چرا تعجب کردید؟ یک افسر عالی‌رتبه نمی‌تواند خانم باشد؟).

سوال: چرا Bob و چرا Alice؟ 

پاسخ: آلیس و باب در واقع دو عضو از یک خانواده‌ی بزرگ هستند تحت عنوان خانواده‌ی کاراکترهای رمزنگاری! به صورت واضح تر، در سال 1978 یکی از اساتید دانشگاه MIT به نام رونالد ریوست، در مقاله ای که برای ارائه‌ی الگوریتم رمزنگاری RSA آماده کرده بود، از این اسامی برای مثال‌های خود به عنوان فرستنده و گیرنده‌ی پیام استفاده کرد. بعدها در دیگر سناریوهایی که طراحی شد، این اسامی شهرت یافتند و کم کم کاراکترهای دیگری هم به جمع آن‌ها پیوستند. برای رعایت این رسم، ما نیز در سناریوی خود همین کاراکترها را به کار می‌بریم. به عنوان یک مطلب اضافه، حرف R در الگوریتم RSA، از فامیل آقای Rivest گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.

دکتر ریوست (نفر وسط)

خب، تصمیم باب بر این شده است که در یک نامه، دستورات خود را به آلیس عزیزش در میدان نبرد ابلاغ کند.

اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر می‌گرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل می‌دهند]:

1. "باب" و "آلیس" باید به نحوی در نامه هایشان، خود را به گونه‌ای به یکدیگر معرفی کنند که هر کدام هنگام دریافت نامه‌ی دیگری بتواند مطمئن شود که نامه از جانب همان شخصی آمده است که باید بیاید. حتی در صورتی که نیروهای دشمن رونوشتی را که هفته‌ی پیش در کاروان‌سرای بین راه از نامه‌ی قاصد تهیه کردند جایگزین نامه‌ی امروز قاصد کنند، دریافت کننده باید متوجه معتبر نبودن آن بشود. [بعد ها این بند را با نام Authenticity خواهید شناخت]
2. در صورتی که نیروهای دشمن در میانه‌ی مسیر قاصد را تطمیع کردند یا به قتل رساندند و به دستوراتِ "باب" یا گزارشِ "آلیس" دست یافتند، نباید از آن چیزی متوجه شوند! [بعد ها این بند را با نام Confidentiality خواهید شناخت]
3. در صورتی که نیروهای دشمن در کاروان سراهای میان راه کمین کردند و نامه‌ اصلیِ قاصد را دزدیدند و محتوای آن را عوض کردند یا نامه‌ی جدیدی که خودشان نوشته اند جایگزین آن کردند، دریافت کننده‌ی نامه‌ی جدید باید متوجه جعلی بودن آن بشود. [بعد ها این بند را با نام Integrity خواهید شناخت]
4. چنانچه "باب" دستوری به آلیس فرستاد و مثلا به وی فرمانِ "حمله" داد و آلیس بعد از خواندن دستور، به خاطر ترس یا ... به آن عمل نکرد، بعدها نباید بتواند ادعا کند که نامه را دریافت نکرده است! همینطور اگر "باب" در موقیعت مشابهی، مثلا در حالت مستی، تصمیم اشتباهی گرفت و فرمانی صادر کرد و به آلیس فرستاد و اجرای آن تصمیمِ اشتباه منجر به اتفاق بدی شد که آبروی "باب" را به خطر می‌انداخت، وی نباید قادر به این باشد که ارسال آن دستور را انکار کند. [بعد ها این بند را با نام Non-Repdiation خواهید شناخت]
5. قاصد و اسب پر انرژی اش همیشه باید در دسترس "باب" و آلیس باشد. [بعد ها این بند را با نام Availability خواهید شناخت]

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

قسمت بعدی: الگوریتم‌های سزار/Caesar و اِنیگما/Enigma

---

To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.

Ralph Waldo Emerson

رمزنگاری-مقدمه/3-حل مشکلات مرتبط با Encoding

قسمت قبلی: انکدینگ و دیکدینگ

طبق قرار پیشین، به عنوانِ ادامه‌ی مبحث اِنکدینگ و دیکدینگ (پیش زمینه ای بر مباحث رمزنگاری)، در این پست دو مشکلی را بررسی می‌کنیم که با احتمال زیاد تابحال حداقل یکبار با آن‌ها مواجه شده اید و با Encoding ارتباط مستقیم دارند:

مشکل اول: زیرنویس های خرچنگ قورباغه و ناخوانا

 گاها، بعد از دانلود کردن زیرنویس فارسی یک فیلم و افزودن آن به Player، به جای حروف فارسی، با تصویری مشابه زیر مواجه می‌شویم:

علت مواجه شدن با این خطوط ناخوانا، تنظیم نبودن Encoding محتوای فایل زیرنویس روی Encoding مناسب حروف فارسی است. برای رفع این مشکل چند راهکار ساده وجود دارد که در این پست با سه مورد آنها آشنا می‌شوید. 

راهکار اول: (موقتی)

نرم افزار Microsoft Office Word را باز کنید و از منوی File و سپس Open فایل زیرنویس دانلود شده را داخل آن Import کنید. بلافاصله بعد از کلیک کردن روی دکمه ی Open برای باز شدن فایل در نرم افزار Word پنجره ای مشابه زیر باز خواهد شد که باید از منوی سمت راست گزینه ی Unicode  UTF-8 را انتخاب کنید (معمولا به صورت اتوماتیک این کار انجام شده است و شما در کادر بزرگ پایین، متن فارسی را به صورت درست مشاهده می‌کنید؛ در ایصورت حتی اگر Encoding چیزی مغایر با آنچه که گفتیم بود، به آن دست نزنید) و کلید OK را بزنید:

پس از کلیک روی OK محتوای زیرنویس به صورت خوانا داخل Microsoft Word باز می‌شود. کاری که لازم است در این مرحله انجام دهید این است که از منوی File گزینه‌ی Save As را انتخاب کنید و سپس این محتوا را به صورت یک فایل با پسوند txt. ذخیره کنید. در نهایت، فایل جدید را با موس به داخل Player بکشید تا تصویری مشابه زیر داشته باشید:

راهکار دوم: (موقتی)

در این روش که مشابه روش پیشین است، به جای استفاده از نرم افزار Microsoft Word از نرم افزاری به نام ++Notepad [دانلود کنید] استفاده میکنیم.

برای این منظور، ابتدا زیرنویس را در این محیط باز می‌کنیم. در این مرحله محتویات آن را به همان صورت ناخوانا می‌بینیم. از منوی Encoding به صورت زیر، Windows-256 را انتخاب می‌کنیم تا متن فارسی به صورت خوانا ظاهر شود:

و سپس، باز از منوی File گزینه‌س Save As را انتخاب کرده و محتویات را به صورت یک فایل txt. ذخیره می‌کنیم و فایل جدید را به عنوان زیرنویس استفاده می‌کنیم.

راهکار سوم: (دائمی)

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

از منوی Start روی Control Panel کلیک کنید و سپس در پنجره ی باز شده روی  Clock, Language and Region (در ویندوز XP روی Region and Language) انتخاب کنید. در پنجره ی باز شده، ابتدا در تَبِ Format، از قسمت کشویی، Persian را انتخاب کنید و سپس به تَبِ Administrative رفته و با کلیک روی Change System Locale مجددا مشابه تصویر زیر Persian را انتخاب کرده و با زدن OK سیستم خود را Restart کنید:

از این به بعد، زیرنویس های دانلود شده، بدون مشکل ناخوانا شدن داخل Player باز می‌شوند. 

مشکل دوم: صفحات وب و ایمیل های خرچنگ قورباغه و ناخوانا

خوشبختانه منشاء این مشکل نیز همان مسئله‌ی انکدینگ است. برای رفع این مسئله چنانچه با یک ایمیل فارسی ناخانوا مواجه هستیم، می‌توانیم با Copy & Paste کردن محتوای آن در یک فایل متنی و انجام مراحل ذکر شده در راهکار اول و راهکار دوم برای زیرنویس ها، متن آن را بخوانیم؛ و چنانچه یا با یک صفحه ی وب فارسی مواجه هستیم، یا تمایلی به Copy & Paste کردن محتوای ایمیل نداریم، می‌توانیم تنظیمات Encoding مرورگر وب خود را به صورت زیر تغییر دهیم (هر بار یکی از گزینه های مشخص شده انتخاب می‌کنیم) تا نتیجه‌ی مطلوب را مشاهده کنیم:

برای مرورگر Google Chrome:

برای مرورگر Fire Fox:

Sorry, I don't like it :D use dear Google Chrome, or Google "How to change encoding in fire fox?" and follow the above steps!

قسمت بعدی: معیارهای امنیت

---

Well you only need the light when it's burning low

Only miss the sun when it starts to snow

Only know you love her when you let her go ...

رمزنگاری-مقدمه/2-اِنکُدینگ و دیکُدینگ

قسمت قبلی: هشینگ!

خیلی خب! در قسمت قبل (یعنی این پست) با "Hash" کردن یا دَرهم نگاری آشنا شدیم و فهمیدیم که هَش کردن یعنی اختصاص یک رشته ی با طول ثابت به یک ورودی دلخواه، با این شروط که:

1. از روی مقدار هش مقدار ورودی قابل تولید نباشد.
2. احتمال این که به ازای دو ورودی مختلف، یک خروجی تولید شود به قدری کم باشد که قابل چشم پوشی باشد.

همچنین فهمیدیم که الگوریتم های Hash کردن، کلید یا رمز ندارند و همه چیز صرفا یک الگوریتم است که تنها ورودی آن داده ی مورد نیاز برای Hash شدن است. برای عملی تر شدن توضیحات، می توانید با مراجعه به این سایت یا این سایت عبارت های مورد نظر خود را با چند الگوریتم مشهور دَرهم نگاری هش کنید. به هر حال من قبلا این کار را برای عبارت "This is a sample plain text" انجام داده ام و نتیجه را برای شما داخل عکس زیر آماده کرده ام:

و اما:

قسمت 2: Encoding/Decoding

معرفی فرایند:

چیزی که در این پست با آن آشنا می‌شویم، Encoding و Decoding است. طبق نوشته‌ی ویکی‌پیدا، Encoding به فرایند جایگزینی کاراکترها و رشته با کاراکترها و رشته های دیگری است که انتقال یا ذخیره‌ی آنها برای یک سیستم بهینه تر باشد و همچنین، عمل Decoding تغییر دوباره ی فرمت این کاراکترهای Encode شده به فُرم اولیه‌ی آنها می‌باشد. 

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

بنابراین، با توجه به مثال ارائه شده، Encode و Decode کردن تغییر فرمت(نحوه‌ی نمایش) یک متن/داده است به گونه ای که:

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

از آنجا که با ارائه شدن هر محصول یا تکنولوژی ای، معمولا یک فرمت بهینه برای آن سیستم ارائه می‌شد، گستردگی توابع Encoding/Decoding به گستردگی توابع هش کننده و یا حتی بیشتر از آن است. به عنوان مثال ASCII،  Bas64، UTF16، UTF32 و ... همگی نمونه هایی از Encodingهای مختلف می‌باشند.

کاربردها:

اولین سوالی که ذهن با آن مواجه می‌شود این است که چرا باید Encodingهای مختلفی وجود داشته باشد؟

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

به عنوان مثال در ابتدا وقتی سیستم عامل‌ها توسعه داده شدند، هر تولیدکننده ای بدون توجه به آنچه که تولیدکننده ی دیگر ارائه می‌دهد یک Encoding برای خود به وجود آورد! همچنین کسی در نظر نگرفته بود که حروف فارسی یا چینی یا زبان های دیگر و همچنین کاراکترهای خاص عبارت های ریاضی نیز قرار است در آن محصول استفاده شود و بنابرین بسنده کرده بودند به حروف انگلیسی کوچک و بزرگ و چند علامت ساده‌ی ریاضی. از آنجا که تعداد این کاراکترها از تعداد حالت هایی که با 8 بیت می‌توان تولید کرد افزون نبود، بنابرین 1 بایت را به آن اختصاص دادند و نام آن انکدینگ را ASCII گذاشتند. بعدها با گذر زمان وقتی نیاز به کاراکترهای بیشتر احساس شد، انکدینگ دیگری ارائه کردند که طول آن بیشتر از یک بایت باشد و بتواند کاراکترهای بیشتری در خود جای دهد. این روال در گذر زمان منجر شد که Encodingهای مختلفی بوجود آید. (مانند Unicode, UTF-32 و ...).

یکی دیگر از دلایل، ناسازگاری استانداردهای موجود برای انتقال بعضی داده ها و انجام بعضی کارها بود. به عنوان مثال استاندارد شده بود که برای جداسازی قسمت های مختلف یک URL (آدرس وب) از کاراکتر "/" استفاده شود. همچنین برنامه نویس می‌توانست به گونه ای برنامه ی وب خود را بنویسد که پس از پر کردن یک فرم در صفحه توسط کاربر،محتویات آن فرم را از طریق Address-bar از وی دریافت کند.مشکلی که وجود داشت این بود که چنانچه کاربر در فرم خود از کاراکتر "/" استفاده می‌کرد، آنگاه حین ارسال این کاراکتر به سرور، به خاطد تداخل داده ی کاربر با کاراکتر جداکننده، با مشکل مواجه می‌شد. برای رفع این مسئله و چند مورد مشابه یک Encoding جدید به نام URL Encoding برای محتویات خط آدرس ارائه شد. در این سیستم جدید، کاراکترهای خاص نظیر / و فاصله و ' و " و ... پیش از ارسال به مقادیر دیگری تبدیل می‌شود (به ترتیب به 2F% و 20% و 27%  و 22%) که با استاندارد آدرس دهی تداخلی نداشته باشند و آنگاه در سرور Decode شده و تفسیر می‌شوند. 

انکدینگ‌های مشهور:

همانطور که در خلال متن اشاره شد، برای انکدینگ های مشهور می‌توان به سری UTF اشاره کرد که شامل کاراکترهای زبان فارسی و ... می‌باشد ؛ ASCII که تنها شامل کاراکترهای زبان انگلیسی و یک سری کاراکتر خاص است و همچنین Base64 که معمولا برای نمایش خروجی توابع رمزنگاری استفاده می شود. برای تبدیل داده های خود از یک انکدینگ به انکدینگ دیگر می‌توانید از ابزارهای آنلاین مانند این سایت استفاده کنید، یا این که با دانلود کردن نرم افزارهایی مثل ++Notepad از امکانات آنها برای تغییر Encoding  بهره ببرید.

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

قسمت بعدی: مشکلاتی که با تغییر Encoding حل می‌شوند!

---

خوشا آنانکه الله یارشان بی

بحمد و قل هو الله کارشان بی

خوشا آنانکه دایم در نمازند

بهشت جاودان بازارشان بی

رمزنگاری-مقدمه/1-هَشینگ

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

1. هش کردن (Hashing)
2. کد کردن / از کد خارج کردن (Encoding & Decoding)
3. رمز کردن / از رمز خارج کردن (Encrypting & Decrypting)

قسمت 1: "هش کردن یا دَرهم نگاری"

معرفی فرایند:

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

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

وقتی که قراره قدرت یه تابع/الگوریتم هَش کننده رو بررسی کنند، باید دو تا مسئله در نظر گرفته بشه:

1. آیا با داشتن مقدار هَش یه داده، میتونیم داده رو بدست بیاریم؟
2. آیا با داشتن یه مقدار هَش، میتونیم داده یا داده هایی تولید کنیم که با اون الگوریتم همین مقدار رو به ما بدهند؟

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

Input 1:  HelloMyDearFriend

Input 2:  WhereDoYouWantToGO?

Step1 Of Hash(Input 1):  -e-l-M-D-a-F-i-n- 

Step1 Of Hash(Input 2):  -h-r-D-Y-u-a-t-o-o

Final Hash(Input 1): elMDa

Final Hash(Input 2): hrDYu

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

کاربردها:

توابع هَش، دو تا کاربرد اصلی دارند:

1. جایگزین پسورد برای ذخیره کردن در دیتابیس
2. به عنوان Check Sum

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

جواب:

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

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

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

و اما در مورد Checksum: فرض کنید شما قصد دارید فایلی رو روی سایت خودتون بذارید که کاربرهای شما دانلود کنند و میخواید اطمینان داشته باشید که فایلی که دانلود میکنند، داخل مسیر، به صورت اتفاقی(به خاطر Noise)و یا به صورت تعمدی(توسط یه هکر) دستکاری نشده باشه؛ خب چه راهکاری به ذهنتون میرسه؟

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

الگوریتم های مشهور:

SHA - MD5 - NT - LM  ....

توجه: بین hash و checksum و CRC  علیرغم شباهت های زیاد، تفاوت هایی هم هست که برای اطلاع از اونها به ویکی پدیا مراجعه کنید. (:

قسمت بعدی: اِندینگ و دیکدینگ

---

احسان هنری نیست به امید تلافی

نیکی به کسی کن که به کار تو نیاید ...

#صائب