id: Гость   вход   регистрация
текущее время 21:44 28/03/2024
Автор темы: spinore, тема открыта 11/05/2010 01:38 Печать
Категории: криптография, openpgp, шифрование с открытым ключом, протоколы, аутентификация, эцп, управление ключами, стандарты
http://www.pgpru.com/Форум/Криптография/ОффтопикИзТемывозможностиTrueCryptПроОдноразовыеПодписи
создать
просмотр
ссылки

Оффтопик из темы "возможности TrueCrypt" про одноразовые подписи


Контекст: /comment37813, /comment37818, /comment37823, /comment37824 (перенести сюда).


 
Комментарии
— spinore (11/05/2010 02:18, исправлен 11/05/2010 03:25)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Вы же и сами прекрасно понимаете, что применить такое ограничение на уровне математического аппарата невозможно (если подписываемые данные действительно произвольны, то что мешает наделать копии этого ваучера?). Если ограничение применяется на программном уровне, это DRM.

Согласен. Пока писал тот комментарий физическое мышление затмило ум. В математике "неклонируемость" невозможна (оставляя пока в стороне вопрос о неклонируемых функциях, которые всё равно основаны на "физической" неклонируемости).


Может создадите отдельную тему и внятно изложите, что вас интересует, а то так непонятно и действительно далёкий оффтопик по отношению к криптоконтейнерам.

Задача приблизительно такова: упростить процесс убеждения публики в том, что ключ заменён на новый с таким-то отпечатком. Стантартная процедура с сертификатами отзыва не работает, т.к. на момент владения старым приватным ключём ID нового ключа неизвестен.


Одноразовые подписи существуют — Lamport signature or Lamport one-time signature scheme, но возможно это не то что вы думаете или для чего их предполагает применить spinore (для отрицаемости?).

Нет, вопрос о неотрицаемости мной не ставился. Подписи Лампорта, по-видимому, чисто формально бы решали мою задачу в теоретическом смысле, но были бы не целесообразны в практическом (как я понял позже). Дело в том, что для Лампорта нужна новая пара ключей, причём публичный ключ должен быть доведён до сведения всей публики. Единственное отличие такой схемы от стандартной PGP – одноразовость. С ровно таким же успехом можно создать второй "служебный" ключ PGP, и добавить информацию о нём в uid'ы основного ключа, написав что-то наподобие "доверяйте этому ключу, при смене/компрометации/утрате ключа информация о новом ключе будет подписана этим служебным". И в такой ситуации, и в ситуации с подписями Лампорта надо приватно хранить какой-то другой ключ/данные, а одноразовость здесь не критична. Это может быть целесообразно с точки зрения "разделения секрета" (один ключ подтверждает валидность другого), но не более того. Другое дело – когда схожий механизм встроен в саму инфраструктуру PGP, где владельцу ключа дозволено только один раз сообщить об идентификаторе нового ключа [опять противоречие: если злоумышленник получил доступ к ключу, то он может первый заявить о смене ключа, а если для этого нужны ещё какие-то приватные данные, то получаем схему, функционально схожую с одновременной поддержкой двух ключей (можно, конечно, сделать служебный ключ простым типа пароля (личностная криптография?), но это уже сторона чисто технической целесообразности)]. Как видно, вопрос был сформулирован невнятно, потому что не понимал [правильно поставленный вопрос – половина ответа, как всегда].


Более того, подписи Лампорта чем-то даже хуже служебного PGP-ключа: после того, как приватный ключ для Лампорта опубликован, любой может нагенерить сколько угодно валидных подписей, и встаёт вопрос о том, где впервые этот приватный ключ и подписанные данные были опубликованы (это уже действительно может быть интересно как раз для неотрицаемости), т.е. если не использовать какие-то сервисы меток времени, то может начаться бардак. Мне кажется, что Лампорт даёт интересный криптопримитив, но его применение в реальных задачах потребует разработки соответствующего стойкого протокола [равно как и RSA было бы уязвмо, если бы шифровались/подписывались произвольные данные, а не случайный симметричный ключ].


P. S.: на правах публичного монолога/рассуждений, т.к. сам вопрос ввиду вышесказнного мне представляется уже снятым, но, может быть, кто-то захочет ещё пообсуждать.

