PGP. Генерировать на коленке. Читать https://www.pgpru.com/

А как же доверенные центры?

В PGP работает модель сети доверия. По ссылке всё это есть.

По поводу сертификатов (S/MIME, x.509) ничего сказать не могу. В принципе, PGP — стандарт де-факто, и S/MIME с ним конкурирует не очень бодро.

Совсем забыл, для PGP ещё придумали глобальный каталог, который хотя бы проверяет соответствие e-mail открытому ключу: http://keyserver.pgp.com/vkd/GetWelcomeScreen.event Но лучше всё же попросить кого-нибудь из друзей IRL подписать твой ключ.

>Где можно получить

В центре сертификации... //Ваш КО.

Кроме того, тебе же нужен не абы-какой сертификат, а выданный известным CA. Так что список крайне ограничен... И не все физиками занимаются.

Ну и не в России, ессно. Если, конечно, тебя ГОСТ не интересует.

> Допустим, хочу иметь на руках пару private key-public key

Проблемы? Генератор в руки...

и цифровую подпись

Цифровую подпись чего?

Где можно получить (у центра, а не...

Могу поднять у себя центр сертификации и подписать ваш сертификат. Сойдет?

>Совсем забыл, для PGP ещё придумали глобальный каталог, который хотя бы проверяет соответствие e-mail открытому ключу: http://keyserver.pgp.com/vkd/GetWelcomeScreen.event

мой ключ не находит, так что в топку.

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

чем это лучше традиционной схемы?

Тем, что не позволяет третьему лицу опубликовать свой открытый ключ с твоим e-mail. ИМХО, как замена сети серверов ключей оно не годно. Да, ещё там можно удалить ключ.

Еще 2 вопроса:
1. Как связать полученный PGP-ключ с Gmail'ом (веб-интерфейсом)?
2. Если по вебке нельзя, а только через thunderbird/evolution/etc., тогда (немного оффтопик) - как в evolution, например, настроить только отправку почты - чтобы он не делал синхронизацию, не качал весь почтовый ящик на локальную машину, а просто чтобы была возможность с данной машины и с данного аккаунта отправлять письма?

>> Как связать полученный PGP-ключ с Gmail'ом (веб-интерфейсом)?

FireGPG (аддон к лисе).

как в evolution, например, настроить только отправку почты - чтобы он не делал синхронизацию, не качал весь почтовый ящик на локальную машину, а просто чтобы была возможность с данной машины и с данного аккаунта отправлять письма?

Эм… Не использовать IMAP? :)

>Тем, что не позволяет третьему лицу опубликовать свой открытый ключ с твоим e-mail.

третьему лицу, публикующему свой открытый ключ с твоим e-mail никто не подпишет этот ключ, т.к. e-mail чужой, сеть доверия не построится. нет?

>> третьему лицу, публикующему свой открытый ключ с твоим e-mail никто не подпишет этот ключ, т.к. e-mail чужой, сеть доверия не построится.

Да. Тем не менее, всегда существует вероятность, что кто-то не глядя выразит доверие ключу (ССЗБ, да): подлинный ключ устарел, владелец прозевал, злоумышленник создал и опубликовал свой. Таких сценариев можно придумать много.
Вообще, выше я не пытался сказать, что централизованный каталог намного безопаснее, но он добавляет удобства (хотя бы то же удаление ключей, которое является неизбежным геморроем кейсерверов).

>Вообще, выше я не пытался сказать, что централизованный каталог намного безопаснее, но он добавляет удобства.

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

хотя бы то же удаление ключей, которое является неизбежным геморроем кейсерверов.

А зачем их удалять? Отозвал и все.

централизация хранения и даже выдачи сертификатов не только не полезна, а наоборот - вредна.

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

А зачем их удалять? Отозвал и все.

Отзыв и так подразумевается. Вообще, более актуальна проблема с неудаляемыми ID, которые будут копиться и копиться. Это меня потянуло не туда, и я вспомнил об удалении ключа, а не ID.

>Да кто ж спорит :) Но здесь ситуация даже близко не такая хлипкая, как с сертификатами — даже поломав каталог, злоумышленник не сделает ничего страшнее тех вещей, которые можно сделать без оного.

какая смысловая нагрузка этого каталога, если все равно на него полагаться нельзя (а вдруг поломали? ЭЦП в его выдаче о том, что ключ валиден нет же наверняка?), а проверять валидность ключа придется по старинке - через trustdb.

Отзыв и так подразумевается. Вообще, более актуальна проблема с неудаляемыми ID, которые будут копиться и копиться. Это меня потянуло не туда, и я вспомнил об удалении ключа, а не ID.

