РегистрацияПодключи: объясните на пальцах, pls
Я полагал, что понимаю как устроены ключи [open]pgp и каковы принципы работы этой системы.
Секретный ключ S[ecure] – хранимое в тайне и безопасности дополнение ключа P[ublic] открытого.
Связь между S и P – забота владельца.
К ключу P прицеплены всякие реквизиты владельца – имя, емейл, фото и т.п.
Эта связь между Р-ключом и реквизитами утверждается подписью владельца, созданной S-ключом, а подтверждается подписями других людей.
S используется для подписывания и расшифрования, P для шифрования и проверки подписи. Всё наглядно и логично.
Как в эту схему вписываются подключи?
Понятно, что каждый подключ – это все же S-P _пара_ ключей.
_Зачем_ это делается, я в общих чертах понял.
https://www.pgpru.com/chernowi.....mi/podkljuchiopenpgp
А вот дальше всё тонет в тумане непонимая.
Чем определена и подтверждена связь между главным ключом и подключами?
Почему это стало обязательным? PGP версий 9.x вообще не позволяет создать S-P-пару без подключей. Позволяет создать сколько угодно подключей, но не дает возможности выбрать какой именно [под]ключ надо использовать для той или иной операции.
комментариев: 11558 документов: 1036 редакций: 4118
Подписями, как и в случае записей сертификата и прочих метаданных типа списка предпочтений.
комментариев: 27 документов: 9 редакций: 3
Подписями
Подпись владельца всей этой конструкции, сделанная при помощи главного ключа?
комментариев: 11558 документов: 1036 редакций: 4118
Опция -u в gpg позволяет выбирать в т.ч. и подключ, о чём по вашей же ссылке и сказано. Про PGP не в курсе.
комментариев: 27 документов: 9 редакций: 3
Ну, я win-юзер. Почту пишу-читаю иногда через theBat, но как правило через веб-интерфейс. В таких условиях пользоватся gpg с командной строки – это просто какой-то закат Солнца вручную.
PGP desktop версии 9.8 и младше – нет, не позволяет.
Что-то такое я и предполагал. Поэтому недоумеваю.
Идея о необходимости подключей строится на том, что
а) заверять ключ (собирать на него подписи других людей или удостоверяющих центров) – занятие долгое и трудоёмкое
б) регулярно используемый ключ, особенно ключ для шифрования, может быть утерян или скомпрометирован (в том числе по требованию закона)
Поэтому предлагается заверять мастер-ключ, а для повседневных нужд использовать подключи, каковые создаются по мере надобности, автоматически заверяясь мастер-ключом.
Откуда следует, что сами подключи заверены исключительно и только мастер-ключом. Даже если не сразу, то со временем – ведь предлагается подключи делать короткоживущими.
Очевидные недостатки такого решения:
а) нет совместимости со старыми программами (не поддерживающими подключи)
б) _полноценная_ работа с подключами есть (на текущий момент) только в командной строке gpg
в) повышенная сложность в работе
Достоинства описаны в вышеупомянутой статье.
Однако всё эти достоинства могут быть получены куда более простым методом, лишенным названных недостатков.
Сделать один ключ (S-P пару ключей — это называется сертификат?). Заверить его у разных людей.
Создать себе второй (третий, безднадцатый) сертификат, заверить его первым.
Первый просто экспортировать на флешку, со связки удалить, флешку кинуть в сейф. Доставать обратно только если нужно создать и заверить еще один ключ.
Вторым (третьим и т.п.) ключами пользоваться по своему разумению.
Им можно даже названия дать соответствующие. "Иван Помидоров, ЭЦП для документов ООО <Вектор>" :)
Итог такой же. Мастер-ключ в сейфе. Остальные в работе. Мастер-ключ заверен разными чужими. Остальные заверены мастер-ключом.
Просто, наглядно.
Так чего ради затеяны все эти сложности?
комментариев: 1060 документов: 16 редакций: 32
Подключи в спецификации обязательны, если реализация использует старую спецификацию, то она много чего другого тоже не умеет.
Ваша схема посадит дырку в сеть доверия. Подлинность второго ключа не получится подтвердить автоматически без выставления доверия первому, и не факт, что другой пользователь этого хочет. Придётся всё ручками делать. Ну и шифрование ещё работать не будет, если это будут DSA-ключи.
Собственно ради эти двух вещей и затеяны: не факт, что главный ключ вообще можно использовать для шифрования и для автоматического подтверждения подлинности подключей при подтверждении подлинности главного.
комментариев: 27 документов: 9 редакций: 3
Вот я и пытаюсь понять – зачем. Если вы понимаете – зачем, то объясните мне, пожалуйста, в подробностях.
Конечно. Но это и сейчас так. Если не доверять мастер-ключу, то и его подключи так же не имеют доверия, не пригодны к работе.
Существующая схема: мастер-ключ + его подключи, заверенные только мастером. Дальний пользователь видит их как единое целое. Пользователь _обязан_ выставить мастер-ключу доверие, иначе он не сможет воспользоваться подключами для зашифрования или проверки подписи.
Гипотетическая схема: мастер-ключ + вторые самостоятельные ключи, заверенные только мастером. Дальний пользователь видит их как разные сущности. Пользователь _обязан_ выставить мастер-ключу доверие, иначе он не сможет воспользоваться вторыми для зашифрования или проверки подписи.
В обоих случаях юзер должен доверять мастер-ключу.
Вы разницу видите? Я – нет.
Равным образом шифрование не будет работать, если и мастер-ключ и все его подключи сделаны так, что годятся только для подписи. Такое возможно, я специально сейчас проверил.
Главный ключ в гипотетической схеме вообще должен использоваться только для заверения вторых ключей. Можно ли им будет что-либо зашифровывать – не важно.
А вот это уже "теплее". Но почему? Не понимаю.
Поставьте gpg4win, gpg является его частью. В командной строке каждый раз задавать все опции было бы неудобно, поэтому в Linux люди создают скрипты или алиасы. Равно и в win никто вам не запрещает создать батник, в котором будет запускаться gpg с вам нужными опциями и делать то, что требуется.
Думаю, для удобства. Нужен универсальный способ связывания мастер-ключа с подключами. То, что один ключ подписан другим, ещё ничего не означает. В текущей архитектуре PGP вам придётся лично договариваться с абонентами о том, что значат ваши подписи. Если же делать унифицированную систему связывания мастер-ключа с подключами, они вместе начинают выглядеть, как единый ключ, что удобно. Соответственно, абоненты сразу получают все нужные публичные ключи в связке. Ещё кое-какие идеи извучивались в /comment4784.
В современных версиях gpg и обвязок, его использующих, всё работает прозрачно. Метод примерно такой (могу ошибаться в деталях, но на уровне сути так), делается с целью достижения этого:
Пару раз [1,2] на форуме менялись ключи приблизительно в соответствии с этим правилом, можете почитать детали.
комментариев: 1060 документов: 16 редакций: 32
Нет. Доверие выставлять не нужно. Нужно только подвердить подлинность. А в случае с несколькими ключами нужно и подлинность подтвердить, и доверие выставить. Прочитайте про различие validity(подлинность) и trust(доверие).
комментариев: 9796 документов: 488 редакций: 5664
Удобство подключей в том, что многие сложные задачи при этом унифицируются, а тем, кому неинтересно в это вникать, эта сложность их не затрагивает, для них всё прозрачно. Они, как отметили выше, воспринимают ключ как единое целое и могут только в общем виде знать, что никто, кроме владельца ключа не может управлять подключами (отзывать, менять, продлевать).
Удобство ещё и в том, что предположим, паранойя перед сильным противником требует регулярной смены ключа (хотя бы раз в год). Вдруг он факторизует RSA и всё расшифрует? Тогда ему надо каждый год уметь взламывать хотя бы по одному ключу. Но можно не менять главный ключ, который только для подписи связки и попытки подмены которого и изменения в связке могут быть заметны (кстати, ещё один довод: все действия над связкой, проведённые главным ключом в ней остаются и публичная часть их всем видна на серверах ключей; даже если противник украдёт главный ключ, ему будет трудно незаметно от владельца устроить изменения в связке, по крайней мере, если пользователи-корресподенты достаточно опытны и внимательны. Или ему придёться быть глобальным активным противником: отслеживать соединения всех корреспондентов через интернет и каждому индивидуально подменять подключи в связке, чтобы никто ничего не заподозрил, что малореально даже для сильного противника). А подключи подписей и шифрования можно менять хоть каждый день.
комментариев: 27 документов: 9 редакций: 3
Со стороны владельца выглядит, кажется, неплохо
-а-
Создание главного ключа и одного или более дополнительных.
Отдельное хранение закрытой части мастер-ключа.
Внесение изменений в главный ключ.
Любая версия любого ПО. Даже по RFC-1991, если надо.
Никаких фокусов. Очень просто.
И каждый ключ может обладать собственным характерным названием.
Например "для шифрования 2012 год", "для подписи \должность\"
-б-
Применение ключа для расшифрования или подписи.
Любая версия любого ПО.
Поскольку закрытая часть главного ключа хранится не на связке, то подписать им что-либо не получится.
В остальном же владелец должен сам следить за тем, чтобы каждый ключ использовать строго по назначению, в том числе не подписывать шифровальным ключом.
Независимые названия это облегчают.
====================================
Вид со стороны абонента менее привлекателен.
-а-
Первоначальное получение ключа.
Получение [новых] дополнительных ключей.
Проверка подписи
Любой openpgp-совместимый софт.
Абонент должен будет либо поднять trust для главного ключа (что, как уже было отмечено, может быть нежелательно)
либо самому поставить на дополнительных ключах свою подпись (неэкспортируемую).
Не очень хорошо, но в целом приемлемо.
-б-
Шифрование.
А вот тут всё плохо.
Ничто не удерживает абонента от того, чтобы использовать главный ключ для шифрования.
Тем самым абонент вынудит владельца достать из сейфа закрытую часть главного ключа.
Неприемлемо
Кстати, почему gpg2win в командной строке выводит русский (зачем?!) текст в кодировке win-1251, хотя именно для консольных приложений винды нужна CP866 и ничто иное?
Консоль gpg2win выглядит вот так:
/comment41107 & /comment48259
комментариев: 27 документов: 9 редакций: 3
Я имел в виду:
Хорошо, спасибо.
Если что, время от времени здесь появлялись жалующиеся на то, что создали ключ, а зашифровать им не могут. Гуй каких-то утилит легко (и чуть ли не по умолчанию) давал им создавать ключи, не предназначенные для шифрования (а только для подписи).
Как можно удалить мастер-ключ на данном шаге?
Получается, что при таком методе работы я не смогу подписывать ничего, не доставая из сейфа связку?