— unknown (11/05/2010 10:30, исправлен 11/05/2010 14:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Надеюсь копии самих комментов делать не надо, можно перечитать темы там и вокруг тех комментов ещё.


[offtop]

(оставляя пока в стороне вопрос о неклонируемых функциях, которые всё равно основаны на "физической" неклонируемости).

Многие уже быстро поломали на основе более совершенных моделей математической эмуляции.
[/offtop]


Более того, подписи Лампорта чем-то даже хуже служебного PGP-ключа: после того, как приватный ключ для Лампорта опубликован, любой может нагенерить сколько угодно валидных подписей

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

Мне кажется, что Лампорт даёт интересный криптопримитив, но его применение в реальных задачах потребует разработки соответствующего стойкого протокола

Конечно, любая криптосистема требует разработки от примитива к протоколу (и если повезёт — к стандарту). Практически для чего пытались применить подписи Лампорта — потоковые микроплатежи (деньги меньше цента для оплаты трафика попакетно: пока абонент смотрит, то платит). Можно конечно придумать и некоммерческое использование. О попытках применения именно для отрицаемых подписей неизвестно. Это было моё предположение. Может и не разрабатывают как раз даже по тем причинам, про которые вы догадались.


Над остальным надо подумать. И над /comment39243, хотя почти со всем согласен.
Вот эту тему логично продолжать как продолжение той, можете там поставить ссылку.


/comment37813:

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

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

— unknown (11/05/2010 11:08, исправлен 11/05/2010 11:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Задача приблизительно такова: упростить процесс убеждения публики в том, что ключ заменён на новый с таким-то отпечатком. Стантартная процедура с сертификатами отзыва не работает, т.к. на момент владения старым приватным ключём ID нового ключа неизвестен.

Что не так в простом объявлении нового ключа, при параллельном использовании старого с пересекающимися короткими сроками действия? Старый можно затем просто не продлевать или наложить на него сертификат отзыва, чтобы уж наверняка убедить, что он недействителен.
Вот как недавно, с подписями на новом от старого, как в самом объявлении, так и на связке ключа. Вопрос только в этом?

— spinore (15/05/2010 00:47, исправлен 15/05/2010 00:57)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Надеюсь копии самих комментов делать не надо, можно перечитать темы там и вокруг тех комментов ещё.

В связи с

Может создадите отдельную тему и внятно изложите, что вас интересует, а то так непонятно и действительно далёкий оффтопик по отношению к криптоконтейнерам.

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


О попытках применения именно для отрицаемых подписей неизвестно. Это было моё предположение.

Можно предположить огород наподобие такого (шифрования нет, только подписи и отрицаемость):

  1. Алиса шлёт Бобу свой публичный Лампорт-ключ, подписанный своим PGP-ключом.
  2. Алиса шлёт Бобу новый публинчный Лампорт-ключ, подписанный Лампорт-ключом с шага 1, PGP-подпись далее использоваться не будет.
  3. Алиса шлёт Бобу первое сообщение и новый публичный Лампорт-ключ, которые подписаны Лампорт-ключом с шага 2.
  4. Алиса шлёт Бобу второе сообщение и новый публичный Лампорт-ключ, которые подписаны Лампорт-ключом с шага 3, а также приватный Лампорт-ключ с шага 2.
  5. Алиса шлёт Бобу третье сообщение и новый публичный Лампорт-ключ, которые подписаны Лампорт-ключом с шага 4, а также приватный Лампорт-ключ с шага 3.

и т.д. После каждого сообщения Алисы Боб шлёт в ответ подтверждение о получении сообщения, с использованием подписей (возможно, как-то аналогично Алисе через Лампорта). В случае разрыва связи стороны опять отправляют друг другу свои "грязные" (из-за PGP-подписи) первые Лампорт-ключи, которые "очищают" на следующем шаге (новые публичный Лампорт-ключ, подписанный предыдущим публичным Лампорт-ключом), после чего уже обмениваются сообщениями, Лампорт-ключами для следующего сообщения, а равно и отправляют приватный Лампорт-ключ с позапредыдущего шага (чтобы в момент сверки подписи атакующему не был известен приватный ключ и он не смог подделать сообщение).


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


Ещё интересная мысль в голову пришла. По ссылке описан случай, когда посылаемое сообщение произвольно, а отправляющая и принимающая сторона оперируют хэшами сообщения. В то же время можно было бы рассмотреть случай посылки сообщений фиксированной длины (256 бит), тогда бы сами сообщения можно было не посылать: получающая сторона их всегда может восстановить сама, зная только публичный ключ и подпись [впрочем, это тривиально ;) но, быть может(?), могло бы дать какие-то полезные свойства для неотрицаемости – не знаю]. Чем-то напоминает "шифрование по таблице" (не помню, как правильно называется), если дополнительно предположить, что публичный Лампорт-ключ известен только адресату.


Вот эту тему логично продолжать как продолжение той, можете там поставить ссылку.

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


Что не так в простом объявлении нового ключа, при параллельном использовании старого с пересекающимися короткими сроками действия? ... Вопрос только в этом?

Да, вопрос только в этом, но есть один нюанс. Если всё идёт по плану – можно сделать как и в "том топике", но, допустим, что доступ к предыдущему ключу из-за чего-то утерян. Как мне доказать, что я есть я, если предыдущего ключа уже нет? Если у меня есть бэкап с сертификатом отзыва (он не настолько критичен – его можно поручить на хранение даже друзьям, т.к. урон от внезапного злонамеренного отзыва не столь велик), я ещё могу доказать, что предудущий ключ аннулирован, но не могу прокинуть "мостик доверия" к новому сгенерированному мною ключу, основываясь на старом, и вынужден аутентифицировать его для всех точно так же, как и свой самый первый ключ. Вот примерно из таких соображений и родились вышеописанные идеи :) Ещё можно заранее иметь второй "будущий" ключ, подписанный старым, но тогда задача всё равно сводится к предыдущей – если доступ к приватным ключам утерян, то всё, а хочется какого-то функционала наподобие "зная пароль, можно доказать, что вледелец моего нового ключа именно я". Согласен, что слишком сумбурное изложение мысли, но я сразу оговаривался, что "это лишь общие идеи".

