Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в

Я мог бы смотреть на старую версию, но похоже, функции объединителя для внутренних узлов (описанных здесь: https://github.com/olalonde/proof-of-liabilities#internal-node), Который состоит в следующем:

Код:

Функция NodeCombiner (left_child, right_child) {
  вар п = {};
  n.sum = left_child.sum + right_child.sum;
  n.hash = sha256 (строка (n.sum) + '|' + left_child.hash + '|' + right_child.hash);
  вернуться п;
}

уязвим к атаке, в которой испытатель заменяет выражение для n.sum с

Код:

n.sum = макс (left_child.sum, right_child.sum)

Это незаметное кем просит для доказательства включения в пассиве Merkle дерева. Исправление для этого было бы заменить выражение для n.hash с чем-то вроде

Код:

n.hash = sha256 (строка (left_child.sum) + '|' + строка (right_child.sum) + '|' + left_child.hash + '|' + right_child.hash)

Был ли этот воспитанный / имя? Дайте мне знать, если это неясно.

Привет charlescharles,

Хороший улов. На самом деле это имя в рецензия iwilcox в --- Grep для "аналогичное спаривание клиента трюк", На самом деле это безопасно, так как сумма для каждого узла является частью его хэш. Это означает, что если вы попытаетесь обнуления одного из детей, хэш ребенка изменится. Таким образом, даже несмотря на то, unsummed ребенка суммы явно не хэшируются, то находятся стремится как часть хэшей дочерних узлов. Я надеюсь, что имеет смысл.

Кстати, в будущем, если вы думаете, что вы нашли безопасность / крипто ошибку, то лучше людям, ошибки в частном (в данном случае olalonde или gmaxwell бы уместно - или идти на IRC # Bitcoin-мастер и просим PM кто-нибудь). Особенно, если есть возможность потери средств (если неправильные люди знают, о чем-то, прежде чем он фиксирован) отвечает раскрытие имеет решающее значение.

Спасибо за аудит кода!

Андрей

Эй Энди,

Я не уверен, что исправляет эту проблему, хотя. Назовем свойства каждого узла «значение» и «хэш» ( «значение» вместо «суммы»). Давайте посмотрим на узел «конца», узел P, с двумя листьями, один клиент А с 10 BTC и еще один клиент B с 5 BTC. Допустим, вы компания, и вы хотите сделать вид, ваши обязательства меньше, чем они на самом деле. Затем построить этот узел, как

Код:

Узел P
значение = 10
хэш = sha256 (10 | Hasha | hashB)

/ \
Клиент Клиент Б
значение = 10 значение = 5
хэш = Hasha хэш = hashB

В этом случае, когда А хочет доказательство включения, вы даете узел Р А, и сказать А, значение ее парный клиент равно 0. Это проверяет, так считает вас, потому что P.value = 10 = 10 + 0. Если B хочет доказательство включения, вы все еще дают точно такой же узел Р б, и сказать б, что значение его парными клиента является 5, и это проверяет для него, потому что P.value = 10 = 5 + 5. Там нет никакого способа для B в убедитесь, что значение хэшируются в Hasha на самом деле 10, а не 5.

Вы повторите эту процедуру для всех узлов на ветви А в до корня. Обратите внимание, что вы никогда не изменять хэши, а свойство Merkle имеет; все, что вам сделать, это фальсифицировать значение заглушек вы говорите человек для Другие филиал. Также обратите внимание, что это не требует какого-либо специального спаривания; это дефект в самой функции узла-комбинирования.

Спасибо за информацию, кстати! Я сделаю все, что в будущем.

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

Но дело в том, что для того, чтобы избежать этой уязвимости, клиент должен был бы проверить прообразы прообразов хэшей в счет-корневого пути - то есть, если клиент node.left, он должен знать, узел .value, node.hash, node.right.userAccount, node.right.value, node.right.hash и node.right.nonce. Это не достаточно, чтобы знать node.right.hash и node.right.value, потому что вы не можете быть уверены, что node.right.value такое же значение, которое было хэшируются для создания node.right.hash.

Если вы посмотрите на это -

Код:

hexstr (firstfourbytes (sha256 ( "satoshi@example.com3333ab00" ))) = E4fd9d12

значение равно 3333, а Nonce представляет ab00. Если испытатель говорит вам, "Хэш этого узла является e4fd9d12 и его значение равно 0", У вас нет способа проверки это не верно, если вы не знаете "satoshi@example.com" а также "ab00", В этом случае вы могли бы видеть, что hexstr (firstfourbytes (SHA256 ("satoshi@example.com0ab00"))) Не совпадает.

Принимая мой пример выше, если вы клиент А, доказывающая вполне может сказать вам хэш, что узел B является hashB и значение узла B равно 0. Это будет соответствовать, потому что P.value = 10 + 0, и P.hash = хэш (10 | Hasha | hashB). Если вы клиента B, доказывающая может сказать вам, что узел Хэш A является Hasha и узел значение А составляет 5. Это также соответствует, потому что P.value = 5 + 5 и P.hash = хэш (10 | Hasha | hashB) , Имеет ли это смысл?

Вы осмысление. То, что я хочу сказать, что в iwilcox рецензии, вся информация является предоставляется пользователю для проверки хэш-прообразы. Что делает включать пользовательские данные для одного другого пользователя, по-видимому, хотя я помню некоторые дискуссии во время gmaxwell предложил это об очистке, что до ..

Если нет, что это так, то это уже не дерево Merkle в том смысле, что доказательства включения теперь взять O (N) (вместо O (Lg (N))) пространства. Рассмотрим корень с четырьмя листьями и тремя внутренними узлами:

Код:

если nodeE хочет доказательство включения, nodeE необходимо требовать nodeD.name и nodeD.val для проверки hashD для того, чтобы убедиться, что valB правильно. Обратите внимание, что это в гораздо больше, чем требуется для стандартного Merkle дерева доказательства включения, в котором nodeE просто требует hashD, а не Вальд. Теперь, чтобы проверить Вал, боб нуждается valC, но боб не может быть уверен, что valC на самом деле хэш в hashC. Так что теперь качаются также нуждается в hashF, valF, hashG и Valg, чтобы проверить valC = valF + Valg. Но Боб не может быть уверен, что valF или Valg либо, если он не знает названия «ЧАРЛИ» и «Давид» в дополнение к hashF и hashG, чтобы проверить правильность этих двух хешей. Как вы можете видеть, это уже не только пользовательские данные для одного другого пользователя, но пользовательские данные для каждого другого пользователя в дереве.

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

Это не достаточно, хотя. В приведенном выше примере, если узел Е получает узел D, узел В, узел А и узел C (так как он не будет в стандартном включении Merkle доказательства) не было бы никакого способа, чтобы проверить, что на самом деле nodeC.val значение в nodeC. хэш. Испытатель мог фальсифицировать nodeC.val без изменения nodeC.hash, и не было бы никакого способа для nodeE, чтобы обнаружить это. В этом случае испытатель мог бы сказать, что nodeE nodeC.val = 2 и nodeA.val = 2 + 2 = 4, и nodeE не смогли бы проверить это.

Цитата: charlescharles от 08 октября 2014 года, 2:09:16 PM

Испытатель мог фальсифицировать nodeC.val без изменения nodeC.hash

Прувер нельзя, так как nodeC.hash = Н (4 || nodeC.left_child_hash || nodeC.right_child_hash) и пользователю предоставляется все три части информации в хэш (как часть nodeC). Для того, чтобы изменить значение nodeC прувер должны были бы находить строки X, Y такие, что nodeC.hash = Н (2 || Х || У), что невозможно, если Н является столкновение устойчивостью хэш-функции.

Цитата: andytoshi от 08 октября 2014 года, 2:25:01 PM

Согласен, это то, что я говорил раньше. Узел Е должен требовать больше, чем просто от узла С доказывающей; узел E нуждается nodeC.left.hash, nodeC.left.value, nodeC.right.hash и nodeC.right.value для проверки узла C.hash. Но тогда вы столкнетесь с той же проблемой, с nodeC.left и nodeC.right - вам нужен их хэш-прообраз, а также для проверки их значений и хэш.

Мне очень нравится Merkle дерева решение обезличения пользователей и холдингов.

Но извините, если я пропускаю что-то здесь, как любое из этого доказательства платежеспособности? Я могу видеть, что это доказательство ответственности, но, чтобы доказать состоятельность мы должны были бы видеть публичные адреса горячих и холодных кошельки?

Эта схема не анонимная, что многое - вы все равно знаете значение, занимаемое ваши "в паре" пользователь. Доказательство резервов осуществляется путем подписания некоторых строк с секретными ключами, контролирующих UTXOs добавления к стоимости вашего заявленному резерва. Там нет необходимости раскрывать какие-либо публичные адреса для доказательства правильности ответственности, только для доказательства-из-заповедника.

Во всяком случае, точка этой нити является то, что функции узла комбинирования дерева доказательства правильности ответственности является дефектным, по причинам, я объяснил выше.

Цитата: charlescharles от 08 октября 2014 года, 2:37:55 PM

Цитата: andytoshi от 08 октября 2014 года, 2:25:01 PM

Вам не нужно их хэш-прообразы. Если эти хэш неверны он будет обнаружен пользователями, чьи Merkle пути идут через эти узлы.

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

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

Но проверяющий не может вычислить nodeC.hash без зная также детские nodeC в хэши, правильно?

Эта логика не относится к детям nodeC, а также, и так далее, пока листья.

Испытатель обеспечивает дочерние хэши nodeC в. Там нет необходимости, чтобы убедиться, что они правильны, то есть работа контролеров, чьи Merkle пути идут через nodeC.

Цитата: andytoshi от 08 октября 2014 года, 5:07:54 PM

Испытатель обеспечивает дочерние хэши nodeC в. Там нет необходимости, чтобы убедиться, что они правильно

Это верно, но проверяющий должен убедиться, что nodeC.value правильно. Там нет никакого способа проверить, что без проверки также nodeC.hash. Единственный способ проверить nodeC.value этого значения в nodeC.hash является вычислением хэша (nodeC.value | nodeC.left.hash | nodeC.right.hash) и сравнивая это значение nodeC.hash - вы согласны?

7 октября 2014, 2:56:28 PM	# 1
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я мог бы смотреть на старую версию, но похоже, функции объединителя для внутренних узлов (описанных здесь: https://github.com/olalonde/proof-of-liabilities#internal-node), Который состоит в следующем: Код: Функция NodeCombiner (left_child, right_child) { вар п = {}; n.sum = left_child.sum + right_child.sum; n.hash = sha256 (строка (n.sum) + '\|' + left_child.hash + '\|' + right_child.hash); вернуться п; } уязвим к атаке, в которой испытатель заменяет выражение для n.sum с Код: n.sum = макс (left_child.sum, right_child.sum) Это незаметное кем просит для доказательства включения в пассиве Merkle дерева. Исправление для этого было бы заменить выражение для n.hash с чем-то вроде Код: n.hash = sha256 (строка (left_child.sum) + '\|' + строка (right_child.sum) + '\|' + left_child.hash + '\|' + right_child.hash) Был ли этот воспитанный / имя? Дайте мне знать, если это неясно.

7 октября 2014, 9:31:00 PM	# 2
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Получил 1806 Биткоинов Реальная история. Привет charlescharles, Хороший улов. На самом деле это имя в рецензия iwilcox в --- Grep для "аналогичное спаривание клиента трюк", На самом деле это безопасно, так как сумма для каждого узла является частью его хэш. Это означает, что если вы попытаетесь обнуления одного из детей, хэш ребенка изменится. Таким образом, даже несмотря на то, unsummed ребенка суммы явно не хэшируются, то находятся стремится как часть хэшей дочерних узлов. Я надеюсь, что имеет смысл. Кстати, в будущем, если вы думаете, что вы нашли безопасность / крипто ошибку, то лучше людям, ошибки в частном (в данном случае olalonde или gmaxwell бы уместно - или идти на IRC # Bitcoin-мастер и просим PM кто-нибудь). Особенно, если есть возможность потери средств (если неправильные люди знают, о чем-то, прежде чем он фиксирован) отвечает раскрытие имеет решающее значение. Спасибо за аудит кода! Андрей

7 октября 2014, 9:56:02 PM	# 3
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Эй Энди, Я не уверен, что исправляет эту проблему, хотя. Назовем свойства каждого узла «значение» и «хэш» ( «значение» вместо «суммы»). Давайте посмотрим на узел «конца», узел P, с двумя листьями, один клиент А с 10 BTC и еще один клиент B с 5 BTC. Допустим, вы компания, и вы хотите сделать вид, ваши обязательства меньше, чем они на самом деле. Затем построить этот узел, как Код: Узел P значение = 10 хэш = sha256 (10 \| Hasha \| hashB) / \ Клиент Клиент Б значение = 10 значение = 5 хэш = Hasha хэш = hashB В этом случае, когда А хочет доказательство включения, вы даете узел Р А, и сказать А, значение ее парный клиент равно 0. Это проверяет, так считает вас, потому что P.value = 10 = 10 + 0. Если B хочет доказательство включения, вы все еще дают точно такой же узел Р б, и сказать б, что значение его парными клиента является 5, и это проверяет для него, потому что P.value = 10 = 5 + 5. Там нет никакого способа для B в убедитесь, что значение хэшируются в Hasha на самом деле 10, а не 5. Вы повторите эту процедуру для всех узлов на ветви А в до корня. Обратите внимание, что вы никогда не изменять хэши, а свойство Merkle имеет; все, что вам сделать, это фальсифицировать значение заглушек вы говорите человек для Другие филиал. Также обратите внимание, что это не требует какого-либо специального спаривания; это дефект в самой функции узла-комбинирования. Спасибо за информацию, кстати! Я сделаю все, что в будущем.

7 октября 2014, 10:28:21 PM	# 4
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Мое чтение поста iwilcox в (ну, мое чтение большой диаграммы с узлами кружком) является то, что прообразы ребенка узла хэшей (только прообразы хэшей фактически в пути от учетной записи пользователя к корню --- все дерево не расширен, конечно!) предоставляются пользователю, так что пользователь может проверить это. Я не проверил, что это то, что на самом деле делает olalonde код с, но я бы ожидать, что это будет так.

7 октября 2014, 10:47:59 PM	# 5
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Но дело в том, что для того, чтобы избежать этой уязвимости, клиент должен был бы проверить прообразы прообразов хэшей в счет-корневого пути - то есть, если клиент node.left, он должен знать, узел .value, node.hash, node.right.userAccount, node.right.value, node.right.hash и node.right.nonce. Это не достаточно, чтобы знать node.right.hash и node.right.value, потому что вы не можете быть уверены, что node.right.value такое же значение, которое было хэшируются для создания node.right.hash. Если вы посмотрите на это - Код: hexstr (firstfourbytes (sha256 ( "satoshi@example.com3333ab00" ))) = E4fd9d12 значение равно 3333, а Nonce представляет ab00. Если испытатель говорит вам, "Хэш этого узла является e4fd9d12 и его значение равно 0", У вас нет способа проверки это не верно, если вы не знаете "satoshi@example.com" а также "ab00", В этом случае вы могли бы видеть, что hexstr (firstfourbytes (SHA256 ("satoshi@example.com0ab00"))) Не совпадает. Принимая мой пример выше, если вы клиент А, доказывающая вполне может сказать вам хэш, что узел B является hashB и значение узла B равно 0. Это будет соответствовать, потому что P.value = 10 + 0, и P.hash = хэш (10 \| Hasha \| hashB). Если вы клиента B, доказывающая может сказать вам, что узел Хэш A является Hasha и узел значение А составляет 5. Это также соответствует, потому что P.value = 5 + 5 и P.hash = хэш (10 \| Hasha \| hashB) , Имеет ли это смысл?

8 октября 2014, 12:48:10 PM	# 6
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Вы осмысление. То, что я хочу сказать, что в iwilcox рецензии, вся информация является предоставляется пользователю для проверки хэш-прообразы. Что делает включать пользовательские данные для одного другого пользователя, по-видимому, хотя я помню некоторые дискуссии во время gmaxwell предложил это об очистке, что до ..

8 октября 2014, 1:16:24 PM	# 7
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Если нет, что это так, то это уже не дерево Merkle в том смысле, что доказательства включения теперь взять O (N) (вместо O (Lg (N))) пространства. Рассмотрим корень с четырьмя листьями и тремя внутренними узлами: Код: узла А Валы = 4 Hasha = хэш (значение \| hashB \| hashC) / \ Узел nodeC valB = 2 valC = 4 hashB = хеш (2 \| hashD \| hashE) hashC = хеш (4 \| hashF \| hashG) / \ / \ узловая nodeE nodeF nodeG Vald = 1 Вейл = 2 valF = 3 Valg = 4 hashD = хеш ( 'алиса' \| 1) hashE = хеш ( 'боб' \| 2) hashF = хеш ( 'чарли' \| 3) hashG = хеш ( 'Дэвид' \| 4) если nodeE хочет доказательство включения, nodeE необходимо требовать nodeD.name и nodeD.val для проверки hashD для того, чтобы убедиться, что valB правильно. Обратите внимание, что это в гораздо больше, чем требуется для стандартного Merkle дерева доказательства включения, в котором nodeE просто требует hashD, а не Вальд. Теперь, чтобы проверить Вал, боб нуждается valC, но боб не может быть уверен, что valC на самом деле хэш в hashC. Так что теперь качаются также нуждается в hashF, valF, hashG и Valg, чтобы проверить valC = valF + Valg. Но Боб не может быть уверен, что valF или Valg либо, если он не знает названия «ЧАРЛИ» и «Давид» в дополнение к hashF и hashG, чтобы проверить правильность этих двух хешей. Как вы можете видеть, это уже не только пользовательские данные для одного другого пользователя, но пользовательские данные для каждого другого пользователя в дереве.

8 октября 2014, 2:00:37 PM	# 8
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Это по-прежнему логарифмическая. Вы только выявить прообразы соседних хэш (которые включают в себя сумму для непосредственных детей все в вашем Merkle пути), нет необходимости в дальнейшей рекурсии.

8 октября 2014, 2:09:16 PM	# 9
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Это не достаточно, хотя. В приведенном выше примере, если узел Е получает узел D, узел В, узел А и узел C (так как он не будет в стандартном включении Merkle доказательства) не было бы никакого способа, чтобы проверить, что на самом деле nodeC.val значение в nodeC. хэш. Испытатель мог фальсифицировать nodeC.val без изменения nodeC.hash, и не было бы никакого способа для nodeE, чтобы обнаружить это. В этом случае испытатель мог бы сказать, что nodeE nodeC.val = 2 и nodeA.val = 2 + 2 = 4, и nodeE не смогли бы проверить это.

8 октября 2014, 2:25:01 PM	# 10
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Цитата: charlescharles от 08 октября 2014 года, 2:09:16 PM Испытатель мог фальсифицировать nodeC.val без изменения nodeC.hash Прувер нельзя, так как nodeC.hash = Н (4 \|\| nodeC.left_child_hash \|\| nodeC.right_child_hash) и пользователю предоставляется все три части информации в хэш (как часть nodeC). Для того, чтобы изменить значение nodeC прувер должны были бы находить строки X, Y такие, что nodeC.hash = Н (2 \|\| Х \|\| У), что невозможно, если Н является столкновение устойчивостью хэш-функции.

8 октября 2014, 2:37:55 PM	# 11
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Цитата: andytoshi от 08 октября 2014 года, 2:25:01 PM Прувер нельзя, так как nodeC.hash = Н (4 \|\| nodeC.left_child_hash \|\| nodeC.right_child_hash) и пользователю предоставляется все три части информации в хэш (как часть nodeC). Согласен, это то, что я говорил раньше. Узел Е должен требовать больше, чем просто от узла С доказывающей; узел E нуждается nodeC.left.hash, nodeC.left.value, nodeC.right.hash и nodeC.right.value для проверки узла C.hash. Но тогда вы столкнетесь с той же проблемой, с nodeC.left и nodeC.right - вам нужен их хэш-прообраз, а также для проверки их значений и хэш.

8 октября 2014, 3:12:38 PM	# 12
throwaway084575 Сообщений: 12 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Мне очень нравится Merkle дерева решение обезличения пользователей и холдингов. Но извините, если я пропускаю что-то здесь, как любое из этого доказательства платежеспособности? Я могу видеть, что это доказательство ответственности, но, чтобы доказать состоятельность мы должны были бы видеть публичные адреса горячих и холодных кошельки?

8 октября 2014, 3:19:00 PM	# 13
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Эта схема не анонимная, что многое - вы все равно знаете значение, занимаемое ваши "в паре" пользователь. Доказательство резервов осуществляется путем подписания некоторых строк с секретными ключами, контролирующих UTXOs добавления к стоимости вашего заявленному резерва. Там нет необходимости раскрывать какие-либо публичные адреса для доказательства правильности ответственности, только для доказательства-из-заповедника. Во всяком случае, точка этой нити является то, что функции узла комбинирования дерева доказательства правильности ответственности является дефектным, по причинам, я объяснил выше.

8 октября 2014, 3:26:44 PM	# 14
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Цитата: charlescharles от 08 октября 2014 года, 2:37:55 PM Цитата: andytoshi от 08 октября 2014 года, 2:25:01 PM Прувер нельзя, так как nodeC.hash = Н (4 \|\| nodeC.left_child_hash \|\| nodeC.right_child_hash) и пользователю предоставляется все три части информации в хэш (как часть nodeC). Согласен, это то, что я говорил раньше. Узел Е должен требовать больше, чем просто от узла С доказывающей; узел E нуждается nodeC.left.hash, nodeC.left.value, nodeC.right.hash и nodeC.right.value для проверки узла C.hash. Но тогда вы столкнетесь с той же проблемой, с nodeC.left и nodeC.right - вам нужен их хэш-прообраз, а также для проверки их значений и хэш. Вам не нужно их хэш-прообразы. Если эти хэш неверны он будет обнаружен пользователями, чьи Merkle пути идут через эти узлы.

8 октября 2014, 3:32:46 PM	# 15
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Испытатель не в любой момент изменить хэш, только значение, что он говорит людям для доказательства включения. Причина вы не можете доверять (что испытатель говорит за) nodeC.value является то, что вы не можете быть уверены, что это то же самое значение, которое находится в nodeC.hash.

8 октября 2014, 3:35:09 PM	# 16
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Значение каждого узла является частью ввода в хэш для этого узла. Проверяющий может вычислить это сам, доказывающая не нужно делать какие-либо претензии по этому поводу.

8 октября 2014, 3:41:33 PM	# 17
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Но проверяющий не может вычислить nodeC.hash без зная также детские nodeC в хэши, правильно? Эта логика не относится к детям nodeC, а также, и так далее, пока листья.

8 октября 2014, 5:07:54 PM	# 18
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Испытатель обеспечивает дочерние хэши nodeC в. Там нет необходимости, чтобы убедиться, что они правильны, то есть работа контролеров, чьи Merkle пути идут через nodeC.

8 октября 2014, 5:10:47 PM	# 19
charlescharles Сообщений: 11 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Цитата: andytoshi от 08 октября 2014 года, 5:07:54 PM Испытатель обеспечивает дочерние хэши nodeC в. Там нет необходимости, чтобы убедиться, что они правильно Это верно, но проверяющий должен убедиться, что nodeC.value правильно. Там нет никакого способа проверить, что без проверки также nodeC.hash. Единственный способ проверить nodeC.value этого значения в nodeC.hash является вычислением хэша (nodeC.value \| nodeC.left.hash \| nodeC.right.hash) и сравнивая это значение nodeC.hash - вы согласны?

8 октября 2014, 5:33:06 PM	# 20
andytoshi Сообщения: 170 Цитировать по имени цитировать ответ	Re: Уязвимость в реализации olalonde о корректуре из-платежеспособности gmaxwell в Да.

Заголовок