Формат файла публичного ключа
Вопрос для того, чтобы не подумали, что человек – новичек в gpg.
Нужно передать публичный ключ именно в формате текстового файла по емейлу или на флешке (а не через сервер ключей, как обычно).
В каком формате (т.е. с каким расширением) должен быть этот файл?
Например, если передавать с расширением .txt, то это странно, когда такое происходит между линуксоидами.
Если передавать файл вообще без расширения, то м.б. непонятно, что это.
Какое расширение файла публичного ключа можно использовать?
p.s.: вопрос 2 – помогите, пожалуйста, найти тему, где ntldr задавал вопросы по правильной генерации ключа, не могу найти.
комментариев: 9796 документов: 488 редакций: 5664
Для экспорта публичного ключа используйте:
Где user-uid — отпечаток ключа, e-mail, имя, всё, что однозначно указывает на нужный ключ.
Расширение файла, тем более в Linux, никакого значения не имеет. Логично рассматривать это просто как текстовый файл. Поэтому можно сохранять с расширением .txt, .pub, или хоть .key.txt.pub, .gpg.pub.txt
Если используется armored-вывод, то, по конвенции, расширение должно быть .asc, если бинарный формат, то, по конвенции, .gpg. Это так не только для самих ключей, а вообще для любых данных PGP-формата.
Профиль → Документы → «Я меняю свой PGP ключ». Что может быть проще? Если что, на тему, как генерить ключи, есть сравнительно свежее обсуждение, и даже не одно. По итогам было бы неплохо оформить результат в виде связного текста, который бы заменял собой этот старый документ, но я этого пока так и не сделал. Сейчас полезная информация ровным слоем размазана по куче веток. ☹
Может, конечно, unknown прав, но мне такой формат кажется странным. KeyID — это же значение опции --export, а не --armor. Я бы записал так:
комментариев: 1060 документов: 16 редакций: 32
Судя по ману, да. Если так работает, то это даже немного странно.
Я думаю, можно просто вставить в него пару абзацев про предпочтения. По основной теме(подключи) тот документ ещё не устарел.
В целом, да, но это же можно изложить чуть короче, оставив только суть, и предложить иной более логичный способ работы с секретной связкой ключей. То, что там предлагается, вообще говоря, несколько нарушает все каноны безопасности. 2006-ой год, винда + времена, когда люди мало думали в терминах уязвимостей.
комментариев: 9796 документов: 488 редакций: 5664
Если бы я сейчас перегенерировал GnuPG-ключ, то не знал бы на чём остановиться. Вот, например, ключ RSA>4096 можно сгенерировать нештатным способом. Вот и думай, стоит ли это делать напильником, пока это не внедрили штатно? А то, может что-то в формате ключей поменяют и такой ключ превратится в тыкву. Для OpenSSH/OpenSSL, например, были статьи по более навороченным ключам/сертификатам, но пустить такое трюкачество в продакшн — рискованно. Где-то может в ответственный момент не сработать при переносе ключей в системах.
С другой стороны, могут и новые интересные опции добавить. Например, было бы интересно в одном ключе видеть и традиционную симметрику и эллиптику. Главный ключ мог бы быть заверен RSA, но иметь один подключ для эллиптики, так, чтобы с некоторых устройств в каких-то случаях пользователи могли бы выбирать и его.
Можно будет создать тему, где все потренируются создавать тестовые ключи и пошагово описать, что при этом делают. Затем можно оценить, какие навороты полезны, а какие — сомнительны. Может как-то отсортировать по уровням сложности: для рядовых пользователей по-быстрому, для продвинутых, для любителей поэкспериментировать, для надёжности в плане совместимости, для перестраховщиков по безопасности, для сторонников большей гибкости, для сочетания с анонимностью и неприметностью и т.д.
Т.е., я бы не торопился с документом: лучше из нескольких документов собрать общий, чем исправлять чей-то фундаментальный, хорошо оформленный, претендующий на законченность и исчерпанность.
Я не вёл речь про исправление. Естественно, если что-то делать, то будет просто новый документ «как правильно генерировать ключи с учётом имеющихся рекомендаций».
комментариев: 9796 документов: 488 редакций: 5664
Повторюсь немного.
Кому-то нужны отделяемые подключи, кому-то нет. Кто-то хочет традиционно участвовать в акциях совместного подписания и расширять сеть доверия, а топикстартер даже не хочет отправлять ключ на сервер — может ему требуется анонимность. А кто-то хочет использовать ключ для подписи программ и ему не нужна неприметность. Кому-то интересна тема с распечаткой экстренного отзывающего сертификата, кому-то нет. Кому-то интересна групповая переписка и управление группами, а кому-то — приватность связи с единственным адресатом.
Возможно стоит делать что-то вроде серии статей, в которых рассматривается, что хотят некие Алиса и Боб и приводить примеры ситуаций и их решения. Многие даже не догадываются, какие задачи могут быть решены криптографическими способами из набора стандартных программ.