Когда: Среда, 25 марта 2020 г., 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <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, продлена до этих выходных, так как комментарии поступают в самый последний момент <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)