а я через полгода после удаления захочу почитать какой-нибудь древний mail-list, найду там подпись, а проверить не смогу, т.к. кто-то умный удалил ID с сервера.

Убедил :)

Попытаюсь разжевать, пока есть пара свободных минут

> как в evolution, например, настроить только отправку почты - чтобы о не делал синхронизацию, не качал весь почтовый ящик на локальную машину, а просто чтобы была возможность с данной машины и с данного аккаунта отправлять письма?

IMAP? Поставь claws-mail. Там отруби проверку ненужных папок. (например «вся почта» -> ПКМ -> Свойства -> [ ] Проверка на наличие новых сообщений). И в настройках учетки укажи в качестве папки исходящих (очереди) локальную папку, иначе несекьюрно (для этого надо создать локальный почтовый ящик через меню Файл).

В итоге claws-mail будет периодически проверять *список* новых сообщений на сервере, аггрессивно кешируя его. Сами сообщения скачивать не будет. Первый раз потормозит, потом норм. Ещё можно врубить экономию трафика imap (учетная запись -> получить -> [x] режим экономии траффика).

S/MIME, X.509, PGP-key?

Для какой задачи? Если для себя (почту шифровать, файлы и другие задачи) - то однозначно сгенерить GPG-связку ключей. Из консоли или через seahorse или другие gui-проги.

Х.509 - это не ключ, и даже не алгоритм шифрования. Это стандарт для иерархической централизованной модели управления ключами с доверенным центром и сертификатами. Краткая суть его: есть некоторое лицо, которому доверяют все стороны. Это доверенный центр, СА. Стороны хотят друг с другом безопасно контачить. СА ставит подпись на ключах сторон (или одной стороны - сервера). В итоге получается сертификат, который говорит что ключ с таким-то хешем дествительно принадлежит такому-то лицу. Понятно? Всё, остальное знать не надо.

Если имеешь в виду SSL, то нужно сгенерить RSA PRIVATE KEY, сделать на его базе csr-файл (Certificate Request), отправить csr на валидацию в CA и получить на выходе сертификат с подписью CA.

S/MIME

В живую никогда не сталкивался.

Расскажите, пожалуйста, про публичные ключи и цифровые подписи

В ходе генерации рождается два связанных ключа. Они связанны таким образом, что один из ключей может зашифровать какие-то данные, второй может эти данные расшифровать. И наоборот. То есть изначально оба ключа взаиморавноценны. При этом из одного ключа нельзя родить второй за полиномиальное время. Это ассимитричное шифрование.

Затем один ключ принимают за секретный. Второй - за публичный. Ну чисто взяли и решили, сырые ключи изначально равноценны.

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

Чтобы эти данные нельзя было подменить, в файл с публичным ключом и данными владельца добавляется цифровая подпись этих данных.

- В случае GPG - источником подписи является секретный ключ владельца, в итоге получается самоподписанный ключ, который нельзя изменить не имея секретного ключа.

- В случае X.509 - подпись ставит СА с помощью собственного секретного ключа. То есть ты передаешь .csr-файл, и получаешь сертификат с подписью СА.

Что такое шифрование? Это некая математическая функция
: encrypt(Data, PublicKey) -> EncryptedData.
где Data - шифруемые данные. Ну берет данные и тело публичного ключа, производит некоторые манипуляции, генеря на выходе некоторую последовательность байт. Это и есть зашифрованные данные. Шифруется публичным ключом, значит получатель сможет расшифровать эти данные только с помощью связанного секретного ключа.

Что такое цифровая подпись (ЭЦП)? Это та же функция, но с другими аргументами:
: encrypt(Hash, SecretKey) -> Signature.
где Hash - это хеш (md5,sha,etc) от Data, т.е. хеш-сумма от подписываемых данных. Как видишь, хеш-сумма шифруется секретным ключом. Это значит, что для проверки подписи, проверяющий расшифровывает зашифрованный хеш с помощью публичного ключа и одновременно пересчитывает хеш от подписанных данных. Если оба хеша совпадают, то подпись верна.

В модели GPG действует модель сетей доверия. У тебя есть друг Вася. У тебя есть публичный ключ Васи, которому ты доверяешь. У Васи есть знакомый Петя. Тебе нужно законтачится с Петей через интернет.

Вася ставит свою подпись на публичном ключе Пети, а затем Петин подписанный публичный ключ попадает к тебе по какому-то [незащищенному] каналу (от Пети, или от Васи, или вообще с левого сервака). Ну ты видишь подпись Васи на ключе и тем самым понимаешь, что полученный ключ Пети действительно принадлежит Пете: Вася ведь ручается. Ну и ты можешь подпись поставить на любом ключе и тоже его отправить кому угодно.