نوشته‌شده در

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

من می خواستم برای دستیابی به مکانیزم زیر برای رمزگذاری یک سند

  1. هر شخص در یک گروه از N (کاربر a، b، c …) کلید خود داشته باشد؛
  2. user a و user b به نوعی تصمیم گرفت برای رمزگذاری اسناد M، و آنها می توانند M را در متن ساده بخوانند، و هر کسی غیر از a و b می تواند سند M را
  3. را بخواند، کاربر A، کاربر B و کاربر C به نحوی تصمیم به رمزگذاری اسناد N می دهد و همه می توانند آن را بخوانند N در متن ساده، اما هر کسی غیر از a، b، c نمی تواند سند N را بخواند

آیا امکان دارد؟ اگر چنین است، چگونه برای رسیدن به چنین عملکردی؟ (من احساس می کنم PGP نمی تواند این مشکل را حل کند)

نوشته‌شده در

رمزنگاری – OpenSC قادر به اتصال javacard با اپلت PKCS نیست

کارت هوشمند JavaCOS A40 من خالی هست و می خواهم آن را PKCS PKI کارت کنم.

من قصد دارم از آن به عنوان کلید ssh و برای امضای قرارداد الکترونیکی استفاده کنم. روسیه برای شناسایی شهروندان مانند کشورهای عضو اتحادیه اروپا، نشانی اینترنتی الکترونیکی مبتنی بر کارت های هوشمند را ارائه نمی دهد. ارائه دهندگان امضای تجاری امری برخی از انواع درایوهای USB محافظت شده با رمز عبور را به فروش می رسانند که استفاده از آن ناامن است زیرا شما می توانید به راحتی کلید خصوصی صادر کنید. همچنین آنها کارت های معمولی را به فروش می رسانند، اما واقعا گران هستند (x10-x20 از javacard خالی) و کوتاه مدت (حدود 1 سال). بنابراین من می خواهم PKI خود را بر اساس الگوریتم RSA از javacard ایجاد کنم.

اکنون javacard من در حالت OP_READY است و من آن را تغییر نداده ام، چون تغییرات غیر قابل برگشت است. از کلید پیش فرض استفاده می کند و هر کسی می تواند هر چیزی را بارگذاری کند. من از ACR38U خواننده با pcsc راننده لینوکس در اوبونتو استفاده میکنم و به عنوان انتظار میرود، بنابراین از GlobalPlatformPro برای آپلود PKI IsoApplet به عنوان پیشفرض استفاده میکنم. بنابراین خروجی GP: 

 java-jar gp.jar -list
هشدار: هیچ کلیدی داده نشده است، با استفاده از کلید تست پیش فرض 404142434445464748494A4B4C4D4E4F
ISD: A000000003000000 (OP_READY)
     Privs: SecurityDomain، CardLock، CardTerminate، CardReset، CVMManagement

APP: F276A288BCFBA69D34F31001 (SELECTABLE)
     Privs: CardReset

PKG: F276A288BCFBA69D34F310 (بارگیری شده)
     نسخه: 1.0
     اپلت: F276A288BCFBA69D34F31001

cardpeek با موفقیت به آن متصل می شود و می توانم دستورات سطح پایین را به اپلت ارسال کنم
cardpeek

اما هنگام تلاش برای اتصال به کارت و اپلت با استفاده از opensc برای دیدن جواب به درخواست (ATR)، آن را شکست می دهد opensc-tool - خواننده 0 --atr . مشاهده حداکثر اطلاعات اشکالزدایی

نسخه کوتاه شده: 

 opensc-tool --reader 0 --atr -vv
اتصال به کارت در خواننده ACS ACR 38U-CCID 00 00 ...
0x7fc849e7e740 22: 17: 14.634 [opensc-tool] card.c: 200: sc_connect_card: called
0x7fc849e7e740 22: 17: 14.634 [opensc-tool] card-entersafe.c: 138: entersafe_match_card: called
اتصال به کارت انجام نشد: دستور کارت شکست خورد
0x7fc849e7e740 22: 17: 14.797 [opensc-tool] ctx.c: 870: sc_release_context: نام

