Когда: Вторник, 12 ноября 2019 года, 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты <sarang> Всем привет <sarang> да начнётся встреча! <sgp_> привет <sarang> во-первых, ПРИВЕТСТВИЯ <sgp_> черт, я тебя опередил <sarang> следом КРУГЛЫЙ СТОЛ <suraeNoether> howdy <suraeNoether> Саранг, будете первым? <sarang> Я перенес исправление эксплойта RCT3 из агрегированной системы проверки с несколькими входами в систему проверки с одним входом, обновил код, чтобы отразить изменения, и проверил соответствующие доказательства безопасности для этой конструкции <sarang> также я изучил некоторые способы поддержки мультисигнатур в рассматриваемых сублинейных протоколах, к сожалению, это не принесло видимых результатов <sarang> на данный момент все конструкции RCT3, Omniring и Triptych требуют инверсии секретного ключа, что несовместимо с методом линейной комбинации, используемым для обработки мультисигнатур <sarang> данный метод можно использовать только в ключе RCT3 и Triptych на этапе генерации образа ключа, но на данном этапе это всё еще не работает так, как должно работать <suraeNoether> я читал о каких-то схемах подписи, которые не используют хеш-функции, а прибегают к инверсии ключа... когда позже я рассмотрю ваши материалы о triptych, я перепроверю, есть ли что-то, что ускользает от вашего чуткого глаза <sarang> Спасибо <suraeNoether> я бы предположил, что это что-то не очевидно, потому что вы и randomrun очень внимательны в этих моментах <sarang> Несколько вещей всё еще в стадии разработки <sarang> независимо от мультиподписей я работаю над препринтом Triptych для библиотеки IACR <sarang> Это будет доказуемо-безопасная версия с одним подписантом или версия с несколькими подписантами, если сработает аргумент обоснованности <sarang> Он будет включать в себя ту же конструкцию образов ключей, которая находится в основе PRF, RCT3 и Omniring, поскольку она намного эффективнее, чем схема, основанная на хешировании публичных ключей. <sarang> Теперь я передаю эстафету вам, Шурэ <suraeNoether> круто, я сейчас собираю данные для нашего анализа прослеживаемости. Я представил предварительные результаты вчерашнего *одиночного* моделирования, которые обещают быть довольно многообещающими, но пока их не получится обобщить <sarang> Код с вашими правками и результатами уже в вашем репозитории? <suraeNoether> всё, что вам нужно будет сделать, это запустить playerchallenger.py с python3, и вы увидите результаты симуляции <sarang> Вы можете указать ветку и сам коммит, чтобы быть уверенным, что мы выполняем один и тот же код? <suraeNoether> Конечно, результаты будут отличаться от моделирования к моделированию, поэтому точные цифры, которые я предоставил вчера, будут также меняться <sarang> верно <suraeNoether> https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching – вот эта <sarang> Поймал, спасибо! <suraeNoether> во многих отношениях код еще не завершен (всегда есть способы сделать выбранную Евой схему взвешивания лучше или учитывать больше данных), но этого достаточно, чтобы начать сам анализ данных и уже сейчас получить числа для вспенивания <sgp_> Как мне его настроить для тестирования с различными параметрами вспенивания? <suraeNoether> в настоящее время я всё еще вношу изменения в код, чтобы специально исследовать вспенивание, и это потребует некоторых изменений в самой симуляции, не думаю, что закончу это сегодня <suraeNoether> ^ хех <sgp_> хорошо, я подожду <sarang> Я вижу коммит d5076 как самый последний <suraeNoether> да-да, именно он, d5076 <sarang> понял, спасибо <suraeNoether> я думаю, что у документа MRL в ключе вспенивания будут *положительные* данные <suraeNoether> кроме этого, я пытаюсь нагнать RCT, omni и triptych документы, с которыми уже разобрался Саранг <suraeNoether> это все, что у меня есть для вас. О, это же и есть мой отчет о проделанной работе <scoobybejesus> *скрестил пальцы* а что насчёт моего вопроса <scoobybejesus> sarang> данный метод можно использовать только в ключе RCT3 и Triptych на этапе генерации образа ключа <<< Можно ли сделать, чтобы логика работала так, что подписание транзакции по-прежнему происходило с помощью линейной комбинации, но образ ключа был получен сразу несколькими участниками? <sarang> Нам нужен безопасный MPC для функции J(x) = (1/x)*U <sarang> если всё будет именно так, это будет лучше для каждой стороны <sarang> (где U - фиксированный генератор групп с кривой) <sarang> я пытаюсь найти документ, в котором этот конкретный PRF был впервые представлен <sarang> Цитата из документа Omniring (ссылка 20): https://www.iacr.org/cryptodb/archive/2005/PKC/3320/3320.pdf <sarang> у кого-нибудь еще есть работа, чтобы поделиться ею или просто обсудить её? <sarang> кроме того, меня одновременно и раздражает и восхищает эта конкретная псевдослучайная функция <suraeNoether> Просто вычисли логарифм и добавь <sarang> Но на самом деле MPC для этой функции, основанной на линейных комбинациях, решит эту проблему <sarang> но это может и не сработать при сохранении хороших свойств PRF <sarang> (есть весомый аргумент, что такой MPC попросту не может существовать) <suraeNoether> если серьезно, почему бы не вычислить обратный результат произведения закрытых ключей и вместо частичной суммы на базовой точке, передаваемой вокруг, использовать произведение на этой самой базовой точке <suraeNoether> Если у меня есть x, а у вас y, пусть комбинированный ключ будет 1/(xy) U <sarang> только если вы уберете аффинное пространство составного ключа, я не знаю другого способа заставить всё это работать с остальной частью доказательства <sarang> и при этом я не понимаю, какие данные образа ключа будут переданы для создания целого образа <suraeNoether> Я отправляю вам (1/x)U. Вы умножаете на 1/y... <suraeNoether> Так что вам нужен не просто MPC, а линейная функция ввода ключа... <sarang> Возможно. Я думал в контексте комбинации линейных ключей изначально (так как остальные доказательства хорошо сочетаются с ними) <sarang> поэтому multisig работает так хорошо, потому что в нём всё хорошо сочетается с линейными комбинациями <sarang> что если бы можно было ослабить это ограничение <sarang> единственный момент в Triptych и RCT3, который требует использования закрытого ключа (без учета построения образа ключа) - это самый конец доказательства для построения замаскированного скаляра <suraeNoether> Хмммм <suraeNoether> Хорошо, я займусь дальнейшим чтением документа triptych и постараюсь слить мои изменения в репозиторий, чтобы продолжить эксперименты со вспениванием для sgp_ <sarang> Правильно <sarang> Дайте мне знать, если у вас появятся какие-то дополнительные мысли в ключе multisig / MPC конструкций <sarang> О! Вот документ, который вышел совсем недавно. В нем описывается создание составных доказательств zk в библиотеке Python: https://arxiv.org/abs/1911.02459 <sgp_> Спасибо, suraeNoether! Я заинтересован в тестировании вашей модели <sarang> Ну так что? Перейдём к КЛЮЧЕВЫМ МОМЕНТАМ? <sarang> Моя основная задача заключается в том, чтобы внести ясность в формализацию препринта Triptych и еще рассмотреть возможные варианты безопасности MPC <sarang> а затем я хочу сделать анализ работы suraeNoether над его кодом моделирования <sarang> (и наверстать отставание по документам) <suraeNoether> Мне же предстоит прокомментировать и задокументировать ту часть, в которой описывается, как всё это работает, для всех тех, кто хочет что-то понять и разобраться в этом <suraeNoether> кроме этого, я буду много читать и планирую доделать свои рабочие отчеты Источник: Research meeting: 12 November 2019 @ 17:00 UTC #409 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
