Комментарии 18
Замечу, что ничто не мешает использовать нашу технологию связывания транзакций в контексте тех решений (с позволения сказать), которые разработчики протокола REMME предлагают для PKI.
Я регаю миллион аккаунтов, беру чей-то паблик и начинаю его подписывать своими миллонами аккаунтов
Как быстро ваш солюшин загнется до неработоспособного состояния, если брать время транзакции в 1 минуту?
- Откуда берется Hash(n, 0) для нулевой транзакции?
- Что именно содержится в «нотификате»? Только публичный ключ или что-то ещё? Например в X.509 сертификате предусмотрены политики применения сертификата (ограничения области применения);
- Опишите как можно подробнее какой-либо сценарий использования «нотификата». Желательно прямо от процесса подписывания чего-то и до процесса проверки, что вот это что-то подписано именно вот этим «нотификатом» (откуда берется «нотификат» для проверки
- На рисунке, поясняющем процесс проверки нулевой транзакции элемент «общедоступный ключ» не нужен: публичный ключ для кошелька берется из поля «signature». Или это какой-то другой «общедоступный ключ»? В этом случае непонятно как он используется для создания нулевой транзакции
- Зачем нужна «служебная ключевая пара»? Фактически в статье она применяется как некий идентификатор для определённого кошелька. Однако у самого кошелька уже есть своя ключевая пара. Этот же ключ кошелька может быть использован и для проверки транзакций отличных от нулевой. А если рассматривать использование «служебной пары» как доказательства регистрации субъекта в системе, то для такой регистрации опять можно использовать ключ самого кошелька
- Предположим, что злоумышленник зарегистрирован как участник системы. Затем он перехватывает несколько идущих подряд сообщений от другого пользователя и знает несколько предыдущих значений H(n-x). Как мне кажется, в этом случае злоумышленник сможет в новой транзакции от другого пользователя заменить все H корректными значениями и подставить свой публичный ключ. Так злоумышленник может присвоить публичный ключ
- Понимают ли создатели данной системы, что «ёмкость» данной системы (количество публичных ключей хранящихся в системе) ограничена 2^256 при применении SHA-256? Эта цифра обусловлена тем, что информация об общедоступных ключах тут хранится в виде хэшей
- В начале статьи обозначены две проблемы PKI: централизация системы и начальная аутентификация пользователей. Было предложено решение только для первой проблемы. Использование же blockchain системы ведёт к противоречию: изначально blockchain обезличивает пользователей, а в системе DPKI стоит задача корректной идентификации таких пользователей
Дайте ваш email и мы вам вышлем полноценный документ. Если всё же останутся вопросы, то тогда дадим на них ответы.
Пусть ёмкость ограничена числом 2^256. Вы понимаете сколько это? Этого мало что-ли? В чём здесь проблема? Если ключи формируются так, что гарантируется их равномерное и независимое распределение, а именно это и предполагается, то значение хеш-функции будет так же распределено равномерно и независимо на пространстве значений 2^256.
Конкретные числа действительно большие. Однако если уж предлагаете какую-то "инновацию" рекомендую предусматривать возможность разрастания базы. Это всегда полезно. И где же обещанный документ, объясняющий мне остальные мои вопросы?
Нам нужно время для принятия решения. Поймите, у нас перед вами нет никаких специальных обязательств, а мы пока до конца не понимаем зачем вам это нужно.
У меня есть подозрения, что описываемая здесь система достаточно ущербна. Но чтобы это подтвердить или опровергнуть мне нужны дополнительные сведения.
Ок. Для начала почитайте вот эту заявку https://patents.google.com/patent/WO2020076178A1/fr?inventor=Chmora&oq=Chmora
Любой патент просто признаёт, что подобное в данной патентной системе отсутствует (новизна изобретения), а также как-то закрепляет право на это изобретение за заявителем. Корретно ли изобретение для патента маловажно.
DPKI: устраняем недостатки централизованной PKI при помощи блокчейна