Kamal Privacy

شما اگر ایمیل برای کسی بفرستین، خب این ایمیل یه جا تو سرورا ذخیره میشه. و خب جایی که ایمیل داده بهتون (مثل جیمیل) مثلا درسترسی داره که بخونتش.

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

نه خیر میمونه! پیش‌نویس توی هوا که ساخته نشده😁. توی سرورا ذخیره میشه. بعد پاک‌کردن پیش‌نویسم قرار نیست لزوما فایلشم همون موقع پاک شه که.

خب شاید بگین کی آخه این کار رو می‌کنه. باید مدیر CIA (General David Petraeus) دقیقا همینکارو می‌کرده :)

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

اثبات کنید بین 0 و 1 عدد صحیحی نیست.🫪🫪

خب ما یه قضیه (Well-ordering theorem) داریم که میگه:

یک مجموعه خوش‌ترتیب هست اگر هریک از زیرمجموعه‌های غیرتهی‌‌اش رو بگیریم، قطعا کوچک‌ترین عضو رو داره.

مثلا اعداد صحیح مثبت (1, 2, 3, 4...):
هر یک زیرمجموعه‌هاش رو در نظر بگیرین، یه دونه کوچکترین عنصر داره.

ولی مثلا اعداد صحیح منفی، اینطوری نیست:
{..., -3, -2, -1}
خودش که زیر مجموعه خودش هم هست در نظر بگیریم، هیچوقت نمیتونیم کوچکترین عضوش پیدا کنیم. پس well-ordered نیست.

حال بریم سراغ اثبات:
فرض می‌کنیم که بین 0 و 1 یه عدد صحیح دیگه هست. مجموعه زیر رو در نظر می‌گیریم:
S = {k | 0 < k < 1}
مجموعه‌ای از k ها که بین صفر و یک هستن. خب طبق تعریف اینکه اعداد صحیح مثبت well-ordered هستن، پس یه عضوی مثل n داریم که کوچکترین عضوشونه.

حالا باید ببینیم می‌تونیم یه چیزی پیدا کنیم که از n کوچکتر باشه و نقض کنه که n کوچکترین بوده؟
چون:
0 < n < 1 -> n² < n < 1
عه! یافتیم! n² چون n بین صفر و یک بود، کوچکتر از n هست. این روند رو هی می‌تونیم تکرار کنیم:
... n⁴ < n³ < n² < n < 1

پس فرضمون که یه کوچکترین عضو وجود داره غلط شد. پس بین 0 و 1 عددی نیست. چون اگر بود، چون مثبته باید کوچکترین عضو میداشت🙄

مبحث: نظریه اعداد، پیشنیاز ریاضیات رمزنگاری

امروزا خبرایی شنیدیم که اطلاعات وی‌پی‌ان JumpJump در حال فروشه. ۳ ماه پیش (پیام ریپلای شده) درباره همین VPN توی گروهِ کانال نوشته بودم🌝🌝

از اپلیکیشن‌های معتبر استفاده کنین🕊

در رمزنگاری، ما با نظریه اعداد خیلی کار داریم. یه سوال ساده برای علاقه‌مندی به نظریه اعداد:

اثبات کنید که هیچ تابع چندجمله‌ای غیرثابت (ثابت مثل: f(x) = 2) با ضرایب صحیح وجود نداره که همش اعداد اول تولید کنه.
خب فرض کنیم که چندجمله‌ای ما به این شکله:

ax^{n} + bx^{n-1} + ... + cx + d

خب من مثلا مقدار 0 رو داخلش قرار میدم. عدد حاصل d میشه این عدد یا غیر اوله یا اول. خب فرض می‌گیرم که بدشانسی اوردم و اوله.

خب حالا من میگم که چیکار کنم که عددی غیر اول تولید شه؟ ما یه قضیه داریم که اگر دو عدد بر یک چیز بخش‌پذیر باشن، حاصل جمع خطیشونم بر همون بخش‌پذیره. یعنی اگر a و b بر d بخش‌پذیر باشن،
an + bm
هم بر d بخش‌پذیره.
اینجا من میام همون d رو می‌ذارم داخل تابع!

