Перевод Журнал встречи исследовательской лаборатории Monero от 2020-08-19

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 1 сен 2020.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    188
    Симпатии:
    13
    Когда: Среда, 19 августа 2020 года @ 17:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    Журнал встречи:

    <sarang> Отлично!
    <sarang> Начнем нашу встречу
    <sarang> Повестка дня: https://github.com/monero-project/meta/issues/499
    <sarang> Как всегда, журнал будет размещен после окончания встречи
    <sarang> Во-первых, приветствия!
    <sarang> hi
    <endogenic> ullo
    — sarang ждёт несколько минут, пока присоединятся другие участники
    <Isthmus>
    holup! Что-то я не могу найти свои очки
    v1docq47[m] вышел (~v1docq47m@89.113.140.59): Причина: Бездействие в течение 265секунд
    <sarang>
    безопасность прежде всего
    <Isthmus> Ой, под кроватью... конечно ...
    Isthmus надевает очки и лабораторный халат
    <Isthmus>
    Окей, продолжаем
    <endogenic> Ууу, и сеточку для волос не забудьте
    Isthmus закрывает крышку ноутбука, на которой размещена веб-камера
    <sarang>
    Хорошо, дальше мы направляемся к нашему круглому столу, где каждый желающий может поделиться своими интересными темами исследований
    <sarang> Кто-нибудь хочет пойти первым?
    <endogenic> Саранг хочет
    <sarang> Если нет, у меня есть несколько вещей, которыми я хочу поделиться с вами
    <endogenic> Саранг - это все, что нам нужно
    <sarang> Я веду дискуссию с комитетом по стандартам ISO в США относительно конфиденциальности в основе блокчейна
    <sgp_> привет
    <sarang> Моя цель — предоставить более точную техническую информацию
    <sarang> Я предоставлю подробную информацию об этом по мере продвижения
    <endogenic> интригующе
    <sarang> Я внес небольшие изменения в код Arcturus / Triptych для повышения эффективности хранения данных
    <endogenic> звучит как формализация отслеживаемости и последующих искажений и т. д., будет ли он полезен?
    <sarang> Я уже проверил препринт статьи о Triptych, подготовленной рабочей группой пропаганды, и теперь с нетерпением жду публикации.
    <sarang> также подготовил несколько PR, связанных с подтверждением транзакций и подписанием сообщений
    sdsdsd подключился (4131268e@65.49.38.142)
    <sarang>
    Один PR в ключе шифрования ключей был отменен, поскольку его тесты не обеспечили должным образом необходимой функциональности
    <sarang> Любой, кому довелось проверить эту сборку, обнаружит, что его кошельки теперь работают нормально (после отмены изменений или до применения PR).
    <sarang> Спасибо, selsta, за выявление данной проблемы
    <sarang> И, наконец, у меня есть работающие доказательства концепции кода Bulletproofs+
    <sarang> Первоначально система доказательств проверяла внутренние обязательства
    <sarang> Кроме того, теперь работают агрегированные доказательства диапазона и более эффективный верификатор с развернутой рекурсией
    <endogenic> люблю, когда есть над чем работать :p
    <sarang> На данный момент все работает как и было задумано
    <sarang> Сейчас я работаю над полным пакетом BP + поэтапно, как я делал это в BP и некоторых других связанных проектах
    <sarang> Спасибо, endogenic!
    <endogenic> Поможет ли наличие альтернативной сборки в вашем исследовании?
    <sarang> Думаю, что вскоре у меня появится полный пакетный сборщик на основе Python, после чего переход на C++ не составит проблем
    <sarang> endogenic: конечно! поскольку я уверен, что в C ++ есть небольшие оптимизации, которые были бы очень кстати
    <sarang> И я планирую заняться этим вопросом в ближайшие дни
    <sarang> В любом случае на этом у меня все
    <endogenic> где-то я уже встречал подобную реализацию
    <sarang> Я с радостью отвечу на любые ваши вопросы
    <sarang> Кто-нибудь еще желает поделиться интересными исследованиями?
    <ArticMine> Я продолжаю размышлять о рисках Arcturus и Triptych. Если точнее - я имею в виду размер транзакций в Arcturus
    <sarang> Я не знаю, как правильно оценить практический риск нестандартного размера транзакций в Arcturus.
    <sarang> Рецензенты сходятся в утверждении, что это предположение на текущий момент небезопасно, хотя я не согласен с их точкой зрения
    <sarang> и они не предоставили никаких дополнительных подробностей
    <sarang> Думаю, что я возьму дополнительную паузу
    <sarang> Я считаю, что они неправильно прочитали определение
    <sarang> (я собирался опубликовать это раньше, но совершенно забыл про это)
    <EmmanuelLagos> мне интересно узнать больше о том, насколько это предположение небезопасно, и о возможных последствиях...
    <sarang> В предположении есть несколько условий.
    <sarang> и похоже, что заявленные рецензентом ошибки распространяются не на все подходы (именно поэтому существует несколько условий)
    <sarang> их ответ был примерно таким: "мы продолжим", но без каких-либо дополнительных подробностей.
    <EmmanuelLagos> ха, как скучно
    <EmmanuelLagos> с нетерпением буду ждать обновлений
    <EmmanuelLagos> спасибо
    <sarang> Я думаю, что рецензент неверно истолковал последнее условие, которое особенно отличается от других.
    <sarang> И если есть проблема, я обязательно узнаю об этом
    <sarang> это обычный вопрос препринтов и рецензирования!
    <ArticMine> Есть еще какие-нибудь мнения по этому поводу?
    <ArticMine> Я знаю, что рецензирование это довольно сложный процесс
    <sarang> Да, это сложно
    <sarang> Вот почему я надеюсь на послабление для этого предположения.
    <sarang> но на текущий момент его нет
    sdsdsd вышел (4131268e@65.49.38.142): Причина: Бездействие в течение 245 секунд
    <sarang>
    В любом случае я скоро опубликую комментарии рецензента
    <sarang> (наверное, после окончания этой встречи; нужно проверить электронную почту)
    <ArticMine> Большое спасибо
    <sarang> не за что
    <Isthmus> Как всегда, великолепная работа :- )
    <sarang> Еще раз большое спасибо!
    <sarang> Кто-нибудь еще желает поделиться своими исследованиями?
    <Isthmus> У меня быстрое обновление и один назревший вопрос
    <Isthmus> Что касается обновления, мы переключились на написание официальной документации. И я нахожу это захватывающим! Вместо «X алгоритм нарушает функцию Y» мы фактически показываем шаг за шагом, как механизм Y может быть сломан.
    <sarang> Великолепно!
    <Isthmus> у нас уже есть черновик для публичных комментариев, но представим мы его только на следующей неделе
    <Isthmus> забавно наблюдать за атаками в виде такой интерактивной игры
    <sarang> Буду рад прочитать :)
    <sarang> Чтобы уточнить, там будут гипотетические атаки квантового злоумышленника?
    <endogenic> согласен, этот момент был упущен ранее
    <Isthmus> Пока ничего не могу сказать о сроках
    <Isthmus> всё зависит от алгоритма
    <Isthmus>график QC вне рамок нашего исследования
    <sarang> я просто имею в виду, что такие атаки считаются невозможными с учетом современных технологий
    <sarang> (чтобы избежать ненужных FUD и поддерживать только актуальные.. )
    Isthmus даже не пытается делать догадки о возможных сроках конечного исследовательского документа
    <Isthmus>
    Учитывая ДОСТУПНЫЕ технологии на текущий момент - это определенно невозможно
    <sarang> Я не хочу заставлять кого-либо размышлять о квантовых вычислениях
    <sarang> Спасибо :)
    <sarang> Основной упор должен быть сосредоточен на том, чтобы сконцентрироваться на алгоритмах, а не на конкретных вычислительных возможностях злоумышленника
    <hyc> независимо от типа исследований, очевидно, что существующие алгоритмы, устойчивые к контролю качества, несопоставимые с текущими технологиями.
    <sarang> Что ж, это часть нашего исследования, не так ли?
    <hyc> никто не собирается запускать сеть, используя ключи размером больше мегабайта и т. д...
    <sarang> Глядя на текущие исследования и направления?
    <endogenic> вызов принят!
    <ArticMine> Вопрос заключается в том, что возможны ли какие-то смягчения текущих моделей?
    <hyc> * это невозможно на современных компьютерах
    <hyc> единственными компьютерами, способными выполнять контроль качества, будут большие сервера, чье внедрение убьет дух децентрализации
    <sarang> Isthmus: из чистого любопытства, знаете ли вы о каких-либо других крупных проектах, изучающих уязвимости на таком уровне?
    <sarang> Я согласен с hyc в том, что любые предлагаемые меры по смягчению последствий после контроля качества должны быть сбалансированы
    <sarang> но, судя по тому, что я читал, это не является основной целью этого исследования
    <sarang> с другой стороны, понимание уязвимых мест протокола тоже полезно
    <sarang> как понимание того, в каком состоянии находятся исследования сегодня и куда они будут двигаться
    <Isthmus> Насколько мне известно, Monero лидирует в области посткватнтовых исследований
    <sarang> Но это определенно не говорит в пользу Isthmus и его команды
    <Isthmus> Quantum Resistant Ledger имеет механизмы постквантовой безопасности, но не механизмы конфиденциальности
    <sarang> Отлично :)
    <Isthmus> Было несколько статей в ключе Bitcoin, но они, как правило, рассматривают только 1-2 алгоритма, что далеко от комплексного уровня противодействия
    <sarang> Да, я знаю о QRL, но кажется, что на данный момент он не получил широкого распространения
    <sarang> Я встретил одного из руководителей QRL на недавней конференции
    <Isthmus> Они сейчас заняты каким-то крутым проектом
    <Isthmus> ZK-lattice, STARKs и агрегирование pq-подписи
    <sarang> Isthmus: у вас есть ссылки на сторонние ресурсы в ключе аналогичных исследований?
    <sarang> Я уже давно не следил за их обновлениями
    <Isthmus> документ от QRL довольно легко читаемый, и в нём прилагается "красивый" обзор потенциальных атак и возможных подходов
    <midipoet> Isthmus: может быть, глупый вопрос, но будет ли отчет о проделанной вами работе?
    azy вышел (~azy@unaffiliated/stev3)
    <Isthmus>
    Примечание: https://github.com/theQRL/Whitepaper/blob/master/QRL_whitepaper.pdf
    <sarang> спасибо, Isthmus
    <Isthmus> ^ ссылка на документ
    <Isthmus> Самое интересное то, где они переходят к RandomX, который является практически единственной частью Monero с pq-безопасностью
    <hyc> lol
    <sarang> :D
    <sarang> я этого не знал
    <Isthmus> Да, они следят за исследованиями MRL
    <sarang> великолепно
    Isthmus запускает волну из рук
    <Isthmus>
    Теперь у меня всё! Все технические подробности уже на следующей неделе ^_^
    <sarang> Большое спасибо
    <sarang> Другие темы для обсуждения?
    <sarang> Или вопросы?
    <midipoet> sarang: есть обновления в ключе ISO?
    <midipoet> Извините, если я пропустил их ...
    <sarang> midipoet: Я еще не получил ответ от человека, который занимается логистикой
    <sarang> но я говорил с председателем
    <sarang> он уже разослал приглашения на соответствующие встречи и указал, что моё участие без заполнения и подачи всех документов не должно стать проблемой
    <sarang> учитывая задержки, которые могут случиться
    <hyc> звучит круто
    <sarang> Хорошо, перейдем к ключевым моментам, где каждый желающий может поделиться своими планами исследований на предстоящую неделю
    <sarang> Я планирую завершить код подтверждения концепции BP+ (с полной пакетной обработкой), а затем перейду к его реализации на C++
    <sarang> и займусь подготовкой к публикации предположения о прочности Arcuturus
    <Isthmus> Ой, подождите! У меня же еще был вопрос
    <sarang> Да, конечно, Isthmus
    <Isthmus> https://usercontent.irccloud-cdn.com/file/609yOFnf/image.png
    ErCiccione подключился (~ErCiccion@gateway/tor-sasl/erciccione)
    <Isthmus>
    https://usercontent.irccloud-cdn.com/file/WkDekAar/image.png
    <Isthmus> https://usercontent.irccloud-cdn.com/file/DVzt3Gr6/image.png
    <Isthmus> версия для тех, кто не боится Google: https://docs.google.com/document/d/1TBICG6RFoeTOv-Yn9HEOHvWgSdx2NOtGZ1ckvG9VT8w/edit?usp=sharing
    <sarang> не понял, поясните
    <Isthmus> Материал в желтом цвете не должен быть криптографически случайным / однородным / и т. д.
    <Isthmus> Материал в зеленом должен быть сплошным шумом
    <Isthmus> Никаких повторений / столкновений и т. д.
    <Isthmus> Верно?
    <sarang> Но?
    <Isthmus> У меня пока нет "но", просто спрашиваю, правильно ли это
    <sarang> данные BP будут единообразными для всех доказательств, да
    <sarang> Конечно, можно сгенерировать неоднородные скаляры подписи в уже действительной подписи
    Isthmus кивает
    <sarang>
    Полагаю, вы обнаружили что-то, указывающее на неоднородность?
    <sarang> Обратите внимание, что для BP, насколько мне известно, ничто не мешает использовать обязательство повторно...
    <sarang> что может быть весьма опасно
    <sarang> из-за его отклонений
    <sarang> все, кроме одного скаляра подписи в MLSAG (и CLSAG), выбирается подписывающей стороной и произвольно
    <sarang> У вас может быть действительная подпись с плохими скалярами
    <Isthmus> Это просто мои мысли в стадии генерации гипотез и разработки нового эксперимента
    <Isthmus> мы будем выдвигать гипотезу, что определенные поля должны быть однородными / случайными / не конфликтующими, а затем будем искать контрпримеры
    <sarang> окей
    <sarang> важно отделить то, что находится под контролем подписанта, а что нет.
    <Isthmus> ^^
    <sarang> почти все скаляры MLSAG / CLSAG контролируются подписывающей стороной
    <sarang> что не относится к BP
    <Isthmus> Ах да, мне нужны 3 категории, а не 2
    <sarang> Таким образом, скаляры MLSAG должны быть случайными
    <sarang> и не стоит забывать про дополнительные слои BP
    <Isthmus> 1) контролируемый подписант, с использованием паттернов (например, время блокировки)
    <Isthmus> 2) контролируемый подписант, но присутствует элемент случайности (например, скаляр MLSAG)
    <Isthmus> 3) выход криптографической функции, без паттерна (например, вывод доказательств)
    <sarang> Интересно, что вообще возникла идея использовать хэш-функцию для MLSAG / CLSAG, чтобы позволить скрыть данные или помешать идентифицировать подписывающую сторону
    <sarang> Если это будет реализовано, это поможет избежать плохого PRNG
    <sarang> без принуждения к использованию, конечно
    <Isthmus> ОО! А это интересно!
    <sarang> Да, у меня где-то бы пример кода для подтверждения этой концепции
    <sarang> Вы используете хеш-функцию для всех скаляров, контролируемых подписывающей стороной, а оставшаяся функция равномерно распределена
    <sarang> И подписывающая сторона может использовать это для последующего восстановления индекса подписи
    <sarang> И это крутая идея
    <Isthmus> Отлично!
    <Isthmus> Ладно, на сегодня все, пойду работать над формализацией и разделением материала на сегменты
    <sarang> Великолепно!
    <sarang> Есть ли другие вопросы?
    <sarang> Если нет, то мы закрываемся!
    <sarang> Спасибо всем за то, что приняли участие
    <sarang> Журналы будут опубликованы в ближайшее время

    ---

    Источник: Research meeting: 19 August 2020 @ 17:00 UTC #499

    Перевод:
    Unholy (@Unholy)
    Редактирование:
    Mr. Pickles (@v1docq47)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.