Когда: Среда, 17 июня 2020 года @ 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Примечание в теме от Mitchellpkt (Isthmus) Журнал встречи: <sarang> Начнем с ПРИВЕТСТВИЙ <sarang> Привет! <h4sh3d[m]> Hi <Isthmus_> Приветствую_ <sgp_> Привет <ArticMine> Hi <sarang> Отлично, дальше мы направляемся к нашему КРУГЛОМУ СТОЛУ, где каждый желающий может поделиться своими интересными исследованиями <sarang> Isthmus_, я заметил, что вы только что добавили текст в повестку дня, хотите выступить первым? <sarang> Если в данный момент вы, Isthmus_, не готовы, я могу поделиться своим обновлением <Isthmus_> Ох, дайте мне 5 минут <Isthmus_> я не успел подготовиться <sarang> Я сделал дополнительный анализ в ключе отслеживания транзакций <sarang> Сейчас я опубликую несколько интересных моментов... одну секунду... <sarang> Все транзакции отсортированы по дате и типу: https://usercontent.irccloud-cdn.com/file/Pqx68K2E/all.png <sgp_> Мне нравится ваша классификация типов - скрытый, переходный, деноминированный... <sarang> Те же данные, но уже масштабированные: https://usercontent.irccloud-cdn.com/file/Cm4J3FRc/all-scaled.png <sarang> Удобочитаемые данные о транзакциях по дате и типу (в том же масштабе, что и первый график): https://usercontent.irccloud-cdn.com/file/rcPhKQZ4/deducible.png <sarang> Обратите внимание, что эти "удобочитаемые" данные должны включать по крайней мере вход для возможности анализа <sarang> Из всех транзакций я выбирал распределение по возрасту трат и только затем классифицировал их по выходам из монетной базы <sgp_> "должны включать по крайней мере один вход" <sarang> График CDF для такого распределения: https://usercontent.irccloud-cdn.com/file/teVxZrIe/cdf.png <sarang> sgp_, да, спасибо за исправление <sarang> График CDF также включает в себя гамма-распределение, используемое для выбора выходных данных, которое было впервые затронуто в исследовательском документе Миллера и компании <sgp_> угу, для транзакций с несколькими входными кольцами (очевидно, что вы, Саранг, знаете об этом) <sarang> Что примечательно, так это то, что выходы из монетной базы имеют практически одинаковое распределение по возрасту в сравнении с выходами не из монетной базы <sarang> Раньше мы не знали, как и чем они будут отличаться друг от друга <sarang> Мой "отказ от ответственности" заключается в том, что транзакции скрытого типа подлежат вычету <sarang> Зато мы учитываем все транзакции не скрытого типа, которые можно использовать в качестве прямого набора данных для ground-truth систем <sarang> И это очень хорошая новость! <sarang> Доля всех транзакций (без учета кумулятивных), которые имеют хотя бы один исключительный выход: https://usercontent.irccloud-cdn.com/file/jiDfKje2/proportion.png <sgp_> Я удивлен, что распределение настолько похоже <sarang> Вот вам еще одна догадка о том, когда произошло переключение на CT... <sgp_> lol <sarang> UkoeHB_, перед началом встречи вы спросили меня, как распределение меняется с изменением периода набора данных, так вот, сегодня вечером я планирую добавить возможность выбора периода <sarang> Как минимум это полезная информация, которая показывает, что распределение из анализа Миллера имеет обоснованные результаты, а также предполагает, что выходы из монетной базы не требуют особого подхода с точки зрения возрастных трат <sarang> стоит отметить, что это не единственный фактор отбора <sarang> просто это единственный фактор, по которому у нас раньше не было данных <sgp_> теперь у меня есть четкое понимание того, что мы должны разделить различные типы колец и впредь не должны слепо полагаться на выборку самого алгоритма <sarang> В ближайшее время я обновлю свою инструкцию о том, как самостоятельно получить все эти данные <sgp_> Очевидно, что данные из BTC нужно обновить, за это время появились более актуальные данные <sarang> Также я планирую добавить поддержку инкрементных обновлений, чтобы у всех желающих была возможность строить аналогичные графики <sarang> не стесняйтесь самостоятельно перепроверять все эти сценарии и данные после их публикации, мои данные, как и все другие, могут быть ошибочными <sgp_> как и временные данные, представленные UkoeHB_, особенно если такие выходные данные тратятся после своего первого появления в монетной базе <sarang> К сожалению, у меня нет правильных настроек для запуска этого теста в BTC <sarang> но есть временные данные для Monero <sarang> которые и потребуются для запуска теста <sgp_> по какой схеме вы строите графики на основе времени? Какое среднее количество блоков после генерации выхода из монетной базы до момента ее траты? <sarang> позже я представлю несколько таких временных окон <sarang> и использую в качестве визуализации транзакции с тратами <sarang> так как возраст всегда соотносится с транзакцией траты <sarang> что позволяет всё упростить <sgp_> окей, я обязательно дам вам знать, если у меня возникнут проблемы или потребуется помощь <sarang> Помимо этого, сейчас всё еще продолжается проверка CLSAG командой JP Aumasson совместно с их коллегой, Энтони Веннардом <sarang> Пожалуй, это всё, чем я хотел бы поделиться с вами, у вас есть какие-то вопросы? В противном случае, я передам слово Isthmus_ и другим участникам <sarang> Isthmus_: теперь-то вы готовы? <Isthmus_> Конечно! <sarang> Тогда вперёд! <Isthmus_> Вот наш первый концепт для структуры предстоящего аудита постквантовой модели безопасности. Ваши мысли о предложенных механизмах и алгоритмах? <Isthmus_> https://usercontent.irccloud-cdn.com/file/mRxqUX65/image.png <sarang> Это то же самое изображение, что и в повестке дня? <sarang> Как вы определяете типы проблем? <Isthmus_> Получилось как-то так: <Isthmus_> Потенциальный злоумышленник: {алгоритм Шора, алгоритм Гровера, Ловушка / проверка Фурье, алгоритм Саймона, алгоритм Дойча–Йозса, алгоритм Бернштейна-Вазирани (проблема со скрытой линейной функцией), потенциальные уязвимости для новых методов, используемых квантовым компьютером, но не имеющих какого-либо известного алгоритма на данный момент} <Isthmus_> Вектор атаки: {Кольцевые подписи, RingCT, одноразовые "скрытые" адреса, публичный ключ деривации, чеканные суммы?, Bulletproofs, доказательство работы RandomX, хеширование блока / транзакций, PRNG, изменение в схеме Фиата - Шамира, Подпись Шнорра, ??} <Isthmus_> что мы упустили? → Dean_Guss подключился (~dean@gateway/tor-sasl/deanguss) ⇐ DeanWeen вышел (~dean@gateway/tor-sasl/deanguss): Удаленный хост закрыл подключение <sarang> Попадает ли конфиденциальность обязательств по сумме в пункт RingCT?? <sarang> "RingCT" можно весьма гибко и широко интерпретировать <sarang> как и обратное <Isthmus_> Да, мы можем попытаться это разграничить <Isthmus_> итак, вопросы по существу: 1) подделка 2) разоблачающие суммы <sarang> Возможно, стоит еще добавить идентификаторы платежей <Isthmus_> точно! <sarang> Еще такой момент: как вы определяете типы "проблем" на графике? <moneromooo> keccak, (конкретно наш случай) chacha20 <Isthmus_> О, "проблемы" - это наши исследовательские заметки друг для другу. Назовём это неформальной частью таблицы — Isthmus_ называет это просто заметками <sarang> Isthmus_: тогда что с заметкой mooo... вы планируете учитывать только основную цепочку или будете рассматривать и ответвления по типу локальных векторов? <sarang> в качестве примера: выходит ли шифрование локального кошелька за рамки исследования? <moneromooo> @sarang, возможно, вам есть что добавить? Какой-то новый криптографичиский примитив из triptych? <sarang> Ну, я был бы не против дополнительного анализа доказательств Triptych <sarang> так как в своём большинстве они основаны на DL <gingeropolous> ^^ <sarang> DL это тот еще тост :/ <Isthmus_> хм, я планировал затронуть только основную цепочку, без локальных и узконаправленных векторов <sarang> Думаю, что большинство вещей зависит именно от модели угрозы <Isthmus_> Мой первостепенный приоритет - это векторы атак, которые позволяют провести ретроактивную деанонимизацию <Isthmus_> что в первую очередь отразиться на основной цепочке <sarang> Ну да, если кто-то сядет за ваш компьютер, у вас прибавится головной боли <Isthmus_> Если у вас есть идеи или методы какой-либо проверки локальных механизмов безопасности (например, локальное шифрование), не стесняйтесь, просто отпишитесь мне, и я добавлю их в список <h4sh3d[m]> публичный ключ используется в других функциях / механизмах в качестве примитива, или это больше похоже на случай, как с учетной записью и подадресом? <Isthmus_> похоже, что самая большая проблема заключается в том, что злоумышленник, использующий алгоритм Шора, может подобрать ваши закрытые ключи на основе открытого ключа. Это означает, что если вы дадите кому-то свой публичный адрес, он может создать аналогичный адрес с вашим закрытым ключом и просканировать всю историю транзакций вашей учетной записи <sarang> Да, мне тоже интересно это узнать <UkoeHB_> звучит, как что-то похожее на алгоритм Диффи-Хеллмана <moneromooo> схема зашифрованных данных получателя из ветки rpd использует chacha20 <sarang> <moneromooo> как-то так… но для этого требуются только локальные методы <sarang> превосходно <monerobux> Саранг хотел сказать: превосходно <sarang> хороший бот <sarang> Я с нетерпением жду результатов этого анализа <Isthmus_> Публичный ключ служит затравкой к закрытому ключу в алгоритме Шора <Isthmus_> Также будут рассмотрены подадреса и т. д. <sarang> Isthmus_: знаете ли вы другие проекты, занимающиеся подобной работой? так, просто любопытно <sarang> У меня почему-то есть подозрение, что заголовки будут следующего содержания — "у Monero отсутствует квантовые методы защиты! Бегите, глупцы!", ну или как-то так <sarang> Но в любом случае видеть полную картину относительно текущего протокола и его возможности противостоять квантовым злоумышленникам - захватывающая идея <Isthmus_> ахахах, мы обязательно добавим комментарии по типу "это также относится к Bitcoin, Zcash и всем остальным криптовалютам в вашем портфеле" <Isthmus_> еще один вопрос, который беспокоит меня - настолько безопасны скрытые адреса... Если будет способ через скрытые адреса получить доступ к приватным ключам… считайте, что все мы прожаренные тосты... <Isthmus_> но, в отличие от вас, тост не может потерять свой баланс кошелька <sarang> Isthmus_: возможно вам требуется какая-то помощь в ключе вашей работы и исследований? <Isthmus_> Можно мне задать один глупый вопрос? <sarang> Да, конечно <Isthmus_> Если я отправлю вам, Саранг, транзакцию, а затем уничтожу свой компьютер и потом восстановлю кошелёк из мнемонической фразы, смогу ли я восстановить и ваш адрес из транзакции в этой цепочке? <sarang> Нет, это уже внешняя информация <isthmus_> ФУХ! <Isthmus_> Ладно, иначе все это было бы страшно рекурсивным <sarang> У меня периодически возникали идеи попробовать зашифровать эту информацию <sarang> но вы и сами можете это сделать <Isthmus_> Да, модель безопасности в этой схеме далека от совершенства. Если я получу pubkeyA, то у меня также будет информация о privkeyA <sarang> Скорее <sarang> это компромисс в дизайне, чем потенциальная уязвимость <Isthmus_> Круто, спасибо! На этом у меня сегодня всё <sarang> Спасибо, Isthmus_! <sarang> С нетерпением ждем будущих обновлений <sarang> У вас есть какие-то вопросы или замечания для Isthmus_? <tevador> Я думаю, что *общий* результат исследования будет сведён к тому, что квантовый злоумышленник сможет украсть все ваши деньги, но так и не сможет связать платежи, особенно если ему неизвестны адреса <luigi1111w> "конфиденциальность" при использовании скрытых адресов не должна рассматривается как приоритет атаки квантового злоумышленника, есть другие гораздо более критически уязвимые моменты <sarang> и еще мне интересно увидеть, как результаты этого проекта будут соотноситься с потенциальными рисками других протоколов <Isthmus_> Да, это исследование должно помочь трезво оценить ситуацию <luigi1111w> вы не можете связать данные в блокчейне с неизвестным вам адресом, но вы можете связать данные для уже известных вам адресов <sarang> Что бы понять, работает ли протокол Monero лучше, примерно также или вообще хуже, чем протоколы в аналогичных криптовалютах <sarang> luigi1111w: Zcash пришли к аналогичным выводам <sarang> (в качестве сравнения) <Isthmus_> "но вы можете связать данные для уже известных вам адресов" < не могли бы вы уточнить? <luigi1111w> учитывая конкретный адрес, вы можете определить, соответствует ли он определенному выходу <luigi1111w> но вы не можете получить сам адрес из выхода <Isthmus_> О как, понял <Isthmus_> Еще такой момент, когда вы говорите "соответствует ли он определенному выходу", вы имеете в виду только что созданный выход или уже имеющийся? <luigi1111w> уже имеющийся <luigi1111w> в таком случае вся конфиденциальность ставится под угрозу <Isthmus_> Да, это имеет смысл и соответствует плану нашего исследования <sarang> Хорошо, кто-нибудь еще хочет поделиться исследованиями, представляющими общий интерес для этой группы? <h4sh3d[m]> Вчера я опубликовал обновленную версию документа свопа <h4sh3d[m]> https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/dl-proof/whitepaper/xmr-btc.pdf <sarang> Отлично! <sarang> Есть что-нибудь конкретное, чтобы вы хотели прокомментировать или отметить? <h4sh3d[m]> Я исправил одноразовое использование VES, и теперь оно отрабатывает правильно <sarang> принято к сведению <sarang> h4sh3d[m], спасибо <h4sh3d[m]> В ближайшее время я внесу еще немного правок в сам документ, но сама концепция протокола не претерпит изменений <sarang> Перед тем как двигаться дальше, есть ли еще какие-либо вопросы или темы исследований, на которые следует обратить внимание? <sarang> (у кого-либо ) <sarang> OKей, тогда переходим к КЛЮЧЕВЫМ МОМЕНТАМ <sarang> Я планирую обновить и опубликовать свой набор инструментов для анализа, а также доработать данные о распределении затрат по возрасту и уже затем разместить их в этом канале. <sarang> Еще продолжить работу с аудиторской командой в ключе документа CLSAG <sarang> На данный момент я отложил в сторону дизайн алгоритма слияния и вернусь к нему немного позже <sarang> Кто-то еще хочет поделиться своими ключевыми моментами на предстоящую неделю? <sgp_> Я хотел бы услышать ваше мнение о том, что мы пришли к консенсусу в отношении распределения выходов колец из монетной базы для предстоящего обновления CLSAG <sarang> Какие именно данные вы планируете использовать для проведения этой оценки? <sgp_> я поддерживаю эту идею в текущем виде, без реализации дополнительного пространства для выходов не из монетной базы <sarang> Отлично, сделаю себе отметку <sarang> Есть ли какие-то конкретные данные (которых у нас в данный момент нет), на основе которых мы могли бы провести дополнительную оценку? <sgp_> Я рассматриваю это как постепенное улучшение. Постепенно мы сможем приспособиться к этому алгоритму выбора данных <sarang> Как мы теперь знаем, такой алгоритм не будет нуждаться в отдельном учете временных трат <sgp_> это сделает реализацию еще проще <sarang> Ладно, наше время подходит к концу <sarang> Есть ли еще какие-нибудь вопросы или комментарии перед тем, как мы закончим? <Isthmus_> У меня где-то был алгоритм для выбора наименьшей возрастной группы, который должен вам помочь <Isthmus_> но в него потребуется перенести запрос на выборку данных <sarang> Isthmus_, что вы имеете в виду? <Isthmus_> Каждый выход в Monero уже и так имеет минимально допустимый возраст. Это отчетливо видно, если смотреть на дерево транзакций из монетной базы <Isthmus_> Я могу указать на любой выход и сказать, что он не моложе N шагов из распределения монетной базы <sarang> О, понял <Isthmus_> Блин, я опаздываю на другую встречу <Isthmus_> g2g — Isthmus_ удаляется в другую конференц-комнату Zoom <sarang> Было бы интересно увидеть, что же вы там такое придумали <sarang> Хорошо, полагаю, мы можем закончить <sarang> Спасибо всем за участие! Источник: Research meeting: 17 June 2020 @ 17:00 UTC #474 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
