Вообще, если трактовать 37% и 50% обычным образом, то написано в исходном сообщении от Google вот что: разработчики вынуждены отбрасывать 63% предложений ИИ, выводимых в автокомплит, и поэтому половину добавляемых символов программы всё ещё набирают вручную, вопреки подсказкам ИИ. И ничего не сказано "в долях" про то, насколько автокомплит сбивает с толку, как потом код удаляется и переписывается, и т.д., и т.п.
Главное - какой вообще смысл в оценке качества разработки программного кода по количествусимволов?
(Там ещё и какая-то странная то ли опечатка, то ли шутка: в параграфе про "resolving code review comments" написано, что "более восьми процентов" (">8%") выполняется с использованием ИИ; но более восьми процентов - это и 100%.)
получить непротиворечивую неевклидову геометрию, в которой параллельные прямые пересекаются или расходятся.
Вроде, должно быть очевидно, что параллельные прямые не пересекаются - по их определению.
Что касается «Лобачевский доказал» и «пересекаются», которое много лет кочует по публикациям: тут забавно, что в геометри Лобачевского, как раз, всё равно наоборот. Там параллельные прямые, в некотором роде, о-го-го как «сильнее» не пересекаются, чем в евклидовой. Потому что смысл соответствующего постулата гиперболической геометрии (Лобачевского) такой: «через точку, не лежащую на данной прямой, в плоскости, которая задаётся этой прямой и точкой, можно провести более одной прямой, не пересекающей данную». У Евклида – не более одной прямой: почувствуйте, как говорится, огромную разницу - это постулаты не «про пересечение», а про количество, про подсчёт.
В версии «от Лобачевского», во-первых, можно бесконечно много построить прямых, проходящих через указанную точку и «параллельных» данной (в смысле классической евклидовой системы, поэтому - в кавычках); во-вторых, в процессе построения, возникают как бы две «параллельности»: появляются граничные прямые, которые параллельны данной «влево» и параллельны «вправо» (да, именно так). Все прочие параллельные формируют пучок внутри углов, образуемых двумя граничными прямыми. Получается сильнее евклидового варианта. И именно эти две граничные прямые, дающие углы параллельности, определяются как параллельные в данной геометрии. Свойства параллельности в геометрии Лобачевского имеют богатую интерпретацию, но, главное, в геометрическом смысле, даже две прямых, проходящих через точку и не пересекающих данную, это, вообще говоря, несравнимо больше, чем одна прямая у Евклида.
Это, скорее всего, из-за неполных шрифтов. Нередкая ситуация, к сожалению - далеко не все блоки Unicode есть в доступных шрифтах. Я поэтому специально обернул все шумерские цифры статьи в LaTeX-выражения, как формулы, чтобы они рендерились отдельно в SVG. Видимо, это не очень-то помогло.
Вряд ли. Q - это точка на кривой, то есть, пара значений. Даже для того, чтобы говорить о битовой разрядности, нужно было бы ввести какие-то высоты и пр. - довольно технический момент. Но ничего про это не сказано, да и смысла нет в таком действии: оно полезно для вычисления дискретного логарифма, но тут-то сразу логарифм известен, по условию.
Чтобы по утекшей информации о внутреннем состоянии на каком-то шаге было вычислительно сложно восстановить предыдущую выдачу. Это, собственно, одно из базовых требований к криптографически стойким генераторам псевдослучайных чисел - поэтому я его упомянул, так сказать, автоматически. Непосредственно на описанный в статье бэкдор - (не)обратимость φ не влияет, это верно, но расширяет возможности: если φ обратима, то через бэкдор можно получить ещё и предыдущие состояния.
Уточнение: в описанном в статье случае, и ξ, и φ - однонаправленные, если не учитывать значение секрета. Бэкдор позволяет получить внутреннее состояние на следующем шаге - как раз потому, что атакующему известен секрет.
Всё ж, не "двойные эллиптические кривые" - а "удвоенный/двойной генератор (RNG) на эллиптической кривой". Кривая там одна, точек-генераторов - используется две.
Поэтому для нашего proof of concept нужно использовать малое значение Q, которое легко атаковать
Тут, видимо, какая-то опечатка. Что такое "малое значение", применительно к точке кривой? Непонятно, как сравнивать точки (это большая проблема). В упомянутом бэкдоре, если задана точка P, то можно использовать всякую другую точку Q кривой, если вычислить подходящий под P скаляр. Что, собственно, и делается дальше. Другими словами: так как дальше параметры с бэкдором задаются прямо, то никакое требование "малости" тут не нужно.
Вообще, математический смысл данной атаки в том, что владельцу ключа от бэкдора известно соотношение между точками P и Q. То есть, известно такое δ, что δ*P = Q. Это, фактически, шаг протокола Диффи-Хеллмана на эллиптической кривой: P - генератор, δ - секретный ключ, Q - открытый. Зная Q и P вычислительно сложно найти δ (в чистом виде задача "дискретного логарифмирования"). В этом и смысл - для успешной атаки нужно знать секретный ключ, этим ключом "заперт" бэкдор, поэтому не каждая сторона может им воспользоваться. Зная связь между P и Q - можно по выдаче генератора определить его внутреннее состояние (s), перебрав совсем небольшое количество значений.
Не совсем понятно, почему "квантовых вычислений", если, судя по описанию, это эмулятор некоторых моделей квантовой механики или эмулятор квантовых алгоритмов. (То есть, вычисления там явно классические.)
Это да. Так-то тут вообще можно заморочиться и, если случай достаточно редкий, доставать из дампа памяти VM непосредственно сеансовые ключи, чтобы раскрывать трафик полностью пассивно, без терминирования - тогда уже никакое сравнение ключей не поможет в принципе. Я вот более подробно про это писал, как раз на примере истории с jabber.ru: https://dxdt.ru/2023/11/04/11418/
Выше я напсиал и выделил как правило -- "В случае DNS валидации (с доп проверкой CAA), его (сервер) как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google".
А тот регистратор и всякие облака - они где держат авторитативные серверы? Ну, хорошо, назовём сервер не VPS, а VM (непосредственно на железе сейчас мало кто держит такое) - сетевая ситуация-то не меняется.
Перехватить трафик УЦ на несколько порядков сложнее операционно и техничесски (если вообще возможно) чем у конкретной VPS.
Это миф. Нет там какой-то особой защиты. Тем более, если это запросы к DNS. Ну вот работает в конкретной VPS авторитативный сервер DNS - предположим, BIND, или специальный сервер, не важно. Вот приходит к VPS пакет от резолвера УЦ. Это, с сетевой точки зрения, такой же пакет, такой же трафик, как и HTTP не "от УЦ" - у него только номер порта отличается, и, предположим, в HTTP был TCP, а здесь - UDP. Никаких особых методов защиты к "трафику УЦ" не применяется.
Этот выбор, как раз, очень логичный: для заворачивания/перехвата трафика есть налаженная и универсальная система, а перехват привязан к не менее универсальному протоколу, не зависит от ПО на сервере.
Чтобы разместить CNAME в зоне - тоже нужен доступ. Да, понятно, что после публикации CNAME - "чужие админы" (читай - чужой скрипт с рутовыми правами) могут редактировать только другую зону, соответствующую CNAME. Это безопаснее с точки зрения управления основной зоной в целом. Однако именно редактирование второй, - CNAME, - зоны как раз позволяет проходить проверку и выпускать сертификаты.
При этом настройка CNAME на стороне администратора зоны часто приводит к ошибкам, потому что это самая неочевидная запись DNS. А на стороне системы проверки доменов УЦ - тоже возникает большой риск ошибок, так как CNAME значительно сложнее обрабатывать резолверу.
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ.
Нет. Достаточно перехватить на этапе обращения к авторитативному серверу. Пункт 3 в вашем списке - "[DNS resolvers] -> [ Authorative DNS ]". Авторитативных серверов может быть несколько, но не факт, что УЦ и опрашивает несколько, сравнивая ответы. Как я и написал выше, если нет DNSSEC, то здесь полностью аналогичная HTTP схема: HTTP-узлов так же может быть несколько, они могут быть "в AWS", "в облаке" и т.д.
(Отмечу ещё раз, что, конечно, проверка через DNS, в целом, это существенно более надёжный вариант. Но для стороны УЦ, а не с точки зрения перехвата на уровне провайдера.)
Фактически он предлагает параллельно строить ещё одну сеть доверия
Так DNS уже построена. DANE - базируется на DNS. DANE вообще весьма хорошая, архитектурно, технология. Такое редко встречается в этих интернетах.
причём на базе технологии которая для этого изначально не была предназначена.
DNS - это распределённая БД, хранить там, вообще говоря, позволяется что угодно. Есть SSHFP и пр., скажем. Относительно новая часть, необходимая для DANE - DNSSEC - это да, это такая хрупкая пристройка-надстройка. Но, всё ж, она и предложена-то, буквально, для того, чтобы удостоверять значение записей. Другое дело, что с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень.
Вообще, если трактовать 37% и 50% обычным образом, то написано в исходном сообщении от Google вот что: разработчики вынуждены отбрасывать 63% предложений ИИ, выводимых в автокомплит, и поэтому половину добавляемых символов программы всё ещё набирают вручную, вопреки подсказкам ИИ. И ничего не сказано "в долях" про то, насколько автокомплит сбивает с толку, как потом код удаляется и переписывается, и т.д., и т.п.
Главное - какой вообще смысл в оценке качества разработки программного кода по количеству символов?
(Там ещё и какая-то странная то ли опечатка, то ли шутка: в параграфе про "resolving code review comments" написано, что "более восьми процентов" (">8%") выполняется с использованием ИИ; но более восьми процентов - это и 100%.)
1001 -- составное число:
.
Вроде, должно быть очевидно, что параллельные прямые не пересекаются - по их определению.
Что касается «Лобачевский доказал» и «пересекаются», которое много лет кочует по публикациям: тут забавно, что в геометри Лобачевского, как раз, всё равно наоборот. Там параллельные прямые, в некотором роде, о-го-го как «сильнее» не пересекаются, чем в евклидовой. Потому что смысл соответствующего постулата гиперболической геометрии (Лобачевского) такой: «через точку, не лежащую на данной прямой, в плоскости, которая задаётся этой прямой и точкой, можно провести более одной прямой, не пересекающей данную». У Евклида – не более одной прямой: почувствуйте, как говорится, огромную разницу - это постулаты не «про пересечение», а про количество, про подсчёт.
В версии «от Лобачевского», во-первых, можно бесконечно много построить прямых, проходящих через указанную точку и «параллельных» данной (в смысле классической евклидовой системы, поэтому - в кавычках); во-вторых, в процессе построения, возникают как бы две «параллельности»: появляются граничные прямые, которые параллельны данной «влево» и параллельны «вправо» (да, именно так). Все прочие параллельные формируют пучок внутри углов, образуемых двумя граничными прямыми. Получается сильнее евклидового варианта. И именно эти две граничные прямые, дающие углы параллельности, определяются как параллельные в данной геометрии. Свойства параллельности в геометрии Лобачевского имеют богатую интерпретацию, но, главное, в геометрическом смысле, даже две прямых, проходящих через точку и не пересекающих данную, это, вообще говоря, несравнимо больше, чем одна прямая у Евклида.
Да, по основанию 2 - "разбегаться" цифры будут иначе.
Это, скорее всего, из-за неполных шрифтов. Нередкая ситуация, к сожалению - далеко не все блоки Unicode есть в доступных шрифтах. Я поэтому специально обернул все шумерские цифры статьи в LaTeX-выражения, как формулы, чтобы они рендерились отдельно в SVG. Видимо, это не очень-то помогло.
Имеется в виду, что 0.99999... - это и есть вторая запись 1.
Вообще, нет.
n = 11:
Но верно для n = 2, B = C = E:
Вряд ли. Q - это точка на кривой, то есть, пара значений. Даже для того, чтобы говорить о битовой разрядности, нужно было бы ввести какие-то высоты и пр. - довольно технический момент. Но ничего про это не сказано, да и смысла нет в таком действии: оно полезно для вычисления дискретного логарифма, но тут-то сразу логарифм известен, по условию.
Исправил. Спасибо.
Чтобы по утекшей информации о внутреннем состоянии на каком-то шаге было вычислительно сложно восстановить предыдущую выдачу. Это, собственно, одно из базовых требований к криптографически стойким генераторам псевдослучайных чисел - поэтому я его упомянул, так сказать, автоматически. Непосредственно на описанный в статье бэкдор - (не)обратимость φ не влияет, это верно, но расширяет возможности: если φ обратима, то через бэкдор можно получить ещё и предыдущие состояния.
Уточнение: в описанном в статье случае, и ξ, и φ - однонаправленные, если не учитывать значение секрета. Бэкдор позволяет получить внутреннее состояние на следующем шаге - как раз потому, что атакующему известен секрет.
Кстати, по "Пропустить" - показался такой же набор, в котором опять была одна клавиатура.
Всё ж, не "двойные эллиптические кривые" - а "удвоенный/двойной генератор (RNG) на эллиптической кривой". Кривая там одна, точек-генераторов - используется две.
Тут, видимо, какая-то опечатка. Что такое "малое значение", применительно к точке кривой? Непонятно, как сравнивать точки (это большая проблема). В упомянутом бэкдоре, если задана точка P, то можно использовать всякую другую точку Q кривой, если вычислить подходящий под P скаляр. Что, собственно, и делается дальше. Другими словами: так как дальше параметры с бэкдором задаются прямо, то никакое требование "малости" тут не нужно.
Вообще, математический смысл данной атаки в том, что владельцу ключа от бэкдора известно соотношение между точками P и Q. То есть, известно такое δ, что δ*P = Q. Это, фактически, шаг протокола Диффи-Хеллмана на эллиптической кривой: P - генератор, δ - секретный ключ, Q - открытый. Зная Q и P вычислительно сложно найти δ (в чистом виде задача "дискретного логарифмирования"). В этом и смысл - для успешной атаки нужно знать секретный ключ, этим ключом "заперт" бэкдор, поэтому не каждая сторона может им воспользоваться. Зная связь между P и Q - можно по выдаче генератора определить его внутреннее состояние (s), перебрав совсем небольшое количество значений.
Не совсем понятно, почему "квантовых вычислений", если, судя по описанию, это эмулятор некоторых моделей квантовой механики или эмулятор квантовых алгоритмов. (То есть, вычисления там явно классические.)
Это да. Так-то тут вообще можно заморочиться и, если случай достаточно редкий, доставать из дампа памяти VM непосредственно сеансовые ключи, чтобы раскрывать трафик полностью пассивно, без терминирования - тогда уже никакое сравнение ключей не поможет в принципе. Я вот более подробно про это писал, как раз на примере истории с jabber.ru: https://dxdt.ru/2023/11/04/11418/
А тот регистратор и всякие облака - они где держат авторитативные серверы? Ну, хорошо, назовём сервер не VPS, а VM (непосредственно на железе сейчас мало кто держит такое) - сетевая ситуация-то не меняется.
Возможно.
Это миф. Нет там какой-то особой защиты. Тем более, если это запросы к DNS. Ну вот работает в конкретной VPS авторитативный сервер DNS - предположим, BIND, или специальный сервер, не важно. Вот приходит к VPS пакет от резолвера УЦ. Это, с сетевой точки зрения, такой же пакет, такой же трафик, как и HTTP не "от УЦ" - у него только номер порта отличается, и, предположим, в HTTP был TCP, а здесь - UDP. Никаких особых методов защиты к "трафику УЦ" не применяется.
А в упомянутых документах - как раз тоже классический. FFDH (Finite Field DH) или "мультипликативный" - это и есть классический.
Этот выбор, как раз, очень логичный: для заворачивания/перехвата трафика есть налаженная и универсальная система, а перехват привязан к не менее универсальному протоколу, не зависит от ПО на сервере.
Чтобы разместить CNAME в зоне - тоже нужен доступ. Да, понятно, что после публикации CNAME - "чужие админы" (читай - чужой скрипт с рутовыми правами) могут редактировать только другую зону, соответствующую CNAME. Это безопаснее с точки зрения управления основной зоной в целом. Однако именно редактирование второй, - CNAME, - зоны как раз позволяет проходить проверку и выпускать сертификаты.
При этом настройка CNAME на стороне администратора зоны часто приводит к ошибкам, потому что это самая неочевидная запись DNS. А на стороне системы проверки доменов УЦ - тоже возникает большой риск ошибок, так как CNAME значительно сложнее обрабатывать резолверу.
У Let's Encrypt должен быть свой резолвер.
Нет. Достаточно перехватить на этапе обращения к авторитативному серверу. Пункт 3 в вашем списке - "[DNS resolvers] -> [ Authorative DNS ]". Авторитативных серверов может быть несколько, но не факт, что УЦ и опрашивает несколько, сравнивая ответы. Как я и написал выше, если нет DNSSEC, то здесь полностью аналогичная HTTP схема: HTTP-узлов так же может быть несколько, они могут быть "в AWS", "в облаке" и т.д.
(Отмечу ещё раз, что, конечно, проверка через DNS, в целом, это существенно более надёжный вариант. Но для стороны УЦ, а не с точки зрения перехвата на уровне провайдера.)
Так DNS уже построена. DANE - базируется на DNS. DANE вообще весьма хорошая, архитектурно, технология. Такое редко встречается в этих интернетах.
DNS - это распределённая БД, хранить там, вообще говоря, позволяется что угодно. Есть SSHFP и пр., скажем. Относительно новая часть, необходимая для DANE - DNSSEC - это да, это такая хрупкая пристройка-надстройка. Но, всё ж, она и предложена-то, буквально, для того, чтобы удостоверять значение записей. Другое дело, что с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень.