id: Гость   вход   регистрация
текущее время 07:00 01/10/2020
Владелец: serzh (создано 23/11/2007 01:09), редакция от 30/12/2007 10:30 (автор: SATtva) Печать
Категории: криптография, openpgp, спецификации, сайт проекта, wiki, стандарты, разное, сообщество
http://www.pgpru.com/Черновики/Спецификации/RFC/ОбсуждениеНовогоСтандартаOpenPGP
создать
просмотр
редакции
ссылки

В связи с выходом нового стандарта OpenPGP (RFC4880) предлагаю приступить к обсуждению необходимых изменений в следующей версии. Тут возможно обсуждение и сопутствующих сервисов (keyserver и т.д.).


Оглавление документа:

Мини-FAQ


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

  • Я хочу добавить предложение.
Добавьте предложение, согласно шаблону. Желательно указать себя, как ответственного за перенос спорных изменений этого предложения на страницу.

  • Предложения будут посланы в официальный список рассылки OpenPGP?
Да.

  • Что должно получиться в результате?
Статья с чёткими предложениями и аргументацией по улучшению OpenPGP.

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

Предложения

тип идентификатора ключа (Serzh)

Предложение: Необходимо ввести тип идентификатора, т.е. получить "расширеный vCard". Типы возможных идентификаторов:
  1. имя
  2. фамилия
  3. отчество
  4. e-mail
  5. jabber (и другие, каждый IM как отдельный тип)
  6. nickname (псевданим)
  7. номер паспорта
  8. сайт/пользователь (например: www.pgpru.com/Serzh)
  9. фото
  10. логотип
  11. блог / домашняя страница
  12. телефон
  13. день рождения
  14. адрес
  15. произвольная строка

Плюсы:

  1. возможность подписать отдельный идентификатор
  2. легко реализуема автоматическая обработка
  3. больше отличий между владельцами ключей

Минусы: -

связь ключа шифрования с контактом (Serzh)

Предложение: Сделать возможность привязки ключа шифрования к определённым контактам. Например: 1-й ключ используется для шифрования 1-й и 2-й почты, 2-й ключ для шифрования jabber и 3-й почты, 3-й ключ для особо приватных контактов.
Плюсы: гибкость при разделении ключей шифрования.
Минусы: -

публичность идентификатора/ключа (Serzh)

Предложение: каждому идентификатору/ключу добавить условие публичности, т.е. если идентификатор/ключ обозначен как приватный, то keyserver его игнорирует (не импортирует).
Плюсы:

  1. добавляет управление количеством опубликованой информации
  2. крайних пораноиков добавляет в общую сеть доверия, т.к. им можно не публиковать свой самый-самый-самый секретный открытый ключ

Минусы: -

управление удалением идентификаторов/ключей (Serzh)

Предложение: в свойствах ключа добавить список хэшей возможных идентификаторов/ключей. Например: мы имеем ключ с двумя идентификаторами ид1 и ид2. В свойствах хранится хэш(ид1) и хэш(ид2). Через некоторое время мы решили оставить только 1-й идентификатор. Следовательно из свойств мы удаляем хэш(ид2), а т.к. дата самоподписи позже, то и остальные сервера его успешно удаляют.
Плюсы:

  1. возможность целиком удалять старые идентификаторы (это не отзыв!)
  2. меньше раздувается объём ключа при замене идентификаторов
Минусы: избыток информации на ключе (хранение хэшей идентификаторов)

Использование одноразовых публичных подключей(unknown)


Пусть пользователь "A" хочет получить одно сообщение от пользователя "B",
после чего он уничтожает связку открытый ключ/закрытый ключ PK_A, SK_A. Также он уничтожает расшифрованное сообщение.
Это гарантирует ему защиту от требования выдачи предыдущих ключей и сообщений враждебной стороной. Проблема в том, что одноразовые ключи должны храниться в формате, позволяющем лёгкое уничтожение, что трудно при условие, что вся связка хранится в виде базы в одном общем файле.


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


Возможность запрета на подпись ключа или разрешение подписи только по запросу(unknown)


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


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


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


Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").

Защита от атаки "Скопировать/Вставить"(Serzh)


Описание атаки: при подписывании кратких сообщений (например: "Я согласен.") на форумах существует проблема несанкционированного переноса этого сообщения на другой форум, что исказит позицию автора.


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


Плюсы: возможность проверки последовательности сообщений
Минусы: сложности при модерации


  • имхо защита от такой атаки не входит в модель OpenPGP, и ее внесение только излишне усложнит стандарт. Для желающих избежать такой атаки будет достаточно вставлять в каждый пост ссылку на топик к которому он относиться. (ntldr)
  • Согласен, это чисто инженерная проблема реализации; сам протокол с такими мелочами связываться не должен.

© 2007 SATtva, ntldr, serzh, unknown

Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
CreativeCommons-Attribution-ShareAlike

 
— Гость (23/11/2007 02:19)   <#>
Вместо того что хернёй маяться, извиняюсь за выражение, лучше бы доработали асимметричные алгоритмы с учётом защиты против взлома на квантовых компьютерах. Это куда более актуально на данный момент. gpg преимущественно используется для защиты "личных секретов", а таковые не теряют своей ценности спустя многие годы в отличе от коммерческих решений. Однако же, как видим, путь развития продуктво асимметричного шифрования нацелен прежде всего на коммерческих пользователей...
— serzh (23/11/2007 02:45)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Вместо того что хернёй маяться, извиняюсь за выражение, лучше бы доработали асимметричные алгоритмы с учётом защиты против взлома на квантовых компьютерах.

Жду предложений.
— Гость (23/11/2007 03:57)   <#>
Жду предложений.

Судя по высказываниям unknown'а в этом направлении ведётся работа. Судя же по тому, что она ведётся и ещё долго будет вестись, потребность в указанных алгоритмах пока рассматривается не необходимостью, а скорее академическим интересом, как-то типа квантового распределния ключа ... :(
— ntldr (23/11/2007 07:51)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
А HFE чем не подходит на роль безопасного от квантового взлома асимметрика? Опирается он ведь не на проблему теории чисел, а на проблему решения неполной системы уравнений.
— SATtva (23/11/2007 12:39)   профиль/связь   <#>
комментариев: 11552   документов: 1036   редакций: 4094
А HFE чем не подходит на роль безопасного от квантового взлома асимметрика?

По-моему, HFE взломан алгебраическим криптоанализом (именно благодаря его алгебраической структуре), нет?
— ntldr (23/11/2007 13:30)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Не найдете ссылку на эту работу? Интересно было бы применить к кое-какой проге :)
— Гость (30/09/2013 07:43)   <#>

О каких комментариях идёт речь? Об uid'ах подписывающих ключей? Так их обычно не грузят, поэтому получается безликий список keyid'ов — одни цифры, непонятно кому принадлежащие. Конечно, если кто-то загружает все ключи, которыми был подписан нужный, то тогда да...

Есть ещё какие-то notation, но я так и не понял, что это, и зачем нужно; какая-то связанная с сертификатами/CA дичь. Не знаю, может ли добавлять notations тот, кто не владелец ключа.
— SATtva (30/09/2013 08:15)   профиль/связь   <#>
комментариев: 11552   документов: 1036   редакций: 4094
Вот в notations и можно при желании совать произвольные комментарии. По-хорошему, они могут применяться для собственных семантических расширений или каких-то машиночитаемых пояснений (из стандарта: "Notations can be used for any extension the issuer of the signature cares to make").

Не знаю, может ли добавлять notations тот, кто не владелец ключа.

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