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

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

  1. Unholy

    Unholy Well-Known Monerano

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

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

    <sarang> Приветствия
    <sarang> hi
    <seddd> o/
    h4sh3d[m] подключился (h4sh3dmatr@gateway/shell/matrix.org/x-mockfssioqoxkmzk)
    <UkoeHB_>
    hi
    sarang ждет несколько минут, возможно, что появиться кто-то ещё
    <SerHack>
    hi
    Young_Padawan[m] подключился (bookerdewi@gateway/shell/matrix.org/x-nvujxgjclwvevcsk)
    ophalia[m] подключился (ophaliahac@gateway/shell/matrix.org/x-jsrntuywsechxoxq)
    <sarang>
    хорошо, дальше у нас КРУГЛЫЙ СТОЛ
    <sarang> кто-то хочет поделиться интересными исследованиями?
    ArticMine подключился (~ArticMine@s207-81-214-17.bc.hsia.telus.net)
    <ArticMine>
    Hi
    <sarang> ну ладно, тогда я сам — думаю, что могу поделиться несколькими вещами
    <sarang> я завершил экспертную оценку всех материалов для IEEE S&B
    <sarang> и работал над анализом для построения связываемой кольцевой подписи в IACR 2020/333
    <sarang> если верить утверждениям, то он более эффективен, чем CLSAG в текущей реализации
    truchaese[m] подключился (truchaesem@gateway/shell/matrix.org/x-fafjhaoviqeruuha)
    <sarang>
    однако текущие цифры подразумевают не совсем безопасную конструкцию для образов ключей
    dl3br[m] подключился (dlebrechtm@gateway/shell/matrix.org/x-punhqwxappcjocvh)
    <sarang>
    авторы уже опубликовали новую ревизию документа, но она не включает новые доказательства безопасности для модифицированных конструкций
    <sarang> помимо всего этого, вот обновленная информация о некоторых других проектах...
    <sarang> что касается CLSAG, то я все еще жду заключительных комментариев от suraeNoether, который является соавтором статьи
    <sarang> еще я закончил оптимизацию кода и сделал PR в ветке moneromooo, которая теперь имеет несколько хороших ускорений проверки
    <sarang> препринт Triptych-1 был заменён на IACR 2020/018
    <sarang> хоть сопоставление MPC для образов ключей и завершено, но анализ multisig / join все еще продолжается
    <sarang> вы можете найти препринт Triptych-2 в архиве IACR 2020/312
    <sarang> но multisig / join анализ ещё продолжается
    ErCiccione[m] подключился (erciccione@gateway/shell/matrix.org/x-newrxenjcjnpvrlo)
    <sarang>
    на этом у меня всё
    * ErCiccione[m] → Guest56370
    <sarang>
    какие-то конкретные вопросы или комментарии по любому из пунктов?
    <nioc> сколько составляет увеличение скорости проверки в CLSAG?
    <seddd> где можно взглянуть на изменения для CLSAG?
    <sarang> порядка 4-5%
    <nioc> отлично!
    <sarang> seddd: мы обязательно поместим ссылку, как только moneromooo интегрирует изменения в основную ветку
    <seddd> отлично, с нетерпением хочу взглянуть
    <sarang> да, конечно
    <moneromooo> я закончил, осталось запушить все изменения
    <sarang> о, даже так! превосходно!
    <ArticMine> 4-5% это уменьшение в размере или времени проверки?
    <sarang> единственное изменение во всей статье - это изменение параметров, которые входят в хэш-функцию вызова
    <sarang> ArticMine: время проверки
    <sarang> я пока не занимался вопросами генерации, поскольку это сейчас менее важно
    <sarang> а размер будет идентичен
    <sarang> PR включает в себя новые тесты производительности и прямое сравнение с MLSAG. Вдруг кому-то это пригодится
    <seddd> moneromooo: ссылка?
    <ArticMine> это окончательная реализация для аудита?
    <moneromooo> пока ещё нет
    <sarang> предположительно, что всё будет зависеть от аудиторской группы
    <moneromooo> Я вначале перенесу его в мастер ветку, потом займусь тестами и только после этого опубликую ссылку
    <sarang> moneromooo: отлично, это правильное построение рабочего процесса
    <seddd> офигенно! большое спасибо
    <sarang> Есть еще вопросы?
    <sarang> кто-то еще хочет поделиться своими исследованиями?
    <seddd> да, но это, скорее, относиться к другой криптовалюте
    <sarang> тогда, возможно, лучше это стоит обсудить после встречи
    <seddd> хорошо, без проблем
    <selsta> кто входит в рабочую группу аудита? sgp?
    <sarang> sgp_ занят координацией
    <sarang> Что касается статьи CLSAG — если я в ближайшее время не получу ответ от suraeNoether, полагаю, что нам нужно будет опубликовать обновленную версию без него
    <sarang> но я бы предпочел не делать этого, как-никак соавтор
    <seddd> разве suraeNoether сегодня не здесь?
    <sarang> он не включил возможность публичного просмотра в текущей версии документа, а у меня, к сожалению, нет соответствующих прав
    <sarang> Нет, его сегодня нет
    <seddd> ладно, понял
    <sarang> из уважения времени полагаю, что мы можем перейти к ключевым моментам
    <UkoeHB_> Моё обновление, корректура ztm v2, продлена до этих выходных, так как комментарии поступают в самый последний момент :p
    <sarang> хорошо, давай, UkoeHB_
    <UkoeHB_> текущая версия здесь - https://www.pdf-archive.com/2020/03/22/zerotomoneromaster-v1-1-2/zerotomoneromaster-v1-1-2.pdf
    <UkoeHB_> это всё
    <sarang> отлично, спасибо
    <sarang> Мои ключевые моменты на предстоящую неделю: завершить корректуру Zero to Monero (это было отложено в дальний ящик; приношу свои извинения)
    <sarang> и работать над MPC математикой в документе Triptych-2
    <sarang> кто-то ещё?
    <hyc> «только для исследований, а не для производственного использования» - sumokoin выпустили inb4
    <UkoeHB_> о, еще я сделал небольшое обновление по смягчению атаки Януса
    <sarang> hyc: ?
    <sgp_> UkoeHB_: что?
    <seddd> lol, hyc
    <hyc> извините, наверстываю упущенное
    <UkoeHB_> https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784
    <seddd> ага, пометка от sumo - "ПЕРВЫЙ"
    <sgp_> UkoeHB_: ничего из этого еще не реализовано, верно?
    <sarang> Не по теме, ребята!
    <UkoeHB_> верно
    <seddd> простите
    ErCiccione подключился (~ErCiccion@gateway/tor-sasl/erciccione)
    <sarang>
    в последний раз меры по смягчению атаки Януса обсуждались на прошлой встрече разработчиков
    <UkoeHB_> мои ключевые моменты сосредоточены на том, чтобы просмотреть обновления по всем последним корректировкам и затем обновить релизную версию
    <UkoeHB_> Cаранг, мне казалось, основная загвоздка заключалась в том, сколько именно публичных ключей и основных ключей потребуется для проведения атаки Януса
    * Guest56370 → ErCiccione[m]1
    DeanGuss вышел (~dean@gateway/tor-sasl/deanguss): Удаленный хост разорвал подключение
    <UkoeHB_>
    полное устранение возможности атаки Януса потребует: 1 базовый ключ Януса для каждой транзакции, где #pub keys = #outputs для ВСЕХ транзакций (и не только транзакций с подадресами, как в настоящее время)
    <sarang> угу
    <seddd> это подразумевает много дополнительных расходов… Это одно из главных противоречий?
    DeanGuss подключился (~dean@gateway/tor-sasl/deanguss)
    <UkoeHB_>
    возможно и частичное смягчение атаки Януса, где обычные адреса и подадреса разделены; другими словами, не стоит упрощать связывание обычных адресов с подадресами
    <UkoeHB_> однако даже при частичном уменьшении пула подадресов, ваша транзакция, скорее всего, будет обнаружена как отправленная с подадреса, поскольку в настоящее время существует оптимизация, которая скрывает транзакции только с основного адреса
    <UkoeHB_> в то время как при полной миграции стандартный адрес транзакции и подадрес будут неразличимы
    <UkoeHB_> все в точности, как говорил Саранг
    <seddd> +1
    <sarang> Да, «принуждение» к неразличимости и повышению анонимности всегда полезно
    <UkoeHB_> главная цель – понять возможность проведения атаки Януса
    <UkoeHB_> которая в данный момент не может быть обнаружена своевременно
    <sarang> да
    <seddd> каковы противоположные аргументы?
    <sarang> повышение размера транзакций
    <sarang> это главный контраргумент
    <sarang> (в прямом смысле)
    <seddd> :)
    <sarang> как и всегда, компромисс между сложностью (в данном случае размером и изменениями протокола) и неразличимостью
    <sarang> стоит отметить, что размер CLSAG снизился с ~2,5 кБ до ~1,9 кБ
    <sarang> так что у нас есть свободное место для потенциального механизма противодействия
    <seddd> существуют ли альтернативные смягчения атаки Януса?
    <sarang> каждый скалярный / групповой элемент добавляет 32 байта
    <UkoeHB_> это единственный вариант
    <ArticMine> насколько увеличится размер транзакций?
    <UkoeHB_> в среднем на 2,2*32 байта за транзакцию
    ErCiccione вышел (~ErCiccion@gateway/tor-sasl/erciccione): Причина: Вышел
    <UkoeHB_>
    при условии, что 2.2 - это среднее значение
    <UkoeHB_> стоп, нет, вот так будет правильно 32 + 1.2*32
    <UkoeHB_> или как-то так, LOL
    <seddd> как насчет добавления дополнительной базовой точки в таблицы поиска, где точка индексируются первыми 8 байтами
    <UkoeHB_> на самом деле чуть-чуть меньше, учитывая текущую специфику подадресов
    <ArticMine> Таким образом, порядка 64 байта
    <UkoeHB_> да, как-то так
    <ArticMine> если проблема для безопасности подтверждена, я не вижу другого решения как увеличение размера
    <UkoeHB_> seddd, базовый ключ должен быть сгенерирован авторами транзакций
    <UkoeHB_> в рамках текущей конструкции не уверен, есть ли другие способы реализовать это
    <sarang> ArticMine: в рамках погрешности
    <seddd> понял, спасибо
    <seddd> нужно будет перечитать документ
    <sarang> возможно, что пришло то время, когда нужно это снова обсудить
    <UkoeHB_> seddd, да, я еще думаю, как можно симулировать её без наличия оригинального ключа
    <sarang> у кого-то еще есть ключевые моменты на предстоящую неделю?
    <seddd> UkoeHB_, это то, о чем я подумал в первую очередь
    <seddd> буду рад сотрудничать с вами, это интересная проблема
    <sarang> конечно
    <sarang> Хорошо, давайте подведём итоги этой встречи; обсуждения может продолжаться после окончания официальной части
    <sarang> заключительные темы, представляющие общий интерес в рамках этой встречи?
    <sarang> мы заканчиваем!
    <sarang> спасибо всем за участие!

    Источник: Research meeting: 25 March 2020 @ 17:00 UTC #448

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

    Kukima (@Kukima)
     
    #1 Unholy, 27 мар 2020
    Последнее редактирование модератором: 29 мар 2020
  • О нас

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