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

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

  1. Unholy

    Unholy Well-Known Monerano

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

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

    1.png

    2.png


    Журнал встречи:

    <sarang> Во-первых, ПРИВЕТСТВИЯ
    <ArticMine> Hi
    <I3^RELATIVISM> 0/
    <Isthmus> Приветствую
    <sarang> Отлично, дальше мы направляемся к нашему КРУГЛОМУ СТОЛУ, где каждый желающий может поделиться своими интересными темами исследований
    <sarang> Кто хотел бы выступить первым?
    <sarang> Isthmus?
    <Isthmus> Heyo
    <Isthmus> У меня есть новая информация в ключе нашего квантового аудита. Вот наш предварительный анализ существующих уязвимостей (стоит отметить, что результаты могут быть изменены в ходе исследований!)
    <Isthmus> https://usercontent.irccloud-cdn.com/file/RKKVcmGZ/image.png
    <Isthmus> https://usercontent.irccloud-cdn.com/file/ZPskux3i/image.png
    <Isthmus> На данный момент это больше похоже на женскую сумочку, где всё перемешано
    <sarang> Полагаю, этого следовало ожидать
    <sarang> Но я вижу много интересных компонентов
    <Isthmus> Как и ожидалось, наша зависимость от DLP - это самое слабое место
    <sarang> угу
    <Isthmus> Вот и всё, у вас есть какие-нибудь вопросы?
    <sarang> Предполагаю, что под "кольцевыми подписями" вы подразумеваете квантового злоумышленника, идентифицирующего индексы подписи с помощью образов ключей?
    → theostorm подключился (~theostorm@host-p8vu8h.cbn1.zeelandnet.nl)
    <isthmus>
    да (или любой подобный механизм)
    <Isthmus> О, забыл упомянуть об одной вещи, о которой мы начали задумываться
    <Isthmus> Если вы создаете multisig-транзакцию и у одного из подписавших есть квантовый компьютер, сможет ли он получить информацию о своих соподписывающих участников?
    <sarang> Теоритически вы можете вычислить приватный ключ целиком
    <sarang> если это то, что вы имеете в виду
    <Isthmus> Да. Мне нужно будет сесть и перечитать ZtM2, чтобы выяснить, как происходит подписание. Я почему-то задумался об этом только вчера
    <sarang> Да, отличное начало
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): Удаленный хост закрыл подключение
    <sarang>
    Я не помню, чтобы кто-то упомянул multisig-транзакции на этапе планирования вашего анализа
    <Isthmus> Да, мы уже добавили это в предстоящие исследования. Вероятно, в течение следующих нескольких недель нами будет реализована еще пара аспектов исследований
    <Isthmus> Не забывайте делиться своими идеями :- )
    <sarang> Существуют ли конкретные предположения, в которых злоумышленник уже имеет публичный ключ?
    <sarang> например, злоумышленник уже подозревает конкретный адрес в качестве пункта назначения выхода
    <Isthmus> Мы предполагаем, что злоумышленник является соподписантом multisig -транзакции. И он в любом случае получит доступ к публичному ключу, на то он и квантовый злоумышленник, верно?
    <Isthmus> [ну, мы можем рассматривать действия злоумышленника с обоих направлений]
    <sarang> Извините, если запутал вас
    <sarang> В смысле не только в отношении multisig
    <Isthmus> Понял, квантовый компьютер с вашим публичным ключом и квантовый компьютер без вашего публичного ключа – это две разные модели злоумышленника, которые мы рассматриваем отдельно
    <Isthmus> Хотя в первом варианте всё намного проще
    <Isthmus> Публичный ключ -> [алгоритм Шора] -> Приватный ключ -> Инициализация кошелька -> game over
    <sgp_> Извините, что опоздал
    <sarang> И ему даже не понадобится "ваш" приватный ключ
    <sarang> хватит простого взгляда на вашу цепочку транзакций
    febrezo[m] вышел (febrezomat@gateway/shell/matrix.org/x-nmwuqdhiryoaaaqy): Причина: Ошибка аутентификации
    febrezo[m] подключился (febrezomat@gateway/shell/matrix.org/x-rbuouyikyggzymnb)
    <sarang>
    особенно если цель злоумышленника состоит в том, чтобы определить как можно больше ключей, адресов и т. д.
    <sarang> адресов отправки и адресов получения и т. д.
    <Isthmus> Да, это актуально, если внешний наблюдатель пытается извлечь транзакции из блокчейна случайным образом, не зная, что они могут прояснить ему в отношении 1) отправителя, 2) самих транзакций, 3) получателя
    <sarang> Правильно. А затем они могу сделать сопоставление с уже имеющимися у них адресами
    <Isthmus> Бинго!
    <sarang> уже есть (или возможно будет) статья с подробным описанием того, что и как соотносится в этой таблице?
    <UkoeHB_> Раньше я утверждал, что вы могли бы просто перебрать все выходы при условии, что DLP "сломан" и адрес получателя неизвестен. Однако теперь я пересмотрел свою точку зрения и понял, что выходные данные теоретически безопасны
    <Isthmus> Понял
    Isthmus делает заметку
    <Isthmus>
    Да, все это будет отражено в дополнительной рецензии, а все остальные моменты попадут в общую рецензию
    <sarang> Вы что-то еще хотите добавить, Isthmus?
    <Isthmus> Мы думали сделать несколько коротких статей, чтобы подогревать интерес публики постепенно
    <Isthmus> Нет, пожалуй, на этом у меня всё
    <sarang> Окей, отлично!
    <Isthmus> Сегодня утром я начал спускаться в "кроличью нору" сублиминальных каналов, но сохраню мои мысли и заметки на потом
    <sarang> Кто-нибудь еще хочет представить своё исследование?
    <UkoeHB_> Это означает, что если DLP и преобраз хеша сломаны, у вас не получится извлечь адрес получателя из вывода.
    <Isthmus> Это всё упрощает, так как мы могли бы рекурсивно применить алгоритм Шора и продвигаться вверх по дереву транзакций, взламывая все кошельки по очереди
    Isthmus с облегчением выдыхает
    thrmo подключился (~thrmo@unaffiliated/thrmo)
    <sarang>
    Хорошо, тогда я поделюсь своими исследованиями
    <sarang> Вот пример временных окон CDF с возрастными тратами: https://usercontent.irccloud-cdn.com/file/5EccXpmE/cdf_window.png
    <sarang> гамма-распределение поддается отслеживанию довольно хорошо, но есть незначительные различия во времени (preCT)
    <sarang> В связи с этим я разместил свой обновленный код: https://github.com/SarangNoether/skunkworks/tree/tracing
    <sarang> Теперь он поддерживает итеративные обновления, которые могут оказаться очень кстати
    <sarang> В дополнение я продолжаю работу с аудиторами CLSAG
    <sarang> Я переписал доказательство для первой теоремы, которое связывает неподдаваемость с фактом невозможности клеветы
    <sarang> И множество других мелких обновлений, не связанных с моделью безопасности
    <sarang> и сейчас я занимаюсь пересмотром доказательства связываемости анонимности, чтобы использовать более точные предположения и метод утверждения, что весьма утомительно
    <sarang> думаю, что учту все их пожелания и комментарии, чтобы получить более сильную модель безопасности
    <sarang> Аудиторы пришли к выводу, что конструкция кажется вполне безопасной, а сама модель безопасности кажется вполне жизнеспособной для её дальнейшего использования
    <sarang> Это, собственно, и была общая цель аудита — проверка предложений, касающихся представления, формальности и т. д.
    <UkoeHB_> Похоже, что с аудитом все отлично
    <sarang> Так точно! Обзор самого кода еще не начался, но уже на этом этапе, рецензенты не нашли никаких ошибок, которые я должен был бы исправить с момента первого аудита препринта.
    <sarang> Есть вопросы по моим темам исследований?
    <sarang> Хорошо, у кого-нибудь еще есть исследования, которыми стоит поделиться, прежде чем мы двинемся дальше?
    <sgp_> неа
    <sarang> Если таковых нет, мы можем перейти к КЛЮЧЕВЫМ МОМЕНТАМ на предстоящую неделю
    <sarang> Я планирую завершить проверку связываемости и добавить все изменения в препринт, который завершит все необходимые подготовки для представления его на аудит
    <sarang> Как только я закончу с правками, я отмечу препринт как "готовый к аудиту"
    <sarang> Кто-то еще?
    <sgp_> Я открою проблему на GitHub для предстоящего разделения выходов из монетной базы
    <sarang> Отличное время, чтобы обсудить это, особенно если мы собираемся провести обновление сети для CLSAG
    <sgp_> Да, я тоже задумался об этом
    <sarang> особенно учитывая недавние возрастные данные
    <sarang> но я все еще хотел бы видеть аналогичные данные для bitcoin
    <sarang> но у меня нет нужных наборов данных
    <sarang> все данные в Monero до реализации CT
    <sarang> и любые данные, полученные уже после реализации CT, тратят старые выходы и, следовательно, бесполезны для такого рода распределений
    <sgp_> без сомнения, получение таких данных для btc было бы конечно здорово, но это и не настолько важно в нашем случае
    <sarang> понял вас
    <sarang> Хорошо, что-нибудь еще, или мы можем закончить на сегодня?
    <UkoeHB_> Isthmus, я должен уходить, но оставлю немного информации для вас (Саранг, прошу прощения, что вот так вот врываюсь посреди беседы). Итак, что касается DLP и преобраза ключа - информационно-теоретическая безопасность ничего не значит перед лицом грубого форсирования всех имеющихся возможностей. Вам потребуется: 1) получить DLP генератора H и обязательство C, 2) выбрать сумму 3) вычислить возможное преобразование в скаляр, 4) получить преобраз хеша
    <UkoeHB_> 4a) использовать последовательность битов ключа из преобраза для проверки закодированной суммы и продолжить работу только в том случае, если он соответствует предполагаемому количеству (конечно, маловероятно, что он совпадет, если предполагаемое количество изначально неверно), 5) использовать последовательность битов ключа из преобраза для вычисления преобразования адреса в скаляр, 6) вычесть преобраз из одноразового приватного ключа адреса, чтобы получить приватный ключ траты, 7) получить DLP из
    <UkoeHB_> ключа преобраза относительно публичного ключа траты, чтобы получить приватный ключ траты, 8) проверьте, может ли ключ траты сгенерировать ключ просмотра напрямую (обычный адрес) или можно ли использовать индекс субадреса для извлечения ключа трат, который получен из ключа просмотра, 9) повторяете пункты 2-8 до тех пор, пока не получите совпадение (шаг 4а, вероятно, станет самой проблемной точкой с большим количеством неверных данных)
    <sarang> хм
    <Isthmus> оуууу
    <sarang> преобраз keccak равен O(2^100)
    <sarang> но я не уверен
    Isthmus делает заметку
    <Isthmus>
    для сведения — в ZtM2 есть упоминания о типах переменных?
    <UkoeHB_> Это варианты, о которых я уже упоминал в разделе 6.3
    <Isthmus> Отлично. Спасибо!
    <sarang> Хорошо! Предлагаю заканчивать текущую встречу, время подкралось к 18:00 UTC
    <sarang> Спасибо всем за участие!

    Источник: Research meeting: 24 June 2020 @ 17:00 UTC #477

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

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