мини-софт для pgp

SATtva Спасибо за ответ. Нашел сорец:
unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=__16384__;
Но собрать не получается. Ну да ладно. Меня больше заинтересовала действительная их надежность.
т.е. к примеру, если я буду вести переписку по XMPP, при этом у меня и у собеседника будет длинный кей – все будет дико тормозить? Или это будет тормозить только на действительно старых машинах?
Спасибо.

Если вам не принципиален именно стандарт OpenPGP, то можете использовать для заявленных в топике целей OpenSSL.

если я буду вести переписку по XMPP

а что (Pidgin+OTR или PSI+gnupt)+Tor не подойдут? все может быть портабельным.

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


Там безальтернативно AES128, что не очень, + протокол сделан так, что писать в оффлайн нельзя.

а что (Pidgin+OTR или PSI+gnupt)+Tor не подойдут? все может быть портабельным.

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

Меня больше заинтересовала действительная их надежность.

Если Вы не понимаете, в чём разница между надёжностью 4096-битового ключа и 16384-битового, то последний Вам не нужен. В любом случае никто не будет добывать открытый текст путём взлома ключа. Прочитайте хотя бы это и это.

т.е. к примеру, если я буду вести переписку по XMPP, при этом у меня и у собеседника будет длинный кей – все будет дико тормозить? Или это будет тормозить только на действительно старых машинах?

На современном десктопе разница практически не будет заметна.

при общении в джаббере с использованием длинных ключей

в Psi почти не видно.

Вам лично они может и не будут плохи, а серверам ключей может поплохеть. Или пользователям, которые держат большие связки на сотни-тысячи ключей.
Даже на ключах обычной длины пересчёт индексов доверия в такой базе занимает ощутимое время.

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

Будучи неподкованным – наплодил ключей, соответственно приваткеи посеял, как с сервера удалить их? я им могу написать с почты, которая указана у меня. Что еще посоветуете?
А по теме: есть очень клевый фронтенд, написанный на шарпе, сорцы открыты, размер приличный, вот только на семерке запускаться не хочет. Может подправите кто-нить?)
http://gnupgk.svn.sourceforge.net/viewvc/gnupgk/

наплодил ключей, соответственно приваткеи посеял, как с сервера удалить их?

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

А есть владельцу сервера написать с почты, на которою привязанны ключи?
Сервер http://pgp.mit.edu/
Подскажите, может есть какой-то выход?

Вот поэтому и разрабатывают квантовые каналы

А разве квантовые каналы используются не только для распределения ключей? То есть, в конечном счете, все ведь опирается на стойкость алгоритмов шифрования?

Подскажите, может есть какой-то выход?

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

зы: да можно аннулировать .. если привязаны к почте.

А есть владельцу сервера написать с почты, на которою привязанны ключи?

Вы не понимаете, как работает PGP. Это не волшебник-админ, который сидит и кликает «ключ удалить» / «ключ опубликовать». Есть связка PGP-ключей, которая взаимно зеркалируется на куче серверов. Даже если администратор удалит руками какие-то ключи со своего зеркала, они туда будут тут же загружены с других серверов при синхронизации. Смысл состоит в том, что доверие к ключам строится не на доверии к серверу ключей, а на доверии к подписям на ключе и параметрам ключа, которые определяет сам его владелец и никто иной. Если ключ опубликован где-то в интернете, кто-то может иметь его копию и повторно отослать на любой сервер ключей — это ничему не противоречит. Если хочется пометить ключ, как более неиспользуемый, надо его отозвать и после этого повторно загрузить на сервер ключей. Запомните: подписи с PGP-ключа не пропадают, но только добавляются новые — таков протокол. Грубо говоря, если вы подписали ключ, а потом отозвали, а потом снова подписали, и после каждого из этих шагов ключ загружался на сервер, то любой сможет увидеть по ключу все 3 этих шага, что вы над ним делали. Система не забывает ничего. И отозванный ключ — просто финальная пометка поверх всего на предмет того, что пользоваться им не надо, вот и всё. Прочитайте /comment2787.

Сервер http://pgp.mit.edu

Были некоторые исключения — серверы ключей, которые не участвуют в кольце серверов ключей. Кажется, это (когда-то) касалось коммерческого сервера на pgp.com. Другой пример — местный сервер клчюей на этом сайте. Про всё остальное описано выше.

Подскажите, может есть какой-то выход?

Разбомбить все дата-центры с серверами, где могут храниться и зеркалироваться ваши ключи, но надёжнее — уничтожить все компьютеры и носители информации в мире. Если бы у вас ещё был доступ к приватному ключу, то можно было бы ключ отозвать и повторно загрузить на сервер. Если же доступ к приватному ключу утерян, то нельзя сделать ничего — вы ничем не отличаетесь от злоумышленника, у которого нет доступа к вашим ключам.

Мыло, указанное в ключе — не более, чем информационное поле, там можно вбить, что угодно. И было бы крайне глупо в защите ключа полагаться на доступ к почте. А вдруг вашу почту сломали или её админ разгласил пароль / данные с неё? А вдруг вы указали чужую почту в своём ключе? Абсурд.

А разве квантовые каналы используются не только для распределения ключей?

Каналы — это такая функция/отображение, а распределение ключей — это протокол QKD. Да, каналы, как просто полезный математический объект, используются много где, не только для распределения ключей. Однако, QKD используется лишь для шифрования канала передачи данных, а для шифрования уже переданных данных (на диске) оно бессмысленно — тут работает только классическая криптография.