— SATtva (15/05/2010 21:35)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если всё идёт по плану – можно сделать как и в "том топике", но, допустим, что доступ к предыдущему ключу из-за чего-то утерян. Как мне доказать, что я есть я, если предыдущего ключа уже нет?

Обычно такой сценарий означает разрыв доверия и необходимость начинать с чистого листа. Хотя да, понятно, что именно эту проблемы Вы решить и пытались.
— unknown (16/05/2010 16:24, исправлен 16/05/2010 16:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Многошаговые протоколы для отрицаемости или PFS в почте не нужны. Ведь в почте можно точно также использовать растянутый по шагам DH или в целом виде тот же OTR, что неудобно. Да ещё могут быть атаки на переотправку активным атакующим.


Доверие на новый ключ действительно нельзя переносить, как SATtva заметил, смысл наоборот как можно громче заявить: "возможно враг добрался до старого ключа и все цепочки доверия, которые тянутся от него по крайней мере после момента X, скомпрометированы; возможно с ключом обращались недостаточно аккуратно и потеряли его и т.д.". Нужно заводить новый ключ и заново "выращивать" на нём доверие.


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

Именно потому что бэкапы сертификатов отзыва прячут не так тщательно, факт его опубликования (якобы) первым с некой новой подписью нового ключа ничего не доказывает в плане доверия.

— spinore (17/05/2010 01:23)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Многошаговые протоколы для отрицаемости или PFS в почте не нужны.

Для начала/для простоты я подразумевал jabber. Насчёт почты действительно надо думать.

Доверие на новый ключ действительно нельзя переносить

Вопрос участия в сети доверия я тоже изначально не ставил. Считается, что есть n участников (n мало), где каждый независимо доверяет ключу другого, установив при желании доверие своими собственными методами. В качестве примера можно рассмотреть участников pgpru.com, загрузивших свои ключи в профиль.

Именно потому что бэкапы сертификатов отзыва прячут не так тщательно, факт его опубликования (якобы) первым с некой новой подписью нового ключа ничего не доказывает в плане доверия.

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