نقل قول نوشته شده توسط SZsXsZS مشاهده تاپیک
برنامه من اشکالش از نظر خودم کمبودهای مهمش ایناست:
- باید برای هر جلسه ارتباطی یک session key جدید ایجاد و استفاده بشه (الان همیشه از master key استفاده میشه).
- مسئلهء پیچیده تر forward secrecy که نداره. برای این منظور باید از الگوریتم ها/پروتکل های پیشرفته ای استفاده کرد که باعث میشن اگر کلید اصلی دست نفوذگر بیفته با این حال نتونه ارتباطات قبلی رو رمزگشایی کنه. البته این یک ویژگی پیشرفته است که فکر میکنم خیلی از نرم افزارهای دیگر هم ندارن، ولی بهرصورت چیز خوبیه دیگه!! من دنبالش نرفتم دقیق نمیدونم چطور باید پیاده اش کرد، اونم برنامهء من که ارتباطش از طریق HTTP است و حالت سوکت مستقیم و پایدار نداره شاید به همین خاطر از یکسری کتابخانه های مربوطه نشه درش استفاده کرد.
- امکانی برای تغییر کلید از راه دور (از طریق سمت مانیتورینگ) باید بهش اضافه کنم ویژگی مفیدیه (هم کلید کلاینت ها و هم کلید سرور واسط رو بشه توسط برنامهء کنترل تغییر داد).

بقیش دیگه نمیفهمم چی میگی اصلا منظورت چیه! بنظرم باید بیشتر توضیح بدی. دقیقا بگو اشکال برنامهء من کجاست چطوری چه حمله و نفوذ یا سوء استفاده ای ازش ممکنه.
فکر کردم دیدم وقتی forward secrecy رو پیاده نمیکنیم، چه ضرورتی برای session key هست؟
حقیقتش هم نیازی نیست!
اینجا هم پرسیدم گفتن ضرورت نداره: http://crypto.stackexchange.com/ques...-key-each-time
البته اینکه میگیم ضرورت نداره یعنی حیاتی نیست، ولی تحت بعضی شرایط میتونه فوایدی داشته باشه بهرحال، ولی در کاربردهایی که خیلی مهم و حساس نیستن فکر نمیکنم ارزش پیاده سازی داشته باشه.
البته در برنامهء بنده کلید اصلی هم مستقیما استفاده نشده و توسط HKDF، دو کلید یکی برای AES و دیگری برای HMAC ازش مشتق شده. ولی حتی این هم مطمئن نیستم ضرورت داشته باشه، ولی خب ضرری هم نداره و بهرحال وقتی میخوایم از کلید اصلی یک کلید دیگر هم مشتق کنیم (برای HMAC)، بهرحال باید از HKDF استفاده کنیم و بنابراین از نظر کد فرق چندانی نمیکنه که از کلید اصلی مستقیم استفاده کنیم یا نه.