ad^{n} + bd^{n-1} + ... + cd + d

هر جملش بر d بخش‌پذیره و ترکیب خطیشونم بر d بخش‌پذیره :)

از جایی هم که تابع ما ثابت نیست، پس درواقع یه ضریبی از d وجود داره که اگر به تابع بدیم، عددی بخش‌پذیر بر d تولید می‌کنه. پس ثابت کردیم که تابع همیشه اول تولید نمی‌کنه ؛)
زیبا نیست آیا؟ 🦌

گاهی ما می‌خوایم امنیتمون رو خیلی بالا ببریم، به جاش باعث میشیم امنیت بیاد پایین!! ⬇

مثلا هر هفته یه پسورد جدید و طولانی برای سیستم انتخاب می‌کنیم. کارمندا دیگه خسته میشن، پسوردو رو کاغذ می‌نویسن روی میز میذارن و هم وقتی میخوان برن یه چای یا چیزی بخورن، کامپیوتر خاموش نمی‌کنن و میگن: "ول کن بابا الان میام. کی حوصله داره دوباره اون پسورد طولانی رو دوباره بزنه😒."

غافل از اینکه تو همین زمان کم ممکنه یه فرد بد پشت سیستم بشینه و‌..🌝

حتما شرکت کنین🌝

انجمن علمی رباتیک دانشگاه شیراز برگزار می‌کند:

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

👨🏻‍🏫 مدرس:

محمد کمال
فارغ‌التحصیل مقطع کارشناسی مهندسی
نویسنده‌ی کتاب
Beyond the Veil: A Guide to Privacy, Security, and Anonymity in the Digital Era

📚 سرفصل‌های کارگاه:

1. مفاهیم و فرایندهای پایه‌ای حوزه امنیت
2. مهندسی اجتماعی
3. کاربرد رمزنگاری؛ از حفاظت روزمره تا پردازش پرایوت AI
4. انواع بدافزارهای کامپیوتری
5. حملات سخت‌افزاری
6. امنیت کد و نرم‌افزار امن
7. مسیر و نقشه راه ورود به حوزه امنیت

💻 نحوه برگزاری: آنلاین
💵 هزینه شرکت در دوره: رایگان
📅 زمان برگزاری:

۱۹ و ۲۳ شهریور
ساعت ۱۶ تا ۱۸

📌 ظرفیت ثبت‌نام محدود است.

📲 ثبت‌نام و پشتیبانی از طریق آیدی تلگرام:
@Roboshiraz
🔗 لینک کانال انجمن علمی رباتیک دانشگاه شیراز:
@ShirazURoboticsAssociation⁠

یکی از چیزایی که باید دقت کنیم، بحث پیام ارور در پیاده‌سازی هست. فرض کنین یه سیستمی داریم که توی forget password ایمیل رو میگیره و

✅ اگر ایمیل درست باشه، پیام میده: ایمیل بازیابی رمز به ایمیل شما ارسال شد.
❌ اگر اشتباه باشه میگه: ایمیل وارد شده ثبت نشده. لطفا ایمیل صحیح را وارد کنید.

خب مشکل کجاست؟ من اگر یه برنامه بنویسم که خودکار ایمیلای مختلف رو چک کنه، می‌تونم بفهمم کیا توی سیستم ثبت‌نام کردن و کیا نکردن 🌝 و اینطوری دیتابیس ثبت‌نام کنندگان رو در میارم :)

اینجاست که کتاب Cryptography Engineering میگه:

Errors need very careful handling, as they are a potential avenue of attack. The safest procedure is not to send any reply to an error and immediately delete the protocol state. This minimizes the amount of information the attacker can get about the protocol.

Unfortunately, it makes for an unfriendly system, as there is no indication of the error. To make systems usable, you often need to add error messages of some sort. If you can get away with it, don’t send an error message to the other parties in the protocol. Log an error message on a secure log so the system administrator can diagnose the problem. If you must send an error message, make it as uninformative as possible. A simple “There was an error’” message is often sufficient.

Src: Cryptography Engineering
Design Principles and Practical Applications, Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno

