Re: (пробел) эффективно использовать повторно адр с помощью Weil сопряжения IBE
Существует краткое описание ситуации здесь http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03792.html и я поставил й вопрос о том, можно ли сделать лучше всего с Питером Todd:
Цитата: adam3us на Bitcoin-DEV
Теперь в то время как было бы ясно очень хороший выигрыш, если многоразовые адреса могут быть сделаны SPV, как в характеристиках сети и личную жизнь, но мы не имеем вероятный механизм еще ИМО. Закрыть, как мы получили, было повышение Грега моего / ваш "цветение наживка"/"префикс" Концепция сделать несколько приманок кандидатов, чтобы обеспечить некоторую двусмысленность (по-прежнему позволяет исключить, только немного меньше его).
Если мы сможем найти эффективную криптографию, чтобы решить эту последнюю, мы могли бы даже принять их, как правило, если это было достаточно эффективно без необходимости интерактивного одноразового адреса релиза
Если мы сможем найти эффективную криптографию, чтобы решить эту последнюю, мы могли бы даже принять их, как правило, если это было достаточно эффективно без необходимости интерактивного одноразового адреса релиза
и Питер предложил также связанные с ним проблемы доказав что-то о существовании или нет решения этой проблемы.
Я думаю, что у меня есть решение корректуры из концепции, что доказывает примером мы можем сделать лучше в экономии пространства, linkability обороне и не-интерактивности, чем мой цвет приманка, приставка связанного Питера Todds; и расширенное цветение приманка Greg Максвелла описывается http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03705.html.
Таким образом, идея заключается в том, чтобы использовать схему IBE в качестве строительного блока в аналогичном пути к моей постановке проблемы 1996 года для НИФ и замечания 1998 года о том, что использование нового для схемы IBE может обеспечить общее решение для НИФ, и прихода в 2001 году из первых эффективная / чувствительная люком крутизна (*) IBE с введением проблемы Weil Сопряжение Дэна Боне и Мэтт Франклин описал здесь http://en.wikipedia.org/wiki/Boneh%E2%80%93Franklin_scheme.
Грег суммированы следующим IBE на IRC:
котировка
(Для тех, кто может) не быть знаком с IBE вещи: Идея заключается в том, что пользователь имеет главный секретный ключ, который приводит к открытому ключу мастера. Любой желающий может принять предварительный блок хэш и объединить его с помощью открытого ключа мастера, чтобы получить сеанс Публичным который может быть использован для шифрования chaincode, включенной в OP_RETURN. Используя мастер закрытого ключа пользователя может derrive закрытого ключа сеанса, который затем может использоваться для распознавания транзакции, используя тот же ключ сеанса.
В IBE (шифрование на основе идентичности) все это используется немного по-другому: основные ключи удерживаются ЦС, а идентификатор сеанса ваш адрес электронной почты, и теперь любой желающий может сделать открытый ключ для вы- но вам нужна помощь ЦС получить закрытый ключ)
В IBE (шифрование на основе идентичности) все это используется немного по-другому: основные ключи удерживаются ЦС, а идентификатор сеанса ваш адрес электронной почты, и теперь любой желающий может сделать открытый ключ для вы- но вам нужна помощь ЦС получить закрытый ключ)
В принципе, как сказал Грег ваш публичный ключ ваш адрес (адрес электронной почты, блок-хэш, все, что удобно и уникальным) и от того, и главный открытый ключ сервера IBE, сервер может вычислить секретный ключ, соответствующий этому. Мастер общественность, как правило, считается общесистемный параметр домена. Естественно потому, что побочный эффект этого является то, что сервер IBE может расшифровать всякие почтовые человек никогда не были слишком взволнованы перспективой.
Однако мое наблюдение 1998 НИФ является действуя как свой собственный сервер IBE (каждый пользователь создает свой собственный мастер открытого ключа сервера), они могут создать последовательность (НИФ) или набор (Bitcoin многоразовой адрес) открытых ключей с интересными и публично выводимой свойствами!
Это мой вывод из 1996, что для решения этой проблемы с DL непосредственно по крайней мере, в случае НИФ, как представляется, не представляется возможным.
Таким образом, в основном многоразовый адрес становится открытым ключом IBE, существующий общественный вывод через DH или EC Elgamal / ECIES или любой вариант (bytecoins, шахты, Питер Тодд / Амир Таки в) поступает на фактор, который может быть извлечен. Так что с моим вариантом (случайным образом отправителя генерируется коэффициент умножения, зашифрованный с помощью ECIES) можно зашифровать фактор с пабом = IBE-экстракт (мастер-паб, ид = предыдущий блоком хэш), используя предыдущий блок хэш в качестве "идентичность" и пользователи владеют самостоятельно принадлежит IBE "сервер",
Для Bytecoin & Питер Тодд / версия Амир Таки EC DH, используя входные или вспомогательные адреса для экономии места его даже не нужно отправить фактор, его уже послали. Тогда вы отправить отдельное сообщение, чтобы сделать с помощью безопасной delegatable фильтрации, замены более безопасного / больше места эффективным цветения фильтра / префикса, и это более гибкая структура.
Таким образом, безопасный delegatable фильтра вы отдельно добавить зашифрованное цветение приманку Greg предложенный (например, 1 байты префикс сообщаться с общедоступным адресом.) И вы можете даже объединить, что с расширенным цветом приманкой Грега выше, чтобы добавить анонимность установить в пределах блока.
Следовательно, теперь вы можете безопасно и очень сети / пространство эффективно и безопасно делегировать поиск блока путем вычисления секретного ключа для ключа паба IBE, что любой отправитель будет использовать для этого блока, и отправить его в качестве запроса к случайному (или узлу-захвату защищали случайным образом выбранный узел). Узел может расшифровать цветение приманки с ним, но по-прежнему не в силах коррелировать с налетом приманками других платежей, полученных одним и тем же пользователем в заморачиваться блоками.
(На практике может понадобиться эпоха не блокировать или перекрывающийся тест, поскольку пользователь не имеет полную уверенности в их ОМ, заканчивающемся в ожидании блока).
О Weil спариванию, и новый риска твердости крипты, это также предположение твердости при некоторых ZK-SNARKs, как я думаю, что используется в zerocash, и в то время как ZK-СНАРК вводит свой собственный риск системы сложности / крипто сверху; на мой взгляд, Weil спаривание немного ниже гарантии / обзор не так широко используется по отношению к проблеме EC DL. Во всяком случае, интересно, что нужно сказать о том, что в случае эта схема сломалась в будущем она падает обратно на схему, которая в настоящее время предлагаемого использования префикса. То есть его не хуже, чем от linkability и, вероятно, сохранит некоторую стоимость, даже если broken-- асимметричные криптографические разрывы, как правило, несколько постепенно.
Это выглядит более дорогим и Неиндексируемым хотя я не смотрю, чтобы увидеть, если есть какой-либо шифротекст или только партия предвычисление, что можно было выжать из него.
Очевидно, его более ресурсоемкие и некоторые, например, плата за механизм для предотвращения узлов DoS может быть хорошо, но это, кажется, чтобы продемонстрировать доказательство существования на то, что можно сделать лучше.
Наконец-то я думаю, что это может быть в возможности делать дальше, чем это, потому что технически это не нужно делегировать дешифрование только делегировать фильтрацию, которая может быть более простым требованием.
Адам
(*) Там была более ранняя схема по Маурер и др, если я помню, но, чтобы получить запас безопасности в 1024-битовую вы должны были выполнить дискретный журнал атаку на 512-битном цвете, поэтому ключ стоимость производства была огромна, следовательно, "разумный люк крутизна" тот очень неглубоко в TEMS разницы между стоимостью рабочей установки и прочностью системы шифрования.