Там, с этой первой задачей и LLM, самое забавное, что сразу, в начале решения, "экспериментальная модель" пишет правильный ответ, - откуда он взялся? - а потом собирается доказывать, что ответ - правильный:
Will prove: , independent of n.
Но даже этот кортеж значений, составляющий половину ответа, - {0, 1, 3}, - его нет в условии, он получается в ходе решения. (Вторая половина ответа в том, что набор вариантов не зависит от n.)
Там нет никакого «времени». Это лишь популярное упрощение, происходящее из неверного обобщения рекурсивного термина «интервал времени», где рекурсия начинается с применения термина к определению секунды (такой вот вариант «GNU's Not Unix»). В физике вообще нет «времени» в этом смысле. Упомянутые эксперименты — они про источники частоты, про наблюдения над «осцилляторами». То есть, это всё про подсчёт некоторых периодических физических событий: переходы между «состояниями» и т.д., откуда и возможность определения погрешности без требования наличия неких «часов с абсолютной точностью». Учитывая современное определение секунды, всё здесь базируется на Стандартной модели, в предположении, что предсказания этой модели о частотах внутриатомных процессов стабильны и универсальны, как «во времени», так и в пространстве. Причём, «время» — означает лишь некий порядок подсчёта: что послечего произошло, в том смысле, что есть аппаратная реализация функции, различающей события, а раз события различаются, то, зафиксировав очередной переход между отдельными событиями, можно к их количеству прибавить ещё одно. Досчитали до заранее заданного количества — получили единицу измерения: секунду.
При этом, подсчитываемые события — дискретные по определению, так что нельзя увидеть, что там внутри одного такта. Грубо говоря, пусть у нас есть некий механический маятник, который спрятан в ящик и поэтому его не видно, однако в крайних положениях он замыкает электрические контакты, провода от которых выведены наружу ящика, поэтому можно считать импульсы, соответствующие крайним положениям, но нельзя достоверно определить, насколько маятник в своём движении близок к тому или иному контакту, пока этот контакт не сработал. Ну, раз так, то будем строить один за одним «рекурсивные маятники» таким образом, что для каждого следующего маятника выбранная теоретическая модель предсказывает, что за один такт маятника из предыдущего шага этот новый маятник — выдаёт несколько тактов, повышая разрешение.
Вообще, если трактовать 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. Никаких особых методов защиты к "трафику УЦ" не применяется.
Этот выбор, как раз, очень логичный: для заворачивания/перехвата трафика есть налаженная и универсальная система, а перехват привязан к не менее универсальному протоколу, не зависит от ПО на сервере.
Оно слишком знаменитое.
Там, с этой первой задачей и LLM, самое забавное, что сразу, в начале решения, "экспериментальная модель" пишет правильный ответ, - откуда он взялся? - а потом собирается доказывать, что ответ - правильный:
Но даже этот кортеж значений, составляющий половину ответа, - {0, 1, 3}, - его нет в условии, он получается в ходе решения. (Вторая половина ответа в том, что набор вариантов не зависит от n.)
Там нет никакого «времени». Это лишь популярное упрощение, происходящее из неверного обобщения рекурсивного термина «интервал времени», где рекурсия начинается с применения термина к определению секунды (такой вот вариант «GNU's Not Unix»). В физике вообще нет «времени» в этом смысле. Упомянутые эксперименты — они про источники частоты, про наблюдения над «осцилляторами». То есть, это всё про подсчёт некоторых периодических физических событий: переходы между «состояниями» и т.д., откуда и возможность определения погрешности без требования наличия неких «часов с абсолютной точностью». Учитывая современное определение секунды, всё здесь базируется на Стандартной модели, в предположении, что предсказания этой модели о частотах внутриатомных процессов стабильны и универсальны, как «во времени», так и в пространстве. Причём, «время» — означает лишь некий порядок подсчёта: что после чего произошло, в том смысле, что есть аппаратная реализация функции, различающей события, а раз события различаются, то, зафиксировав очередной переход между отдельными событиями, можно к их количеству прибавить ещё одно. Досчитали до заранее заданного количества — получили единицу измерения: секунду.
При этом, подсчитываемые события — дискретные по определению, так что нельзя увидеть, что там внутри одного такта. Грубо говоря, пусть у нас есть некий механический маятник, который спрятан в ящик и поэтому его не видно, однако в крайних положениях он замыкает электрические контакты, провода от которых выведены наружу ящика, поэтому можно считать импульсы, соответствующие крайним положениям, но нельзя достоверно определить, насколько маятник в своём движении близок к тому или иному контакту, пока этот контакт не сработал. Ну, раз так, то будем строить один за одним «рекурсивные маятники» таким образом, что для каждого следующего маятника выбранная теоретическая модель предсказывает, что за один такт маятника из предыдущего шага этот новый маятник — выдаёт несколько тактов, повышая разрешение.
Вообще, если трактовать 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) или "мультипликативный" - это и есть классический.
Этот выбор, как раз, очень логичный: для заворачивания/перехвата трафика есть налаженная и универсальная система, а перехват привязан к не менее универсальному протоколу, не зависит от ПО на сервере.