یه مشکلی که معمولا وجود داره اینه که ادما میان یه لایه امنیت سخت و سفت برای بیرون و ورود میذارن 🔒، ولی وقتی شما دسترسیتو گرفتی، دیگه داخل سیستم/سازمان/شبکه عملا وِل هستی و میتونی خیلی کارا کنی 🏃.

درحالی که در مکانیزم مدرن، میگن درخواست‌های کاربر باید در تمامی اوقات مورد بررسی و بازبینی قرار بگیره 👀. چرا؟🤔

۱. ممکنه مکانیزم بیرونی یه مشکلی داشته باشه و حمله‌کننده بتونه وارد شه و وقتی وارد شد دیگه آزاد و رهاست 🚪🔓

۲. همیشه که فقط از بیرون حمله نمیشه، ممکنه یه حمله‌کننده از طریق یه فردی که دسترسی داره، اعمالش رو انجام بده 🕵️‍♂️💻.

۳. یه فرد داخلی خودش آدمه دیگه. ممکنه یه روز یا خودش بخواد یا تهدید شه و مجبور شه یه سری کارها توی سیستم کنه 🤐⚠️.

پس باید هر کاربر و هر پراسس، هر درخواست و هر کارش تحت نظر باشه و قبل اکسپت یه بررسی خودکار صورت بگیره✋🚫.

همیشه این سوال بوده که ما مگه تو لایه‌های پایین شبکه، ارورسنجی نمی‌کنیم؟ 🤔 چه نیازی هست دوباره برای لایه‌های بالاتر اینو تکرار کنیم؟* [1]

خب فرض کنین یه مسیجی داریم:

m = a b c

که a و b و c هرکدوم جدا ارسال میشن. 📦

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

اینجاست که Horton Principle میگه:

Authenticate what is being meant, not what is being said (sent). 🎯

برای همین ما نه‌تنها باید خود اطلاعات رو اعتبارسنجی (MAC) کنیم 🔐، بلکه باید توی این اعتبارسنجی، اطلاعاتی که به صورت درست بتونه مسیج رو سر هم کنه هم اعتبارسنجی کنیم.

[1] Src: Cryptography Engineering
Design Principles and Practical Applications, Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno
* ارورسنجی با cryptographic check هم فرق داره....

وقتی صحبت از حریم شخصی میشه، نام DuckDuckGo 🦆 معمولا به چشم میاد.

خدماتی که ارائه میده:
◀ موتور جست‌و‌جو و برای سرچ، جایگزین گوگل: duckduckgo.com 🔎🌐
◀ هوش مصنوعی با حریم شخصی بالا و بدون جمع‌آوری اطلاعات برای آموزش مدل: duck.ai 🤖🔒
◀ برنامه و مرورگر اندروید برای مسدودسازی دنبال‌کننده‌های فعالیت شما که در برنامه‌ها هستن (ببینید) 📱🚫
◀ فورواردکننده ایمیل: به جای اینکه آدرس ایمیل اصلیتون رو بدین به جاهای مختلف، یه ایمیل میانی میدین که هم دنبال‌کننده‌های توی ایمیل رو حذف می‌کنه و هم آدرس اصلی ایمیلتون پنهون میمونه (لینک) 📧🕵️‍♂️

هر زبونی (مثل انگلیسی) 🗣، یه سری اضافات یا redundancy داره. یعنی چی؟ یعنی
یعنی مثلا اگر حرف q داشته باشیم، احتمال اینکه حرف بعدی u باشه خیلی زیاده. چون اکثر کلماتی که q دارن، حرف بعدیشون u هست*:

technique, frequency, queen, question, quiet, quality, request, quarter

یعنی میشه موقع انتقال اطلاعات از u بدون کاهش معنا صرف‌نظر کرد چون توی این حالات معنای خاصی نمیده و تا q رو ببینیم، خودمون میدونیم که بعدیش u هست.[1]

