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

• Согласен, это чисто инженерная проблема реализации; сам протокол с такими мелочами связываться не должен.

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

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

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

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

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

Предположим, владелец ключа не хочет активно участвовать в создании сети доверия, а его ключ представляет какую-либо серьёзную официальную организацию. Чтобы посторонние люди не могли ставить подписи на этот ключ и снабжать их нежелатльными для владельца комментариями, загромождать посторонними подписывающими ключами и т.д., ключ должен быть или полностью закрыт от проставления подписей или требовать запрос от владельца.
В запросе присылаются все поля, которые подписывающая сторона хочет внести в ключ. Если владелец соглашается, то он подписывает запрос и оптравляет обратно подписывающей стороне. Только при правильной подписи подписывающей стороны и владельца ключа, подписывающий ключ может быть допущен к подписанию.
В противном случае все невалидные поля должны выбраковываться из ключа.
Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").

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

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

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

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