Вопросы относительно передачи ключей по hkps

Хотелось бы разобраться с hkps поподробнее.

Протокол HKP — всего лишь сильной урезанный HTTP. HKPS — то же самое с дополнительным канальным SSL-шифрованием (в общем, аналог HTTPS).

Используете ли вы hkps вместо дефолтного hkp? Оправдано ли это?

Зависит от модели угрозы. Сервер в любом случае знает, какие ключи Вы запрашиваете.

Что это за сертификат такой (sks-keyservers.netCA.pem) и можно ли ему доверять?

Раз загружаете его с HTTPS, то доверие к нему будет на уровне SSL-сертификата веб-сервера (при условии, если сертификаты различаются).

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

Это штатный функционал, он ничем не опасен. В любом случае, он не может ухудшить ситуацию по сравнению с доступом к серверу по открытому HKP.

Что означает 'Version: SKS 1.1.0' ?

Что пакет ключа сформирован сервером SKS (SubKeys Server) версии 1.1.0.

Этот вопрос навеян этим?

После загрузки ключа я проверяю, что связь между данным ключом и адресом электронной почты не поменялась на множестве серверов ключей, TLS-сертификаты которых заверены независимо и не зашиты непосредственно в исходники самого пакета GPG (многопутевая криптографическая аутентификация в стиле Perspectives/Notary).

© Mike Perry.

Этот вопрос навеян этим?

Да, но только отчасти.
Дальнейшие чтения матчасти на данную тему порождают еще кучу вопросов по устройству gnupg.

Однако простыми и очевидными для новичка являются следующие тезисы (из статьи):

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

Это же очевидно. Почему тогда задаются этими вопросами?

Кстати, а нет ли готовых рекомендуемых примеров gpg.conf? Чтобы посмотреть, кто как изощрается с настройками gnupg?
Вообще по поводу этого конфига – является ли он тайной за 7-ю печатями? Можно ли держать его, например, в git репозитории,
чтобы управлять историей его версий (в случае, если настройки будут совсем уже заморочными или будет много изменений) да и просто иметь его удаленно для новых машин?
Или это будет совсем уж неразумно?

Непонятно, что хотел сказать автор. TLS-сертификаты некоторых серверов ключей зашиты в исходники GnuPG? Или он просто хочет сказать, что сверка сертификатов имеет смысл, потому что они не зашиваются в исодники GnuPG?


Да, внутренности GnuPG — не простая и очень хреново задокументированная вещь, здесь их описания раскиданы по множеству веток (в основном старых).


Очевидно, но люди об этом не задумываются точно так же, как при платежах своими кредитками они не думают о том, что добавляют информацию о своём местоположении, покупках, вкусах, предпочитаемых магазинах и прочем в перманентную базу данных, из которой эти записи уже не исчезнут никогда. Это тот тонкий случай, когда случайные и ничего не значащие факты незаметно превращаются во вполне значимую статистику.


Что-то было, но разбросано по всему фруму. Например, тут что-то проскакивало. Если гуглить по showpref site:pgpru.com, то много старых топиков находится, где обсуждали эти настройки. Опции no-emit-version и throw-keyids — тоже кандидаты на попадание в конфиг, особенно первая (вторая может вызвать side-эффекты).


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

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

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