اگر حروف انگلیسی در متن بامعنا رندوم بودن، Shannon میگه هر حرف انگلیسی 4.7 بیت اطلاعات جابه‌جا می‌کنه (log_2{26} = 4.7) [2]. اما در یک متنِ بامعنا هر حرف صرفا حدود 1.5 بیت اطلاعات به همراه داره. یعنی درواقع 4.7 - 1.5 = 3.2 بیت redundancy داریم! 📉

این برای ما خوب نیست چون میتونه به خیلی از حمله‌ها در شکستن الگوریتم رمزکردن** اطلاعات -که کسی نفهمه چی گفتیم و فقط خودمون بفهمیم- کمک کنه. چرا؟ چون اگر الگوریتم ما اینها رو پنهون نکنه، حمله‌کننده میتونه از اطلاعات از پیش‌داشته مثل بالا یا تکرار بیشتر حروف (مثلا E بیشتر از Z تو انگلیسی تکرار میشه و تو حروف دوتایی th بیشتر از بقیه تکرار میشه) برای شکستن متن بهره ببره. 🔓

پ.ن‌ها:
* طبیعتا کلمات غیر انگلیسی مثل: Qatar, Iraqi, ... رو در نظر نگرفتیم.

** مثلا یه نمونه رمز، تبدیل
how are you
به
ipx bsf zpv
هست که به جای هر حرف، حرف بعدیش توی حروف الفبا رو گذاشتیم 🔁

[1] Communication Theory of Secrecy Systems, C. E. Shannon
[2] A Mathematical Theory of Communication, C. E. Shannon

حالا آیا قوانینی وجود داره که بتونه از ما در برابر این چیزها دفاع کنه؟🤔 بله. همینکه شما وارد سایتا میشین و ازتون میپرسه چه کوکی‌هایی رو اکسپت می‌کنین، ناشی از این حقوق هست. بیشتر درباره مباحث حقوقی می‌تونین از این مطلب بخونین 📖

حالا این کوکی چطور می‌تونه به نقض حریم شخصی کمک کنه؟🌝

🌐🧭 چجور صفحه‌هایی که تو مرورگر (مثل فایرفاکس) می‌بینیم، بهمون نمایش داده میشن؟

وقتی شما آدرس یه سایت رو توی نوار بالای مرورگر وارد می‌کنین، مثلاً:
https://en.wikipedia.org/wiki/Ariobarzanes_of_Persis
یعنی به مرورگر می‌گین: «برو از سرور ویکی‌پدیا، توی مسیر* «wiki» برام چیزای مربوط به آریوبرزن رو بیار».

🧠 مشکل پروتکلی که ما باهاش این درخواست‌ها رو می‌فرستیم (یعنی HTTP) اینه که بی‌حافظه یا اصطلاحاً Stateless هست؛ یعنی هر درخواست از درخواست دیگه کاملاً مستقله و سرور یادش نمی‌مونه قبلاً چی رخ داده. مثلاً اگه شما یه کالا به سبد خریدتون 🛒 اضافه کنین و برین صفحه بعدی سایت، سرور توی درخواست جدید اصلاً یادش نیست شما کی بودین یا چی تو سبدتون داشتین! برای همین باید یه راه‌حل ایجاد می‌شد که این مشکل رو حل کنه.

🍪 یکی از این راه‌ها، «کوکی» هست. کوکی انواع مختلفی داره، اما به زبان ساده: وقتی شما وارد یه سایت می‌شین، سرور یه تیکه اطلاعات کوچک براتون می‌فرسته. مرورگر شما این داده رو روی کامپیوتر یا گوشیتون ذخیره می‌کنه..💾 از اون به بعد، مرورگر هر درخواستی که به اون سایت می‌فرسته، این تیکه داده رو هم ضمیمه‌اش می‌کنه تا سرور بفهمه شما همون کاربر قبلی هستین. (طلبیعتا خودش هم آیدی شما رو یادش هست)

اگه بخوایم خیلی ساده شبیه‌سازیش کنیم (مثلاً فقط با یه عدد به عنوان شناسه کوکی):

