Comments
Ого, нас ждет аж целых три статьи предыстории к рекламе очередного прорывного криптопродукта, использующего «современные алгоритмы шифрования (RSA, AES, BlowFish и др)»? А там тоже в бесплатной версии размер ключа будет лишь 1024 бита, а в Ultimate аж 8192? Это так мило, аж слёзы наворачиваются.
Спасибо за обзор всё равно. Для начинающих познавательно будет.
У нас собственный сервер ключей, но мы рассмотрим возможность интеграции нашей программы с keybase.io. Спасибо за отзыв!
Немного не понял. То есть как вариант с «зашифровать информацию архиватором с паролем» — есть надежная защита от злоумышленников или полиции? Не кажетсямне этот способ довольно надежным… Смысл замарачиваться с TC и подобными программами, если можно просто все засунуть в архив и поставить пароль?
Вы хотите, что бы я передал вам важный документ. Я беру ваш публичный ключ, шифрую его и теперь открыть его сможете только вы. Да же я его уже открыть не смогу. (я имею ввиду зашифрованную копию)

Эм… речь в статье шла, цитирую

«Самый простой способ защиты электронной почты — это использование симметричного шифрования. Для его реализации можно использовать плагины браузера SecureGmail и Encrypted Communication или вообще обойтись без них, а использовать программы, позволяющие создавать архивы, защищенные паролем (например, WinRAR, 7-Zip). Расчет прост: вы защищаете архивом файл, помещаете в него сообщение с возможными вложениями и отправляете другому человеку. „

Про открытые и закрытые ключи я в курсе, спасибо. Вопрос именно про архивы с паролем. _ФАЙЛЫ_ же, если мне не изменяет память, так же можно шифровать при помощи PGP.
Тогда еще раз вопрос, а то он непонятен. По крайне мере мне.

Файлы можно шифровать PGP и?
Будет ли зашифрован архив с паролем? Да будет еще раз зашифрован архив с паролем.

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

Ваш способ более сложный, надо создать файл, написать в нем, зашифровать и отправить той же почтой.
Можно все сделать это сразу в почте.
На вскидку 3 почтовых сервиса, где не требуют ввода номеров телефона и запасных email адресов + есть шифрование.
https://scramble.io/
https://unseen.is
https://www.openmailbox.org/webmail/

На scramble.io и unseen.is шифрование работает без нареканий, приватные ключи хранятся локально.
На openmailbox.org 4 месяца назад мне не удалось заставить работать шифрование, может сейчас поправили.

Есть еще https://protonmail.ch, но туда только пока по приглашению.
Вы рассмотрели закрытую проприетарную программу PGP, но не стали рассматривать сторонние реализации OpenPGP. Если PGP действительно прозрачно для почтового клиента делает расшифровку писем, то конечно это плохо, так как plaintext хранится на жёстком диске. PGP как продукт — плох и не подходит, как минимум, из-за закрытости кода. Но OpenPGP ничем не хуже (по моему даже лучше из-за того что не надо использовать PKI (PKI это бизнес-модель)) и используя множество почтовых клиентов которые умеют «общаться» с GnuPG у вас не будет на жёстком диске хранится дешифрованные данные.

Заявления в выводах о «наиболее надёжном» S/MIME не подтверждены технически ничем. Если ваша конкретная почтовая программа с конкретным PGP продуктов сохраняет данные в открытом виде, то это
проблемы программы и конечной релизации, а не PGP системы в целом. Уверен что можно найти S/MIME почтовые клиенты которые будут сохранять данные в открытом виде. Решение с почтовым клиентом поддерживающим из коробки GnuPG например имеет все заявленные вами преимущества S/MIME и не имеет недостатка в виде PKI в котором как-то надо получить сертификат. К достоинствам OpenPGP я бы добавил ещё то что он может использоваться и просто для шифрования/подписи файлов, независимо и вне контекста электронной почты, тогда как S/MIME используется только в её пределах (иначе бы пришлось шифровать файл, допустим, 7-zip-ом, а ключ (пароль) симметричный передать по S/MIME почте). PGP можно использовать и в instant messenger-ах, с теми же самыми ключами (хотя конечно лучше OTR, Axolotl и подобные протоколы). В итоге OpenPGP (GnuPG реализация как пример) в целом удобнее получается, шире возможности.

Большинство почтовых клиентов имеют не свою собственную OpenPGP реализацию, а используют внешние инструменты в виде GnuPG. В итоге у кучи клиентов одна, хорошо известная и старая (в плане проверенности временем) реализация стандарта. Тогда как S/MIME многие реализуют регулярно самостоятельно (не без помощи OpenSSL и подобных библиотек конечно). С точки зрения аудита кода это плохо, потенциально менее безопаснее.

Насколько вижу, то в S/MIME вовсю до сих пор используется SHA1, который официально deprecated и не рекомендован к использованию. OpenPGP позволяет сделать выбор среди много каких алгоритмов и уже давно SHA2 доступен и широко используется. S/MIME имеет скудный выбор алгоритмов шифрования и хэширования.

Сравнивать «надёжность» симметричных и асимметричных алгоритмов вообще очень странно. Симметричная и асимметричная криптографии вообще просто выполняют разные задачи и поэтому сравнение не имеет почвы. В одном случае вам придётся как-то найти способ передать пароль, в другом случае вам придётся найти способ передать/подтвердить публичный ключ для проверки подписи. Если вы подразумевали что надёжность выше из-за того что программа за пользователя как бы сгенерирует пароль/ключ для шифрования — то тогда ok, но из текста это не ясно и вводит заблуждение, так как на одной чаше весов у вас «симметричная криптография», а на другой «асимметричная», хотя и S/MIME и PGP шифруют симметрично вообще-то всё.
Конечно, есть и недостатки:
Главная проблема S/MIME — какой программой сгенерировать сертификат?

В чем проблнма? На любом УЦ можно получить, например, CAFL63.


Каждому адресату нужно предоставить свой открытый ключ.

Так он лежит в каждой подписи.


Упустили KMail


KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME.
Only those users with full accounts are able to leave comments. Log in, please.