Очень к сожалению: нет.
Шифрование почты обычно означает шифрование с открытым ключом. Это требует, чтобы получатель где-то опубликовал открытый ключ - его можно использовать для шифрования электронной почты. Этот ключ имеет секретную пару - закрытый ключ, который можно использовать для расшифровки писем.
Чтобы шифрование почты было практичным, почтовый клиент должен иметь возможность:
- При отправке электронной почты автоматически выбирайте открытый ключ получателя для шифрования сообщений.
- При получении электронной почты извлеките закрытый ключ пользователя с назначенного сервера, желательно, чтобы это был тот, кто предоставляет службу электронной почты (обычно провайдер ).
- При настройке учетной записи автоматически создайте и сохраните закрытый ключ.
Но большая проблема здесь - инфраструктура. Чтобы это произошло, должно быть:
- Широко используемый, стандартный способ публикации открытого ключа, связанного с адресом электронной почты (и этот метод должен быть защищен с помощью системы сертификатов, чтобы третье лицо не могло слишком легко с ним связываться).
- Широко используемый стандартный способ автоматического создания закрытого ключа для адреса электронной почты и его хранения на удаленном сервере, доступным стандартным способом. Предпочтительно, чтобы этот сервер был частью обычной службы от поставщика электронной почты. Адрес этого сервера будет затем вводиться как обычная процедура в настройках учетной записи почтового клиента, точно так же, как в настоящее время вводятся входящие и исходящие почтовые серверы, после чего клиент может обрабатывать все проблемы с ключами.
Другая проблема заключается в том, что большинству почтовых клиентов придется уметь обрабатывать расшифровку, а большинству поставщиков электронной почты придется предоставлять ключевую услугу, чтобы система была эффективной. Шифрование нуждается в полной поддержке на обоих концах связи. Но я не вижу в этом большой проблемы. Если на некоторых клиентах и серверах появится простой и практичный стандарт , они могут объявить «мы поддерживаем стандарт безопасной электронной почты», а другие, вероятно, последуют его примеру.
Также пользователь должен быть уведомлен о том, доступен ли открытый ключ для получателя. Хороший подход был бы при добавлении получателя, показывающего общий защищенный символ, такой как замок или синее свечение, используемое в соединениях SSL / TLS с веб-браузерами.
Конечно, альтернативный сервер закрытого ключа или даже просто файл ключа может быть сконфигурирован для почтового клиента, чтобы более параноидальный пользователь мог хранить свои собственные ключи где угодно. Для остальных из нас поставщик электронной почты мог бы читать электронные письма, поскольку они хранят закрытый ключ - но это все равно сделало бы связь очень безопасной. В конце концов, безопасность часто зависит от того, кому мы можем доверять.
Честно говоря, я действительно не знаю, почему этого еще не произошло. Это не так сложно. Получить с этим уже!