- 👋 درخواست اول (مرورگر): سلام، من صفحه آریوبرزن رو می‌خوام.
+ 🔢 پاسخ (سرور): سلام، بیا اینم صفحه. راستی، این شناسه رو (مثلاً عدد ۱۲۳) پیش خودت ذخیره کن و دفعه بعد که اومدی بهم نشونش بده. (اینجا مرورگر عدد ۱۲۳ رو روی سیستم شما ذخیره می‌کنه)

- (مرورگر): من همون ۱۲۳ هستم؛ حالا صفحه سورنا رو می‌خوام.
+ 🔁✅ پاسخ دوم (سرور): آها تویی! بفرما اینم صفحه سورنا.


👀🕵️ تا اینجا رو داشته باشین تا بعدش بهتون بگم چرا همین کوکی‌ها می‌تونن باعث تعقیب (Tracking) شما توی اینترنت بشن!

* این مسیر منطقیه و میتونه فولدر، مسیر کد یا یک Endpoint از API باشه.

if ((( options == __WCLONE ) || (options == __WALL)) && ( 
currUid = 0)) 
    retval = -EINVAL ;

- خب مشکل کجاس؟
+ توی if اگر نگاه کنیم، به جای == اشتباهی = گذاشته! اما خب این چه مشکلی ممکنه به وجود بیاره؟!

بیایم برگردیم به سال ۲۰۰۳. زمانی که کد اصلی و برنچ اصلی لینوکس توی دوجا وجود داشت. هردو با هم سینک بودن ولی.
هر کد که قراره تایید بشه و وارد کرنل بشه، یه کد بهش اختصاص میدادن و یه متن که فلانی اینو تایید کرده.
اما دیدن که توی یکیش یه کد هست که کد نه تایید شده نه توضیحات داره. یکمی واردش شدن و دیدن که عه! این کد یه مشکل داره! == به کار نبرده و = به کار برده.

یکمی دقت کنیم. uid یعنی user id. و توی لینوکس کاربرها آیدی دارن. آیدی کاربر روت، 0 هست. خب حدس زدیم پس این کد که درون یه تابع بود، درواقع id کاربر رو 0 میکنه یعنی دسترسی روت میده‼

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

بعدا مشخص شد که سرور رو هک کردن و این کد رو وارد کردن. این درواقع تلاشی بود برای واردکردن یه backdoor توی لینوکس! که البته ناموفق بود و معلوم نشد که کی این کار رو کرده

توضیح ساده بکدور: یه در پشتی که بتونن از طریق اون بدون اعتبارسنجی، به سیستم نفوذ کنن!
البته این کد هیچوقت وارد هسته اصلی لینوکس نشد و تاییدکنندگان کدها پیداش کردن!
[Src]

🔐 چه زمانی سیکرت چت تلگرام /واتسپ/ سیگنال، واقعا امنن؟

شما باید برید توی چت سیکرتی که می‌خواین، بعدش روی پروفایل فرد کلیک کنین و بعد برید داخل Encryption Key، یه کدی رو می‌بینین. باید این کد عینا با کد توی گوشی دوستتون (اون رو پروفایل شما بزنه و بعد همین کد رو نگاه کنه) یکی باشه.

🌝 یا حضوری چک کنین یا با برنامه و اینترنت دیگه‌ای این کدها رو با هم به اشتراک بگذارین و ببینین آیا یکی هستن؟

❓اما این کدها چی هستن؟
این کدها هش public-key شما و طرف مقابل هستن. اگر هش یکی باشه یعنی public-key ها در دو دستگاه یکی هستن و رمزنگاری درست انجام شده :) بیشتر از قسمت «Asymmetric Encryption» و حمله «MitM» کتابم بخونین.

دو نکته مهم باقی میمونه:

1⃣🧂 همونطور که در کامنت پست قبل یکی از دوستان اشاره کردن، یکی از راهکارهای یافتن پسورد کاربران بعد از دزدیده‌شدن دیتابیس این هست که بیایم پسوردهای مختلف و رایج رو هی هش کنیم و هی خروجی رو با دیتابیس مقایسه کنیم. (بروت‌فورس) هر وقت یکی شد، پسورد کاربر رو پیدا کردیم. 🍃

