| import re | |
| file_path = "/Users/tahamajs/Documents/uni/NS/slides/network_security_presentation_notes.html" | |
| with open(file_path, "r", encoding="utf-8") as f: | |
| content = f.read() | |
| replacements = [ | |
| ( | |
| r"(<h3>الگوریتم SHA-512<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی نمودار این اسلاید ملاحظه میکنید، جریان پردازش SHA-512 یه ساختار بلوکی دقیق داره. پیام ورودی به بلوکهای ۱۰۲۴ بیتی شکسته میشه و در کنارش ۸ مقدار هش اولیه ۶۴ بیتی (از $H_0$ تا $H_7$) داریم. اگه به شکل اسلاید دقت کنید، میبینید که اطلاعات وارد یه حلقه با ۸۰ راند پردازشی میشن. تو هر راند، ثابتهای $K_t$ و توابع پیچیدهای روی مقادیر رجیسترهای $a, b, c, d, e, f, g, h$ اعمال میشه تا در نهایت خروجی ۵۱۲ بیتی شکل بگیره.\2" | |
| ), | |
| ( | |
| r"(<h3>ساختار HMAC<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به شکل اسلاید در مورد ساختار HMAC دقت کنید، روند کار کاملاً مشخصه. ما کلید مخفی $K$ رو داریم که تا رسیدن به طول بلوک $b$ پد میشه و بهش $K^+$ میگیم. تو نمودار میبینید که این $K^+$ اول با $ipad$ (که مقدار ثابت 0x3636...36 هست) XOR میشه و به پیام $M$ میچسبه. بعد خروجی این ترکیب هش میشه: $H(K^+ \oplus ipad || M)$. تو مرحله بعد همونطور که نمودار نشون میده، $K^+$ با $opad$ (مقدار 0x5C5C...5C) XOR میشه، به خروجی هش قبلی میچسبه و دوباره کلاً هش میشه: $H(K^+ \oplus opad || H(K^+ \oplus ipad || M))$.\2" | |
| ), | |
| ( | |
| r"(<h3>الگوریتمهای DAA و CMAC<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی نمودار بلوکی CBC-MAC (یا همون DAA) میبینید، هر بلوک از متن ساده یا Plaintext داره با بلاک سایفرِ قبلی XOR میشه و IV هم اینجا صفر در نظر گرفته شده تا بلوک آخر به عنوان MAC تولید بشه. اما اگه به بخش CMAC تو همین شکل دقت کنید، میبینید که نمودار استخراج زیرکلیدها ($K_1, K_2$) چطور با استفاده از ضرب در متغیر $x$ تو میدان گالوا $GF(2^{128})$ انجام میشه تا همون مشکلات امنیتی رفع بشن.\2" | |
| ), | |
| ( | |
| r"(<h3>امضای دیجیتال ElGamal و Schnorr<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگر به نمودار گردش کار امضای دیجیتال توی اسلاید دقت کنید، دقیقاً فازهای مختلف تولید امضا مشخصه. نمودار با فاز تولید کلید شروع میشه، بعد میره سراغ فاز امضا که توش یه عدد تصادفی $k$ انتخاب میشه. تو سمت گیرنده یا همون فاز صحتسنجی (Verification)، معادلات ریاضی $V_1 = a^m \pmod q$ و $V_2 = y_A^{S_1} S_1^{S_2} \pmod q$ به صورت بصری نشون داده شدن که گیرنده چطور مطابقت اونا رو چک میکنه.\2" | |
| ), | |
| ( | |
| r"(<h3>مراحل پروتکل Handshake<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی نمودار توالی (Sequence Diagram) مراحل Handshake ملاحظه میکنید، این ۴ فاز به صورت رفت و برگشتی ترسیم شدن. ابتدا فلش ClientHello به سمت سرور میره و سرور با ServerHello، Certificate و ServerKeyExchange جواب میده. تو فاز بعدی کلاینت با فرستادن ClientKeyExchange کلید نشست رو میفرسته و در نهایت فلشهای ChangeCipherSpec و Finished رو میبینید که ارتباط امن رو نهایی میکنن.\2" | |
| ), | |
| ( | |
| r"(<h3>ساختار گواهی X.509<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به شکل اسلاید در مورد سلسله مراتب PKI دقت کنید، درخت Certificate Authority به وضوح رسم شده. در رأس نمودار Root CA قرار داره، پایینتر Intermediate CAها و بعدش Issuing CAها هستن که به End Entity یا همون کاربر نهایی ختم میشن. ضمناً تو بخش دیگه شکل، فلوچارت ACME Challenge رسم شده که نشون میده سرور Let's Encrypt چطوری اتوماتیک مالکیت دامنه رو تایید میکنه.\2" | |
| ), | |
| ( | |
| r"(<h3>فرآیند امضای دیجیتال و رمزنگاری تو PGP به چه شکله؟<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی فلوچارت عملیات PGP تو این اسلاید میبینید، گردش کار دقیقاً قدم به قدم ترسیم شده. ابتدا بلوک پیام رو داریم که به سمت امضای دیجیتال (ترکیب هش و کلید خصوصی RSA) میره. بعد فلش به سمت فشردهسازی ZIP میره. در مرحله بعد، نمودار نشون میده که چطور با یه کلید نشست (Session Key)، پیام رمزنگاری متقارن میشه و خود کلید نشست هم با کلید عمومی گیرنده رمز میشه. نهایتاً بلوک خروجی با تبدیل Radix-64 یا Base64 نمایش داده شده تا برای ایمیل مناسب باشه.\2" | |
| ), | |
| ( | |
| r"(<h3>ساختار پروتکلهای AH و ESP چطوریه؟<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به شکل اسلاید که ساختار هدر بستهها رو نشون میده دقت کنید، تفاوتها کاملاً مشخصه. تو نمودار هدر AH، فیلدهای Next Header، Length، SPI، شماره توالی (Sequence No) و داده احراز هویت (ICV) رو به ترتیب میبینید. اما تو فلوچارت ESP، ساختار به سه بخش تقسیم شده: اول ESP Header (شامل SPI و شماره توالی)، بعد قسمت Encrypted Payload و پدینگ، و در آخر ESP Trailer و ESP Auth ICV. همچنین تو پایین اسلاید، مقایسه بصری بین بستههای Transport mode در مقابل Tunnel mode نشون داده شده که چطور هدر IP جدید به Tunnel اضافه میشه.\2" | |
| ), | |
| ( | |
| r"(<h3>بهبودهای دقیق تو TKIP و CCMP چی بودن؟<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی نمودار امنیتی WEP در اسلاید ملاحظه میکنید، بردار IV ۲۴-بیتی به همراه کلید مخفی وارد تولیدکننده شبهتصادفی RC4 میشه و با Plaintext و چکسام خطی CRC-32 یه عملیات XOR انجام میده. همین خطی بودن CRC-32 تو شکل به عنوان نقطه ضعف مشخص شده. در مقابل، اگه به نمودار بلوکی CCMP دقت کنید، میبینید که چطور ساختار AES-CTR برای رمزنگاری و AES-CBC-MAC برای تایید صحت دادهها به هم گره خوردن تا امنیت بینظیری رو فراهم کنن.\2" | |
| ), | |
| ( | |
| r"(<h3>تفاوت False Positive و False Negative تو چی خلاصه میشه؟<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به نمودار منحنی تشخیص ناهنجاری (ROC/Anomaly Curve) تو اسلاید دقت کنید، میبینید که محورها تقابل بین True Positive و False Positive رو نشون میدن. تو این شکل، خط آستانه (Threshold) دقیقاً جایی تنظیم میشه که بتونیم بهترین تعادل رو بین تشخیص حملات واقعی (جلوگیری از False Negative) و هشدارهای اشتباه (False Positive) برقرار کنیم. همچنین تو تصویر قبلیش هم نمودار چیدمان سنسورهای Host-based در مقابل Network-based روی روترها و سرورها ترسیم شده.\2" | |
| ), | |
| ( | |
| r"(<h3>فرایند پیجویی دیجیتال بر اساس NIST<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی فلوچارت چرخه حیات فورنسیک NIST تو اسلاید میبینید، این ۴ فاز به صورت حلقهای و متوالی رسم شدن. بلوک اول Collection (جمعآوری) هست، بعد فلش به سمت Examination (بررسی) میره، سپس Analysis (تحلیل) و در نهایت فاز Reporting (گزارشدهی) نشون داده شده.\2" | |
| ), | |
| ( | |
| r"(<h3>رجیستری ویندوز و کلیدهای اصلی آن<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به نمودار درختی سلسله مراتب رجیستری ویندوز تو اسلاید دقت کنید، دقیقاً نشون داده شده که کلیدهای ریشه مثل HKEY_LOCAL_MACHINE و HKEY_CURRENT_USER چطور شاخهبندی میشن و اطلاعات حیاتی سیستم تو کدوم مسیرها قرار گرفتن.\2" | |
| ), | |
| ( | |
| r"(<h3>DMZ و استقرار فایروال \(Firewall Deployment\)<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به شکل اسلاید در مورد معماری شبکههای DMZ دقت کنید، دیاگرام استقرار فایروالها کاملاً مشخصه. تو نمودار میبینید که یک فایروال خارجی (External Firewall) اینترنت رو از سرورهای عمومی DMZ جدا میکنه، و یه فایروال داخلی (Internal Firewall) بین منطقه DMZ و شبکه محلی (LAN) قرار گرفته. همچنین تو جدول مقایسهای پایین همین اسلاید، تفاوت عملکرد Packet Filtering و Stateful Inspection به صورت بصری تفکیک شده.\2" | |
| ), | |
| ( | |
| r"(<h3>حریم خصوصی تفاضلی \(Differential Privacy\) و پاسخ تصادفی<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nهمونطور که توی نمودار درختی پرتاب سکه برای الگوریتم پاسخ تصادفی (Randomized Response) تو اسلاید ملاحظه میکنید، جریان تصمیمگیری مشخص شده. کاربر تو گره اول سکه میندازه؛ یه شاخه به اسم Heads (شیر) میره که کاربر باید حقیقت رو بگه، و شاخه Tails (خط) میره به سمت یه پرتاب سکه دیگه که اونجا به صورت تصادفی جواب Yes یا No میده. این شکل به خوبی نشون میده که چطور نویز تصادفی وارد دیتابیس میشه.\2" | |
| ), | |
| ( | |
| r"(<h3>انسان در حلقه \(Human in the Loop\)<\/h3>\s*<p>.*?)(<\/p>)", | |
| r"\1\nاگه به شکل اسلاید درباره چارچوب انسان-در-حلقه (Human-in-the-Loop) دقت کنید، این روند به صورت فلوچارت ترسیم شده. بلوک اول، اطلاعات و سیگنالهای امنیتیه که وارد بلوک پردازش انسانی (Human Processing) میشه. در نهایت فلش خروجی به سمت Action یا متاسفانه همون Security Error میره که نشوندهنده اهمیت طراحی رابط کاربری تو کاهش این خطاهاست.\2" | |
| ) | |
| ] | |
| for pattern, repl in replacements: | |
| content, count = re.subn(pattern, repl, content, count=1, flags=re.DOTALL) | |
| if count == 0: | |
| print(f"Failed to match: {pattern[:50]}") | |
| with open(file_path, "w", encoding="utf-8") as f: | |
| f.write(content) | |
| print("Done") | |
Xet Storage Details
- Size:
- 11.9 kB
- Xet hash:
- 73d62f9d3899599ec3a54d426dda8d8dab7e8dc2bd299dde10214cabe802e9fd
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.