بر اساس اطلاعات تولید کننده، کارت پشتیبانی از T = 0 بیش از ISO7816 است، اما opensc تلاش می کند با T = 1 ارتباط برقرار کند. پس چگونه می توانم این را حل کنم؟

به نظر می رسد که ابزار opensc قابل تنظیم نیست. من باید از pkcs15-crypt استفاده کنم اما نمیتوانم اتصال برقرار کنم. آیا می توانم درایورها را تغییر دهم، opensc را مجددا با پچ ها باز کرده یا از ابزار دیگری استفاده کنم؟ چگونه روش های دیگر من می توانم برای مثال برای OpenPGP کار کنم؟

نوشته‌شده در

مدیریت کلید – اقدامات کلیدی چندگانه PGP برای امضای کد، GitHub، و ایمیل

من مجموعه ای از اهداف برای گواهینامه PGP را استفاده می کنم و آنچه که من فکر می کنم یک برنامه منطقی به عنوان یک راه حل است، توسعه داده ام. آنچه که من تعجب می کنم این است:

آیا من چیز مهمی را که نیاز دارد یا به شدت پیشنهاد تغییر در راه حل من را نادیده می گیرد؟

این سوال در مورد نگهداری مجموعه پیشنهاد شده کلید یا "بهترین روش ها" نیست "برای نسل، پشتیبان و غیره. همه چیزهایی که من در اینجا اهمیت می دهم این است که چه تله هایی را برای خود تعیین کرده اید یا سوراخ های امنیتی که ایجاد کرده ام، یعنی برنامه خود را ارزیابی کنید.

Intro

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

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

تهدید

هیچ تهدید غیر معمولی وجود ندارد. بازیگران دولتی / به خوبی تأمین مالی این کسب و کار یا شخص من را هدف قرار داده اند. هیچ رقابتی کسب و کار فوق العاده ای وجود ندارد که به احتمال زیاد به کسب و کار یا پایگاه کد آن هدایت شود. تهدیدات عادی هکرهای تصادفی، اسکریپتها و غیره همواره در حال حاضر هستند. هدف اصلی حمایت ها عبارتند از: ایجاد پرونده و یکپارچگی داده ها و تأیید. یک هدف جانبی این است که، به عنوان مثال، پذیرش PGP، و تشویق بیشتر افراد و کسب و کار، برای شروع استفاده از PGP به عنوان قاعده، به جای استثنا، ترویج شود. به نظر میرسد استفاده از درک شده به عنوان یک مشکل ساده کمک می کند، من بیشتر فکر می کنم که هدف و حفظ تعداد کلید های قابل مشاهده به حداقل در گواهینامه های PGP، به نظر می رسد "ادراک ساده" را افزایش دهند.

اهداف

من می خواهم برای ایجاد یک سیستم یا مجموعه ای از گواهینامه های PGP برای پشتیبانی از اهداف زیر:

  • کلید PGP برای امضای GITHUB به نام کسب و کار من (پروتکل کد)
  • کلید PGP برای دسترسی SSH به کسب و کار حساب کاربری GitHub (امنیت و راحتی)
  • کلید PGP برای کسب و کار برای امضای انتشار و توزیع نرم افزار، روشن یا خاموش GitHub (یکپارچگی کد)
  • کلید PGP برای کسب و کار به عنوان یک هویت دیجیتال – ایمیل و غیره – برای رمزگذاری و امضاي عمومي
  • جداسازی نگرانی ها در مورد ایجاد کد، توزیع کد و "کسب و کار به عنوان یک موجودیت" ایجاد کنید، به طوری که کلید ها می تواند مورد استفاده قرار گیرد:
    • ثبت نام مجوز به سایر مخازن
    • دسترسی به SSH به دیگر حساب ها، GitHub یا غیره
    • توزیع های ثبت نام نه 100٪ منابع داخلی
    • نشانه های دیجیتالی نشانه های مربوط به کد را ندارند
    • ایجاد یک دیجیتال هویت برای کسب و کار به عنوان یک نهاد است که به کد، GitHub یا نرم افزار آن گره خورده است
  • توانایی «بازنشسته شدن» یا جایگزینی هر یک از کلیدهای مورد استفاده در بالا بدون تأثیر بر دیگران
  • یک مجموعه مشابه از کلید های PGP که هویت من است به جای کسب و کار کاربرد دارد

