Теперь я понял, почему почти никто не шифрует свою почту

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!



Шифрование электронной почты — трудная и болезненная процедура. Недавно я сам понял, насколько. Одна моя знакомая, очень продвинутая в сфере информационной безопасности, прислала мне свой открытый ключ PGP и попросила перейти на шифрование. Нет, она не из АНБ или ЦРУ, просто обычный человек, который заботится о своей конфиденциальности. Я никогда раньше не отправлял зашифрованные письма, но подумал: «Почему бы и нет?» Много лет я хотел это освоить, но не с кем было обмениваться шифрованными письмами.

Я начал с установки GnuPG на свой компьютер под Linux.

GnuPG похож на PGP в том, что использует открытые и закрытые ключи для шифрования и дешифрования, но поставляется открытым исходным кодом и идёт в комплекте со многими дистрибутивами Linux. Другая версия PGP с открытым исходным кодом — OpenPGP.

GnuPG для Windows под названием Gpg4win можно загрузить с официального сайта. Я выбрал общий метод шифрования и дешифрования сообщений, который не привязан ни к какому провайдеру электронной почты, потому что не хотел ограничивать себя возможностью шифрования только у одного провайдера. Кроме того, единственный способ убедиться, что даже почтовый провайдер не имеет доступа к вашим письмам — шифровать их самостоятельно. Наиболее полное руководство по GnuPG я нашёл на сайте How-To Geek.

Я импортировал открытый ключ своей знакомой с помощью этой команды:

gpg --import her_public_key_file.key

В этой команде her_public_key_file.key заменяется фактическим файлом открытого ключа. Затем проверил, что её ключ успешно импортирован:

gpg --list-keys

Появилось сообщение вроде этого:

pub 2048R/FFE7947D 2019-10-11 [expires: 2021-10-10]
uid her_email@her_email_provider.com
sub 2048R/AB48FEC2 2019-10-11

Это означает, что GnuPG распознаёт её открытый ключ как действительный и сохраняет его для последующего использования.

Затем подписал её открытый ключ:

gpg --sign-key her_email_address@email_provider.com

Подписание открытого ключа говорит GnuPG, что вы доверяете этому ключу, то есть он действительно пришёл от этого человека. Каждый открытый ключ должен быть подписан, прежде чем сообщения от владельца этого открытого ключа можно будет расшифровать. По-моему, этот шаг не имеет никакого смысла. Зачем вам импортировать ключ, если вы не считаете, что он пришёл от нужного человека?

Затем я попытался сгенерировать свои ключи:

gpg --output ~/temp.key --armor --export My Name 

Ну, после такой команды выскочило сообщение об ошибке, что обнаружен конец новой строки. Я подумал, что это может быть связано с пробелами в моём имени и между именем и адресом электронной почты, поэтому попробовал различные форматы. Примерно через час и множества неудачных попыток, некоторые из которых выглядели как успешные, но не были таковыми, я наконец нашёл правильную команду:

gpg --gen-key

Приведённая выше команда выдаёт вам ряд вопросов. На первый я выбрал вариант «1», затем выбрал опцию 2048-битной длины ключей. Установил бессрочный срок действия ключей. В поле имени не указывал фамилию, но пробелы там тоже поддерживаются: можно указать и имя, и фамилию. Затем ввёл свой электронный адрес. Поле комментария оставил пустым. И, наконец, ввёл длинную парольную фразу. «Парольная фраза» — это просто синоним пароля. Я его записал там, где он не потеряется. На самом деле, я поместил его в файл, зашифрованный с помощью Truecrypt. Парольная фраза понадобится позже, чтобы зашифровать сообщения и в случае повторной установки GnuPG на жёсткий диск и повторного импорта ключей. И не забудьте сделать резервную копию самих ключей!

После создания ключей проверяем результат:

gpg --list-keys

Эта команда выдаёт примерно такой результат:

pub 2048R/FFE7947D 2019-10-11 [expires: 2021-10-10]
uid her_email@her_email_provider.com
sub 2048R/AB48FEC2 2019-10-11


pub 2048R/3A785D3F 2020-02-22
uid My Name
sub 2048R/A7B384FE 2020-02-22

Я дважды запускал генерацию ключей, потому что не был уверен, этот результат означает наличие пары открытого/закрытого ключей или только одного ключа. Каким-то образом я в конце концов понял, что создал две пары ключей, поэтому удалил вторую пару.

Затем я попытался экспортировать свой открытый ключ в файл. Открытый ключ нужно отправить каждому, кому вы отправляете зашифрованное письмо, чтобы он мог его расшифровать. Я не уверен, какую команду использовал, но она выдала текстовый файл, который начинается с -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1. Я отправил это письмо своей знакомой, и она ответила мне зашифрованным сообщением.

Я попытался расшифровать файл message.asc с её письмом:

gpg --decrypt message.asc > plain.txt

Но GnuPG выдал сообщение об ошибке, что не может найти секретный ключ:

gpg: encrypted with RSA key, ID XXXXXXXX
gpg: decryption failed: secret key not available

Но я видел свой секретный ключ. Я мог даже экспортировать его. Я знал, что он есть! Что тут сказать, иногда программисты пишут действительно ужасные сообщения об ошибках. К этому моменту я уже начал испытывать некоторое раздражение.

Я не знал, что сделал неправильно. Единственное, что я мог предположить, что я каким-то образом не смог правильно создать ключи. Либо так, либо я экспортировал не тот открытый ключ. Поэтому я решил начать всё сначала. Удалил свою пару ключей, сгенерировал новую пару ключей и экспортировал свой открытый ключ в файл с помощью такой команды:

