id: Гость   вход   регистрация
текущее время 14:00 28/10/2021
Автор темы: Гость, тема открыта 22/06/2014 07:02 Печать
Категории: софт, gnupg
https://www.pgpru.com/Форум/РаботаСGnuPG/ФорматФайлаПубличногоКлюча
создать
просмотр
ссылки

Формат файла публичного ключа

Вопрос для того, чтобы не подумали, что человек – новичек в gpg.
Нужно передать публичный ключ именно в формате текстового файла по емейлу или на флешке (а не через сервер ключей, как обычно).
В каком формате (т.е. с каким расширением) должен быть этот файл?
Например, если передавать с расширением .txt, то это странно, когда такое происходит между линуксоидами.
Если передавать файл вообще без расширения, то м.б. непонятно, что это.
Какое расширение файла публичного ключа можно использовать?


p.s.: вопрос 2 – помогите, пожалуйста, найти тему, где ntldr задавал вопросы по правильной генерации ключа, не могу найти.


 
Комментарии
— unknown (22/06/2014 10:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ну вы и тему назвали :)
Для экспорта публичного ключа используйте:
gpg --output filename.txt --export --armor --[user-uid]

Где user-uid — отпечаток ключа, e-mail, имя, всё, что однозначно указывает на нужный ключ.

Расширение файла, тем более в Linux, никакого значения не имеет. Логично рассматривать это просто как текстовый файл. Поэтому можно сохранять с расширением .txt, .pub, или хоть .key.txt.pub, .gpg.pub.txt
— Гость (22/06/2014 10:30)   <#>

Если используется armored-вывод, то, по конвенции, расширение должно быть .asc, если бинарный формат, то, по конвенции, .gpg. Это так не только для самих ключей, а вообще для любых данных PGP-формата.


Профиль → Документы → «Я меняю свой PGP ключ». Что может быть проще? Если что, на тему, как генерить ключи, есть сравнительно свежее обсуждение, и даже не одно. По итогам было бы неплохо оформить результат в виде связного текста, который бы заменял собой этот старый документ, но я этого пока так и не сделал. Сейчас полезная информация ровным слоем размазана по куче веток. ☹
— Гость (22/06/2014 10:40)   <#>

Может, конечно, unknown прав, но мне такой формат кажется странным. KeyID — это же значение опции --export, а не --armor. Я бы записал так:
$ gpg -a --no-emit-version --export 0xXXXXXXXX > file.asc
Чтобы убедиться, что экспортировался только нужный ключ, а не все публичные ключи со связки (люди часто по ошибке так делают), можно импортировать экспортированное:
$ gpg --import file.asc
Эта команда напишет, какие ключи были импортированы обратно (и, соответственно, не изменены). А вообще, привыкайте к тому, что всё надо желательно перепроверять, причём не только в PGP.
— sentaus (22/06/2014 12:18, исправлен 22/06/2014 12:27)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
KeyID — это же значение опции --export, а не --armor.

Судя по ману, да. Если так работает, то это даже немного странно.


заменял собой этот старый документ,

Я думаю, можно просто вставить в него пару абзацев про предпочтения. По основной теме(подключи) тот документ ещё не устарел.

— Гость (22/06/2014 12:29)   <#>

В целом, да, но это же можно изложить чуть короче, оставив только суть, и предложить иной более логичный способ работы с секретной связкой ключей. То, что там предлагается, вообще говоря, несколько нарушает все каноны безопасности. 2006-ой год, винда + времена, когда люди мало думали в терминах уязвимостей.
— unknown (22/06/2014 21:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Проблема в том же, как и с тонкими настройками Tor и вокруг него: нет единственно правильного или оптимального способа. У всех немного разные потребности и предпочтения.

Если бы я сейчас перегенерировал GnuPG-ключ, то не знал бы на чём остановиться. Вот, например, ключ RSA>4096 можно сгенерировать нештатным способом. Вот и думай, стоит ли это делать напильником, пока это не внедрили штатно? А то, может что-то в формате ключей поменяют и такой ключ превратится в тыкву. Для OpenSSH/OpenSSL, например, были статьи по более навороченным ключам/сертификатам, но пустить такое трюкачество в продакшн — рискованно. Где-то может в ответственный момент не сработать при переносе ключей в системах.

С другой стороны, могут и новые интересные опции добавить. Например, было бы интересно в одном ключе видеть и традиционную симметрику и эллиптику. Главный ключ мог бы быть заверен RSA, но иметь один подключ для эллиптики, так, чтобы с некоторых устройств в каких-то случаях пользователи могли бы выбирать и его.

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

Т.е., я бы не торопился с документом: лучше из нескольких документов собрать общий, чем исправлять чей-то фундаментальный, хорошо оформленный, претендующий на законченность и исчерпанность.
— Гость (23/06/2014 08:58)   <#>

Я не вёл речь про исправление. Естественно, если что-то делать, то будет просто новый документ «как правильно генерировать ключи с учётом имеющихся рекомендаций».
— unknown (23/06/2014 10:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Скорее, набор вариантов генерации ключа.

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

Возможно стоит делать что-то вроде серии статей, в которых рассматривается, что хотят некие Алиса и Боб и приводить примеры ситуаций и их решения. Многие даже не догадываются, какие задачи могут быть решены криптографическими способами из набора стандартных программ.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3