علاوه بر این ، من ترجیح می دهم که منحنی بیضوی (Curve25519 / Ed25519) را به طور منحصرا به همان اندازه ممکن نزدیک کنم. البته ممکن است که منادی باشد که من باید از RSA استفاده کنم، و یک روش به ظرافت "بازگشت" به RSA به نظر می رسد قابل توصیه است. با این حال امیدوارم که تمام فعالیتهایی که من از کلید PGP استفاده می کنم قادر به پردازش منحنی های بیضی نباشید و قابلیت RSA هرگز مورد نیاز نیست.

برنامه

برای رسیدن به این اهداف، من یک جفت برنامه های موازی.

مجوزهای گواهینامه

برای برنامه هویت، در ابتدا، من فکر می کنم چندین گواهی PGP مجزا قابل اجرا است و با تقسیماتی که در بالا ذکر شد، مطابقت دارد: 19659011] یک گواهی برای کسب و کار، به عنوان یک نهاد، با توانایی صدور گواهینامه، امضا، تأیید هویت و رمزگذاری.

  • تمام UID ها فقط برای کسب و کار هستند و هیچیک از آنها به من و دیگر کارکنان متصل نیست
  • هیچ یک از کلید های زیر برای امضای نرمافزار، git commitments، توزیع یا غیره استفاده نمی شود
  • هیچ یک از کلید های زیر استفاده نمی شود برای احراز هویت در GitHub یا سایر مخازن کد
  • یک گواهی که به طور انحصاری برای امضای نرمافزار منتشر شده توسط این شرکت استفاده شده است
    • امضای به این معنی است که کسب و کار نقطه توزیع برای آن بسته است
    • امضای همچنین اجازه می دهد تا تایید یکپارچگی آن بسته
    • منبع اصلی نرم افزار ممکن است بخشی از " امضای
    • کدام کانال برای توزیع استفاده نمی شود مهم نیست
    • کد منبع یا دوبعدی لکه نیز مهم نیست
    • گواهی دارای کلید های زیر نیست با استفاده از auth یا رمزگذاری موجود
    • این گواهینامه توسط گواهی هویت کسب و کار بالا

      • تایید شده است

  • یک گواهی سوم برای GitHub استفاده شده است
    • گواهینامه دارای کلید های رمزگذاری استفاده نشده است
    • استفاده از مجوز و علامت در دو کلید جداگانه است
    • کلید عمومی auth تنها برای دسترسی به حساب GitHub از کسب و کار
    • هر دسترسی آینده به مخازن دیگر از یک کلید جدید جدید استفاده کنید
    • کلید زیر را برای امضای GIT اعمال می کند و تنها ادغام می کند، نه در GitHub منتشر می شود
    • این گواهی توسط هویت کسب و کار و گواهینامه های امضای کد در بالا تایید شده است
    • A کارکنان جدیدی که مرتکب اعمال می شوند، نیاز به یک گواهینامه دارند، اما از همه ی راه ها یکسان است، اما UID ها، به این یکی است.
  • یک گواهی جداگانه می تواند توسط یک کارمند که بتواند از طرف کسب و کار عمل کند
    • بطور کاربردی این همانند اولین گواهینامه است که UID ها آنها را بعنوان بخشی از کسب و کار شناسایی می کنند، اما نه خود کسب و کار (به صورت نام یا عنوان – مانند "فروش" یا "cfo"
    • گواهی توسط گواهی هویت کسب و کار تأیید می شود.

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

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

    الزامات گواهینامه

    نیمه دوم طرح من توسعه یافته است، که منطبق با یک "وفاداری" و " در صورتی که، و در صورت نیاز، این دستورالعمل ها برای هر گواهی PGP ساخته شده است:

    • کلید اصلی کلید ECC خواهد بود (Ed25519)
    • کلید اصلی [C] فقط فعال خواهد شد، هیچ [19659058]، [A]، یا [E] استفاده
    • اولین کلید (به طور خودکار ساخته شده) خواهد شد:
      • استفاده از یک نوع کلیدی به عنوان ECC اصلی (Curve25519 / Ed25519)
      • تنها هدف: [S]، [A] یا [E]، هرگز [SA] حتی اگر مجاز باشد
      • هدف انتخاب شده بستگی دارد که مورد استفاده کلید است
        • [A] برای گواهینامه هایی که عمدتا برای SSH یا استفاده مشابه از
        • [S] برای گواهینامه هایی هستند که عمدتا برای ارائه امضاهای دیجیتال
        • [E] برای گواهی هایی هستند که عمدتا به منظور استفاده عمومی برای افراد، (به احتمال زیاد برای ایمیل و ارتباطات دیگر مورد استفاده قرار می گیرد و من ترجیح می دهم که رمزگذاری را در زمانی که می توانم تشویق کنم)
        • [S] برای گواهینامه های عمومی برای بنگاه های تجاری که در آن نیاز به «امضای» چیزها و ارتباطات، برای رمزگذاری ارتباطات.
      • به محض اینکه ساخته شد، به پایان رسید
    • کلید های اضافی (همیشه حداقل یک مجموعه وجود دارد) عبارتند از:
      • تنها هدف: [S]، [A] یا [E]، هرگز [SA] حتی اگر مجاز باشد
      • همان نوع کلیدی به عنوان کلید اصلی، ECC (Curve25519 / Ed25519)
      • مجموعه با پایان دوره در محدوده 6-12 ماه (بسته به استفاده و قرار گرفتن در معرض، و غیره)
      • یک کلید اضافی ساخته شده با استفاده از همان، و کلید مقابل نوع RSA-4096
      • زیر کلید زیر است به محض اینکه ساخته شد، به عنوان منقضی شده

    به عنوان یک لایه اضافی از قابلیت «عقبنشینی»، هر یک از گواهیهایی که در بالا ذکر شد، توسط یک گواهی اضافی، با مجموعه یکسان از کلید های زیر، استفاده و انقضا، تکمیل می شود. تفاوت ها عبارتند از: 1) جایی که اول دارای کلید های ECC است؛ دومین دارای کلید های RSA است؛ 2) زیر کلید های ECC به جای کلید های RSA به پایان رسیده است و 3) خود گواهی نیز به پایان رسیده است (ساخت کلید های RSA غیرقابل استفاده غیر قابل استفاده است) برای کمک به ایجاد «بازگشت به عقب» برازنده، هر دو کلیدهای دیگر را تایید می کنند، و هر گواهی هایی که من برای تایید نسخه ECC نیز نسخه نسخه RSA را تایید می کنم. همچنین در هر زمان از گواهینامه ECC برای گواهی متصل شده مانند گواهینامه امضای کد بالا استفاده می کنم، همچنین از گواهی دوقلوی RSA برای تأیید گواهی همان استفاده می کنم. (بنابراین، هر "گواهینامه" شامل چهار امضا می شود: هر یک از دو کلید "گواهی" امضاء هر دو کلید "تایید شده"، بدون در نظر گرفتن اینکه در واقع UID (ها) هستند که امضا شده اند.)

    بحث [19659005] با داشتن همه زیر مجموعه ای از هر استفاده خاص، منقضی شده است، برنامه های مشتری را برای انتخاب یک کلید قابل استفاده انتخاب می کند، یا این که اخیرا برای آن استفاده می شود. اگر شرایطی را که در آن باید از RSA استفاده کنم، می توانم کلیدی مربوطه را بدون از دست دادن امضای قبلا ساخته شده و غیره استخراج کنم. در صورتی که من مجبور هستم برای تغییر کلید اصلی RSA (بعید، در my فکر می کنم)، من نیز یک موجود است که توسط کلید ECC که در حال حاضر در حال استفاده است استفاده می شود که آن را دوقلو است.

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

    از یک موضع موضع استفاده روزانه، Keyring فعال فقط دارای کلید های زیر است که ساخته شده اند برای هدف گواهی (هر دو کلید ECC و RSA) از کلید اصلی ECC. خود کلید اصلی، کلید اول ساخته شده به صورت خودکار ایجاد شده و کلیدهای master RSA دوقلو کامل باقی می ماند بر روی رسانه پشتیبان گیری.

    با تظاهرات و دقیقا مشخص کردن آنچه که در طرح به نظر می رسد در عمل، من یک تولید مجموعه گواهی های PGP. سپس GnuPG را برای لیست کلیدها و امضا از نقاط دید مختلف استفاده کردم. اول، سیستم تولید کلیدی است که همه چیز را به عنوان "به عنوان تولید شده" شناخته است. دوم این است که چگونه آنها را به کلاه ایمنی من، ECC certs و مقادیر محدودی که "in-keyring" نامیده می شوند وارد می کنند. لیستی از شش (سه دیدار با و بدون امضا) لیست شده اند که در لیست قرار داده شده است، به طوری که می توان آنها را در صورت لزوم "ببینیم منظور من چیست" (من می خواستم آنها را اینجا قرار دهم اما به نظر می رسد طول می کشد تا در سوال قرار گیرد.)

    سوال

    بنابراین، این دیوار متن پشتیبانی یک سوال:

    آیا من نادیده گرفته چیزی مهم است که نیاز دارد، و یا به شدت پیشنهاد می دهد، تغییر در راه حل من، و آیا باید آن را به یک راه بهتر انجام شد؟

    نوشته‌شده در

    رمزگذاری – این روش به ارسال ایمن EFAIL از پیام های رمزگذاری شده OpenPGP اجازه می دهد به غیر از خوانندگان ناامن EFAIL: TRUE یا FALSE

    مدیران: لطفا توجه داشته باشید که این یک نسخه از (آیا این یک حفاظت ساده در برابر EFAIL نیست؟)
    زیرا استراتژی متفاوت است که در ابتدای هر متن ساده به عنوان یک بلوک واحد رمزگذاری می شود.

    Background

    تهدید امنیتی EFAIL از اجرای ناقص استاندارد OpenPGP RFC0448 سوء استفاده می کند. بعضی توضیحات بسیار مختصر در زیر آمده است.

    در برخی از تاریخ های محدود در (امیدوارم) آینده ای نزدیک، اکثر مشتری های ایمیل بیش از کاربران GnuPG یک راه اندازی سیستم ایمنی خواندن EFAIL داشته باشند، اگر قبلا آنها را انجام ندهند. استاندارد OpenPGP به شدت اجرا خواهد شد.

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

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

    روش پیشنهادی

    توضیحات مختصر و ساده از حمله:

    هر کدام و هر بلوک رمزگذاری شده B از پیام رمزگذاری شده می تواند توسط داده های رمزگذاری شده psuedo تروجان قرار داده شود تا یک پیام رمزگذاری شده چند بلوک ABC را فراهم کند. قطعات A و C به صورت هوشمندانه انتخاب می شوند، به طوری که وقتی ABC رمزگشایی می شود، پیامی از شکل را ارائه می دهد:

    که نحو معتبر HTML با یک img برچسب، یک ویژگی src و یک مقدار مربوطه است که URL معتبر است. متن رمز گشایی رمزگذاری شده بلوک B در آدرس URL پس از آدرس معتبر مهاجم تعبیه شده است.

    بسته به برنامه نویسی و تنظیمات ایمیل مشتریان خواننده، سرویس گیرنده ایمیل به طور خودکار درخواست HTTP را به آدرس URL ارسال می کند ، باعث شده است که متن ساده B به مهاجم منتقل شود.

    این توضیح بیش از حد ساده تر شده است، که ظرفیت استراتژی EFAIL را غلط و غلبه می دهد. از این رو کافی است که یک استراتژی کاهش EFAIL نشان داده شود که این توضیح بیش از حد ساده را شکست می دهد.

    مهم: یک بلوک رمزگذاری یک اصطلاح فنی خاص است که به الگوریتم کدگذاری بلوک CBF اشاره دارد در RFC4880 13.9 حالت OpenPGP CFB. بلوک B دارای اندازه ثابت است (16 بایت برای تمام رمزهای AES)، و محدوده بلوک B در زمان رمزگذاری ثابت می شوند. مهاجم هیچ کنترلی بر انتخاب مرزهای بلوک ندارد و نمی تواند آنها را تغییر دهد.

    ابهام با استفاده از نحو HTML

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

    راه حل بسیار ساده است. متن ساده که در یک بلوک رمزگذاری می شود به دو بخش تقسیم می شود. این بخش اول رشته مبهوت کننده o است و قسمت دوم پیام m است. انتخاب o مانع از m از ویژگی ویژگی های مهاجم است

    به طور خاص، رشته obfuscating o باید حداقل سه کاراکتر تک نقل قول (')، نقل قول دو (و) و فضای () این به اندازه کافی برای خاتمه بسته شدن ویژگی HTML و حفاظت از پیام m است. این توسط مشخصات HTML تعیین شده است

    شما می توانید بازی را با مهاجمین انتخاب کنید که شروع به تعویض در این مثال سندبلاست Try jsoup (https://try.jsoup.org/٪7E_nyXks5PuAs-zJeek8CVhpuAvtI)

    هنگامی که توسط کاربر در قالب خام خود رمزگشایی شود، پیام کل قابل خواندن انسان خواهد بود. اما کمی زشت است، زیرا حاوی رشته مبهم است o ، اما از EFAIL امن خواهد بود.

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

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

    سؤال

    آیا شکل دیگری از رشته های HTML وجود دارد که توسط مهاجم برای غلبه بر پیشگیری از EFAIL پیشنهادی و اجازه دادن به انفیلتراسیون را می دهد؟

    این یک بحث باز پایان نیست که به

    • مسائل مربوط به پیاده سازی
    • مسائل ارگونومیک
    • حملات دیگر با استفاده از فرایند HTML مبتنی بر نیست [19659026] ضعف غیر EFAIL معرفی شده بدون فشرده سازی و / یا کاراکترهای ناشناخته کمتر در هر بلوک رمزگذاری. (این ممکن است محدود شود اضافه کردن کاراکترهای تصادفی اضافی به رشته obfuscating)

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

    بنابراین پاسخ ها باید محدود است که نشان می دهد که این روش می تواند شکسته شود.

    این را می توان پرش کرد: زمینه های اضافی در مورد آسیب پذیری EFAIL

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

    مرجع

    این روش و اجرای کاهش EFAIL در اینجا کمی عمیق در اینجا مورد بحث قرار گرفته است.

    نوشته‌شده در

    در OpenPGP، هنگام رمزگذاری با کلید عمومی – آیا امکان شناسایی کلید RSA وجود ندارد؟

    در OpenPGP هنگام رمزگذاری با کلید عمومی – آیا ممکن است ID کلید کلید RSA را به عنوان متن ساده در فراداده اضافه نکنیم؟

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

    من این کار را با OpenPGP.js انجام می دهم