gpg --output ~/my_public_gpg_key.key --armor --export My Name my-email@my-email-povider.com

Затем отправил знакомой новый открытый ключ. Параметр --armor указывает GnuPG создать файл открытого ключа в текстовом виде. Название файла — my_public_gpg_key.key.

Она опять зашифровала своё сообщение и отправила его мне. Когда я попытался расшифровать его, то опять увидел то же самое сообщение об ошибке:

gpg: encrypted with RSA key, ID XXXXXXXX
gpg: decryption failed: secret key not available

На этот раз я заметил, что идентификатор ключа соответствует моему старому открытому ключу, а не новому. Я решил, что она ошиблась, и попросил её попробовать еще раз с новым ключом. Затем, чтобы убедиться, что я не ошибся, я решил проверить, что ключ, которым я воспользовался, действительно был моим новым ключом. Новый ключ, который я послал, даже не был одним из моих открытых ключей! Это был её открытый ключ, который начинался с -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1! Каким-то образом я экспортировал её ключ с добавлением Version: GnuPG v1! Я это знаю, потому что у меня по-прежнему был файл с её ключом, который она мне прислала, и он начинается с -----BEGIN PGP PUBLIC KEY BLOCK-----. Там нет Version: GnuPG v1! И её открытый ключ совпадает с тем, который я ей послал.

Я повторно экспортировал свой открытый ключ с помощью той же команды, указанной выше. На этот раз я проверил, что это действительно мой ключ, прежде чем отправить его ей по электронной почте. Из справочных материалов по GnuPG в интернете я узнал, что сообщение об отсутствии секретного ключа может появиться, если люди используют разные версии GnuPG. Я упомянул об этом ей, когда отправил новый ключ по электронной почте.

Через несколько недель я получил ответное письмо. К этому времени я уже решил, что она сдалась. В течение последующих недель у меня были некоторые проблемы с компьютером, из-за которых пришлось переформатировать жёсткий диск. Поэтому пришлось заново установить GnuPG, повторно импортировать мои ключи и повторно импортировать её открытый ключ. К счастью, я сделал резервные копии! Затем я ответил на её последнее письмо другим письмом, которое зашифровал с помощью этой команды:

gpg --encrypt --sign --armor -r her-email@her-email-provider.com --passphrase my-pass-phrase my-msg.txt

Конечно, здесь не мой настоящий пароль, я заменил его на my-pass-phrase, а незашифрованное сообщение — на my-msg.txt. Был сгенерирован шифротекст, и его файл назывался my-msg.tx.gpg. Я не смог найти никакой информации, как самому расшифровать свой собственный шифротекст, поэтому пришлось отправить его ей, не зная, правильно ли я его зашифровал. Я знал только то, что он вроде был правильного размера. Через пару недель я получил от неё новое зашифрованное письмо на другую тему. Только тогда появилась уверенность, что я наконец достиг той точки, когда мы можем успешно общаться по зашифрованной электронной почте. Весь процесс от начала до конца занял больше месяца! Я всё ещё пытаюсь автоматизировать команды GnuPG, чтобы использовать их, не слишком сильно задумываясь о том, что я делаю.

Из этого опыта я понял, что зашифрованная электронная почта, хотя и является интересным упражнением, не очень практична. Если только вы не Эдвард Сноуден, за которым следит АНБ, вероятно, вряд ли вы сможете оправдать усилия на создание и использование зашифрованной почты. И если вы не Эдвард Сноуден с важными секретами, вряд ли кто-то захочет тратить силы на шифрование переписки с вами.

Шифрование и дешифровка электронной почты, как у меня с GnuPG, просто слишком утомительны. Поскольку я уже потратил на это слишком много усилий, то продолжу использовать её для общения со своей онлайн-знакомой. Но я бы не рекомендовал обычному человеку использовать GnuPG для шифрования электронной почты, если этого можно избежать. Понимаю, что на рынке есть более простые решения от конкретных почтовых провайдеров, таких как Protonmail, но большинство людей не захотят менять провайдера, чтобы воспользоваться ими. Нам всем нужен более простой способ отправки и получения зашифрованной почты без изменения почтового провайдера. GnuPG — не решение проблемы. Если вы знаете о более простом способе шифрования почты, пожалуйста, подумайте о том, чтобы оставить комментарий.
Источник: https://habr.com/ru/company/globalsign/blog/498592/


Интересные статьи

Интересные статьи

Как вы понимаете, это крик души. Уже больше года я «счастливый» обладатель 13-дюймового Macbook Pro 2019 года за 170 тысяч рублей. Когда я его покупал, я естественно знал, что у этих...
Вместо привычных дайджестов избранных постов из нашего блога сегодня пробуем новый TL;DR-формат — рассказываем все самое главное из каждого материала. Если захотите детально изучить п...
Продолжаем нашу подборку интересных материалов (1, 2, 3, 4, 5, 6). На этот раз предлагаем послушать курс об алгоритмах интеллектуальной обработки больших объёмов данных и два новы...
Сразу хочу сказать, что речь в статье пойдёт исключительно о настольном применении Линукса, т.е. на домашних компах/ноутах и рабочих станциях. Всё нижеизложенное не касается Линукса на серверах, ...
Написание алгоритмов наверное самая для меня интересная часть в домашней автоматизации. Но даже вся масса сенсоров и сценариев не справляется с буйной фантазией жизни и приходится добавлять спо...