اتفاقا فایل‌های بزرگی از هش پسوردهای رایج تو اینترنت آدما گذاشتن که میشه ازشون استفاده کرد برای این کار.🌝

برای جلوگیری از این، ما یه میایم موقع ثبت‌نام برای هر فرد، یک چیز رندوم (مثلا Lbebhxyfvw) به پسوردش (پسورد مثلا ۱۲۳۴) اضافه می‌کنیم و بعد هش می‌کنیم.
hash("1234Lbebhxyfvw")
و توی دیتابیس یه ستون جدید اضافه می‌کنیم:
Username | hash | salt

موقع ورود کاربر، چون سالت رو نداره، سالت رو میفرستیم طرف کاربر. بعد پسورد و سالت رو هش می‌کنیم و میفرستیم سمت سرور و با هش توی سرور مقایسه می‌کنیم.

و

2⃣🐢 ما انواعی از هش داریم. بعضیا خیلی سریعن (برای مقایسه‌های برابری دو فایل/باینری) اما بعضیا به عمد کندن 🦥

برای جلوگیری از تلاش زیاد برای تست پسوردهای مختلف و چک برابری با هش‌های لو رفته (مشابه توضیح مورد 1️⃣)، ما باید هش‌های پسوردمون کند باشن، مموری زیاد ببرن (که نشه براشون دستگاه‌های خاص منظوره ارزون ساخت) و خلاصه هر ویژگی که باعث بشه تست حالات زیاد زمان‌بر⏱، هزینه‌بردار💰 و سخت بشه. می‌خوانیم:
A function that is memory-hard under this definition requires the adversary to use either a lot of working space or a lot of execution time to compute the function. Functions that are memory-hard in this way are not amenable to implementation in special-purpose hardware (ASIC), since the cost to power a unit of memory for a unit of time on an ASIC is the same as the cost on a commodity server. [BALLOON]

خب تبریک 💐. حالا با هش‌های cryptographic عادی برای چک برابری و هش‌های مخصوص پسورد آشنا شدین. چیزی که خیلی از دولوپر ها نمیدونن و میان SHA (هش چک برابری) رو برای پسورد به کار می‌برن 🤦‍♂🤦‍♀. بیشتر از فصل Cryptography کتابم بخونین.🫰

🌵 هش یه کاربرد دیگه‌ای داره: ذخیره پسورد!

ما اگر پسوردای آدما رو عادی تو فایل ذخیره کنیم، اگر فایل از سیستما/سرورا دزدیده شه خب تبریک :) پسورد همه لو رفت😄

اما هش‌های cryptographic مورد نظر ما، دو ویژگی زیر رو دارن:
۱. هش برگشت‌ناپذیره؛ یعنی اگر هش یک فایل/متن رو به شما بدم، شما هیچ‌جوره نمی‌تونید خود فایل/متن رو بسازین.
۲. هیچ دو متن/باینری/فایلی هش یکسان ندارن.

ما می‌تونیم هنگام ثبت‌نام، از پسورد کاربر هش بگیریم و هش رو در دیتابیس ذخیره کنیم. موقع ورود هم باز پسورد کاربر رو هش می‌کنیم و طبق ویژگی ۲، اگر برابر بود با چیزی که تو دیتابیسه، خب پسورد درست وارد شده و اجازه ورود میدیم.
اگرم یه وقت دیتابیس دزدیده شد، به دلیل ویژگی ۱، پسوردا لو نمیرن. 🙌 🌻

مشکل تقریبا حل شد. فقط یه چیز دیگه مونده. منتظر پست بعدی باشین...⏳

تا حالا شده بخواین چک کنین دوتا فایل عینا یکی هستن یا خیر؟ خب ما نمی‌تونیم بریم بیت به بیت فایلو بخونیم که😄

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

اینطوری صرفا کد اثرانگشتا (که بهشون میگیم هَش) رو مقایسه کنیم، می‌تونیم مطمئن شیم فایلا یکی هستن یا نه.

این الگوریتم خاص جوری طراحی شده که اگر یه نقطه هم از فایل کم یا زیاد شه، اثرانگشت فرق کنه.🐇