Дуже на жаль: Ні.
Шифрування пошти зазвичай означає шифрування відкритим ключем. Це означає, що одержувач має десь публікувати відкритий ключ - це можна використовувати для шифрування електронних листів. Потім у цього ключа є секретна пара - приватний ключ, який можна використовувати для розшифровки електронних листів.
Щоб шифрування пошти було практичним, клієнт електронної пошти повинен мати можливість:
- Відправляючи електронну пошту, автоматично завантажте відкритий ключ одержувача, щоб зашифрувати повідомлення.
- Отримуючи електронну пошту, забирайте приватний ключ користувача з призначеного сервера, бажано, це буде той, хто надає послугу електронної пошти (як правило, Інтернет-провайдер ).
- Під час налаштування облікового запису автоматично створюйте та зберігайте приватний ключ.
Але більша проблема тут - інфраструктура. Щоб це сталося, треба було б:
- Широко використовуваний, стандартний спосіб публікації відкритого ключа, пов’язаного з адресою електронної пошти (і цей метод повинен бути захищений за допомогою системи сертифікатів, щоб третя сторона не могла з цим легко поплутатися).
- Широко використовуваний, стандартний спосіб автоматичного створення приватного ключа для адреси електронної пошти та зберігання його на віддаленому сервері, доступному стандартним способом. Переважно, цей сервер був би частиною звичайної послуги від постачальника електронної пошти. Адреса цього сервера буде введена як звичайна процедура в налаштуваннях облікового запису клієнта електронної пошти, подібно до того, як сьогодні вводяться вхідні та вихідні сервери електронної пошти, після чого клієнт може впоратися з усіма клопотами з клавішами.
Інша проблема полягає в тому, що більшість клієнтів електронної пошти повинні мати можливість обробляти дешифрування, і більшість постачальників електронної пошти повинні мати ключову послугу, щоб система була ефективною. Для шифрування потрібна повна підтримка на обох кінцях зв'язку. Але я не вважаю це великим питанням. Якщо на деяких клієнтах і серверах з’явиться простий і практичний стандарт , вони можуть рекламувати «ми підтримуємо стандарт захищеної пошти електронної пошти», а інші, ймовірно, будуть відповідати цьому.
Також користувачеві доведеться повідомити про те, чи доступний одержувач відкритим ключем. Хорошим підходом було б додавати одержувача, показуючи загальний захищений символ, наприклад замок або синє світіння, що використовується у з'єднаннях SSL / TLS з веб-браузерами.
Звичайно, альтернативний сервер із приватними ключами або навіть просто файл із ключами може бути налаштований на клієнт електронної пошти, щоб більш параноїдальний користувач міг зберігати свої власні ключі, де він захоче. Для решти нас постачальник електронної пошти все ще може читати електронні листи, коли вони зберігають приватний ключ - але це все одно зробить зв’язок дуже безпечним. Зрештою, безпека часто стосується того, кому ми можемо довіряти.
Чесно кажучи, я справді не знаю, чому цього ще не сталося. Це не так складно. Приступайте до цього вже!