Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Небольшой оффтопик. Почитал тут отзывы про консультативную группу “про ИИ в математике”, которую упоминал вчера. В OpenAI, несомненно, сильный маркетинг (и особенно сильно направление, которое принято называть GR/PR – можно отделять от “чистого маркетинга”, можно не отделять, это просто оговорка, тут не важно). Поэтому и данная свежая история про консультативную группу по ИИ в математике – это же чисто маркетинговый ход, по лучшим учебникам, просто хрестоматийный. Странно, что не все это понимают. Смотрите сами: у OpenAI есть риск получить негативный эффект на почве отношения сообщества к тому, что OpenAI ломает складывавшиеся десятилетиями правила публикации “решения задач”. Это далеко не репутационный ущерб, ещё только риск. Но риск есть? Есть. Не проблема, сделаем всё по учебникам: заранее блокируем риск – покажем ответственное отношение к вопросу, сформируем и продвинем консультативную группу!
Теперь заметьте главное: чёткий положительный маркетинговый эффект от создания такой группы – мгновенный. Ещё сильнее он работает в положительную сторону, блокируя риски, в актуальном контексте одобрения “решения ещё сотни задач”. А что же группа будет делать для математики? А это уже вопрос будущего – очевидно, что сам принцип одобрения публикаций такая группа только подкрепляет, поэтому, пока участники группы пытаются как-то оправдать и объяснить своё участие (тоже – “хотим как лучше”), станем пользоваться немедленным положительным маркетинговым эффектом. Мудрый, грамотный ход. Но маркетинговый.
Комментировать »
В 2025 году я писал (в том числе, на “Хабр”), что “суперинтеллект” будет определяться по сообщениям газет. Если точнее, то ИИ станет “сверхразумом”, как только газеты про это напишут. Буквально:
Если только не считать, что степень сверхразумности будет определяться по сообщениям газет: может же так быть, что какую‑то новую систему просто объявят сверхразумной? Вполне.
Что ж, ждать потребовалось не долго: сегодня, в 2026 году, президент США Трамп, как пишут, постановил называть “искусственный интеллект” – “сверхинтеллектом” или “сверхразумом”: Super Intelligence, SI. Такой термин теперь рекомендовано использовать в штатовских официальных правительственных документах. Вот.
Комментировать »
Из OpenAI пишут, что решили ещё “более сотни” давних математических задач (интересно, есть ли там 11.115 из “Коуровской тетради” – ну, а вдруг?) и сформировали, ни много ни мало, а консультативную группу (advisory group) по математике и искусственному интеллекту. Группа, получается, будет определять, что и как публиковать. В общем, что называется, “история получила занимательное продолжение”. Продолжаем наблюдение.
Комментировать »
Недавно я писал о том, что невнятные cybersecurity guardrails (“ограничения/препоны для кибербезопасности”) мешают LLM-системе Claude исправлять собственные же ошибки в программном коде. Поскольку эти самые guardrails начали вылезать едва ли не при каждом запросе, я переключился на теоретическую математику в своих тестах – там, как я думал, guardrails не будет. И действительно, там их нет – всё работает, что называется, “согласно описанию” – без guardrails (да, моментально съедает токены, но это другая история).
То есть, препонов кибербезопасности нет в теоретической математике “силами LLM”.
Пока что.
Дело в том, что недавно появилось очередное открытое письмо про AI/ИИ в математике, подписанное многими филдсовскими лауреатами. И вот как бы по результатам этого письма не добавили “препоны/guardrails” ещё и в упражнения LLM в области теоретической математики. Ну, чтобы ограничить угрозу. Потому что в упомянутом письме прямо признаётся определяющая для соверменной математики роль не столько ИИ/LLM, сколько корпораций, этим LLM/ИИ управляющих, и предлагается озаботиться проблемами – ну, читай, “согласовывать и ограничивать”.
Комментировать »
В блоге Cloudflare – подробности про поддержку ML-DSA DNS-сервисом 1.1.1.1 (я писал об этом пару дней назад). По ссылке (на сайт Cloudflare), собственно, в подробностях развёрнуты все те же моменты: переход DNS на TCP (потому что ответы с ML-DSA не пролезают в UDP) и внедрение соответствующих криптосистем в корне DNS. И есть новый пример зоны с ML-DSA в DNSSEC: valid.mldsa44.dnstest.dev.
Комментировать »
Anthropic (это Claude) на днях опубликовали, как заявляется, полную “формализацию” для Великой теоремы Ферма. Под “формализацией” тут надо понимать машинное описание всего набора необходимых теорем, за исключением нескольких базовых. С точки зрения алгоритмов, речь там про Lean-код, который подтверждает верность выводов – там заявлено 29511 сопутствующих теорем (это в терминах Lean, но, вообще, тут не так важно), то есть, заведомо необозримый кусок текста, и даже для машинной проверки – требуются сотни гигабайтов памяти (ОЗУ) и многие часы работы компьютера.
Но тут особенно интересен сопутствующий аспект: а именно, то, как новость подаётся. В тексте официальной новости несколько раз упоминаются другие, “человеческие” начинания на пути этой же “формализации”, но эти начинания, пока что, успеха не достигли, что тщательно подчёркивает текст новости. И это так, тут не поспорить. Достигла ли успеха машинная программа с миллионами строк и десятками тысяч “машинных теорем”? Тоже непонятно. Собственно, тут-то и кроется действующий конфликт: с завершающими заявлениями по долгоиграющим популярным темам вокруг теоретической математики начали выступать не университеты какие-нибудь, а коммерческие корпорации, поставляющие мощнейший вычислительный сервис, который принято называть LLM/AI. И выступают эти корпорации тут нынче регулярно: следом за “Ферма-формализацией” – свежее заявление по уравнениям Навье-Стокса от OpenAI (это проблема из раскрученного списка “Задачи тысячелетия”).
Комментировать »
Секунду координации (leap second) хотят отменить совсем. Одна из основных причин: по мнению Международного бюро мер и весов, есть большой шанс, что к 2035 году придётся вводить “отрицательную” секунду координации. То есть, раньше, для коррекции – секунду координации добавляли. Часы, работающие по “общепринятому” источнику частоты, ждали одну дополнительную секунду в сутках, чтобы их догнали астрономические события, связанные с вращением Земли. Расчётные сутки – удлинялись на секунду. Процесс должен компенсировать “убегание” метрологических источников частоты от представления о вращении Земли, как об историческом источнике понятия о сутках. Ну или наоборот – происходило “опережение”, тут уж как посмотреть: главное, что всегда есть некая накапливаемая разница, а знак её, вроде, не так важен. Ну, пока не возникает та самая “отрицательная” секунда координации.
Вопрос этот и сам по себе весьма спорный – вращение Земли не имеет строго определения, координация зависит от используемых методов подсчёта наблюдаемых событий и т.д., и т.п. Но это всё технические мелочи, по сравненению с тем, что в 2035 году эта же трактовка может привести к тому, что нужно будет реализовать “отрицательную” секунду, то есть, “перевести часы в обратную сторону” и одну секунду удалить из привычной минуты, и из суток. Представьте, что за 23:59:58 следует 00:00:00 следующих суток! Для точных компьютерных систем это выглядит пострашнее “проблемы 2000”. Из календаря исчезает секунда, поэтому, предположим, если где-то встретится TLS-сертификат, начало действия которого обозначено как 23:59:59, но дата приходится на сутки, когда произошла коррекция, то, получается, такого таймстемпа просто не существовало. И это даже посложнее, чем если кто-то написал 23:59:63. В последнем случае, хотя бы, можно заявить о нарушении формата, а вот 23:59:59 – никаких форматов не нарушает. Нарушает ли их 23:59:60, кстати? Отдельный вопрос. Как бы там ни было, но “отрицательную” секунду координации придётся дальше учитывать во всех вычислениях с преобразованием таймстемпов в календарное время. Тут и положительная-то секунда постоянно приводит к неприятностям, что уж там говорить об отрицательной.
Так что, вполне возможно, секунд координации больше не будет, остчёт секундного времени станет “равномерным”, но зато сделают сразу час координации. Ну а что – час? К нему, предположительно, нужно будет вернуться через несколько веков (именно: см. Draft Resolution C). Так-то. Было бы кому возвращаться.
Комментировать »
Нередко я называю современные LLM-системы “синонимайзерами”. Термин, возможно, не самый точный. Однако, как ни странно, его применимость теперь полностью подтверждается свежей официальной публикацией Anthropic, про проставление меток (“водяных знаков”) на выдаче системы Claude. Там уже самое начало текста полностью раскрывает связь с “синонимизацией”. Буквально утверждается, что нет разницы между двумя словами (синонимами) в заданном предложении, поэтому конкретное слово выбирается случайным образом. (На задании псевдослучайной последовательности, управляющей работой такого синонимайзера, как раз построен механизм простановки метки, но сейчас не об этом.)
Цитата (и перевод):
Take the sentence “The weather today was cold and…”. The next word is very unlikely to be “sugary.” But it is quite likely to be “overcast” or “grey.” Under most circumstances, it doesn’t matter much to the reader which of these latter two words the model ultimately chooses—the meaning of the sentence is largely the same either way. In cases like this, the choice is settled by a random number.
/Возьмём предложение “Погода сегодня была холодной и…”. Вряд ли следующее слово будет “сахарной”. Но вполне вероятно, что следующее слово это “пасмурной” или “серой”. В большинстве случаев, для читателя не имеет значения, какое из двух слов модель в конце концов выберет: значение предложения, в общем-то, одинаковое, так или иначе. В случаях, похожих на этот, выбор осуществляется при помощи случайного числа./
Обратите внимание: “синонимы” вне контекста и “случайное число”. Всё сходится. Это описание синонимайзера. Между тем, с литературной точки зрения, два английских предложения “the weather today was cold and overcast” и “the weather today was cold and grey”, конечно, имеют разную коннотацию. Особенно, если предположить, что вокруг есть некий больший контекст. Английский вариант тут работает почти так же, как и русский: “погода сегодня была холодной и пасмурной” и “погода сегодня была холодной и серой”. Но для синонимайзера – здесь главное не коннотация, а то, что синонимы есть и их возможно переставить, а значит, можно и приспособить образовавшуюся вариабельность в качестве носителя метки текста! Далее там как раз объясняется, что если возможности для синонимизации нет, – как в конкретных декларациях фактов, например, – то и метку не применить. Конкретные декларации здесь, это о том, что добротная система не может “синонимизировать” слово “братья” в сообщении о том, что роман “Братья Карамазовы” написал Достоевский.
К сожалению, такой подход начисто удаляет и “интеллект” (в кавычках) и литературную основу, заменяя процесс на механическую “простановку меток”.
Комментировать »
В продолжение записки про метки на выдаче LLM-систем, которые должны позволять атрибутировать текст (или другой тип контента), как сгенерированный ИИ/LLM. Тут есть несколько нехороших моментов.
Момент первый. Если определять такие метки будет тот же провайдер, который обеспечивает LLM, то получается существенное усиление позиции этого провайдера: он сможет по собственному разумению приписывать своей системе произвольные тексты.
То есть, LLM-провайдер захватил и использовал в своих целях практически весь контент, до которого смог дотянуться (в том числе, страницы веб-сайтов), а теперь ещё и сможет маркировать контент как “свой”, придавая, тем самым, дополнительную окраску различным публикациям. Тут важно понимать, что это только кажется, будто тут борбьба идёт за то, что некие пользователи распространяют “сгенерированный контент” как “подлинный”. Нет. Вопрос подлинности контента остаётся в стороне. Выдача LLM тоже может быть подлинной. Банальный пример – это, например, публикация, основная часть которой – разбор особенностей этой самой выдачи. Есть и небанальные примеры: цитирование и синонимизирование текстов LLM-генератором.
Так что речь не про произвольную атрибуцию, а про навязываемую окраску: и контент был, буквально, отобран и захвачен через синонимизацию, и результат захвата теперь использовать не позволяется без обязательного окрашивания тем же провайдером того же самого сервиса, в который этот контент утёк. И это всё в ситуации, когда без крупнейших LLM-систем уже практически не обойтись, поскольку и интернет-поиск сломали, и всё вокруг заливается выдачей этих систем. Ещё раз: это, конечно, работает только в том случае, если обнаружение меток и аутентификацию таки оставят за провайдерами LLM-сервисов, а сам метод детектирования не будет подразумевать непрерывного независимого аудита (хотя, кого такой аудит пугает? и где же его “независимость”?).
Момент второй. Что делать, если вполне себе авторский текст, написанный человеком, а не сгенерированный LLM, тем не менее, детектор меток записывает за LLM? То есть, автору говорят – нет, это всё сгенерировано.
– Вы просто переписываете “Википедию”!
– Нет, это не так, это редакторы “Википедии” берут мои статьи за основу.
Ошибки атрибуции, понятно, не то что возможны, они – обязательно будут. Про эти самые ошибки до сих пор написано в тех же самых интерфейсах лидирующих LLM-сервисов. Более того, если метка не является криптографической, то подготовленному человеку не составит особого труда написать текст, который будет определяться как сгенерированный данной LLM. То есть, тут уже получается такое “навязывание метки”. Можно подумать, что это ерунда. Но нет – кто там знает, что “такое сомнительное” могут “навесить” на сервис? Тоже интересный момент.
– Можно ли подзарядить мой смартфон от твоего портативного аккумулятора?
– Конечно. Подключай.
– Спасибо! Ого, а что это там замигало?
– Это данные передаются.
– Да? Ну, ладно, мне нечего скрывать из того, что есть в смартфоне.
– А кто сказал, что данные считываются из смартфона? Напротив, они сейчас туда загружаются. И, кстати, теперь тебе есть, что скрывать.
Момент третий. Что считать достаточной “степенью генерирования”? Подходит ли дорисованная на ночную фотографию пейзажа Луна? Это достаточное вмешательство, чтобы стать “генерированием”? А если Луну дорисовало ПО фотокамеры в смартфоне? А если это сработал “фильтр” в программе для обработки цифровых фотографий, и Луна не дорисована полностью, но “улучшена”? Считается ли исправление орфографических ошибок в тексте достаточным признаком? Сколько ошибок можно исправить автоматом, чтобы деятельность автомата посчиталась как генерирование LLM? Есть ли разница между “орфографией” на буквах и “рисованием” на пикселах? Сколько можно исправить пикселов? Заметьте, что практически всякое установление границ и лимитов на этом направлении тут же приводит к размытию и лимитов, и границ.
Но, конечно, хуже всего выглядит то, что LLM-првайдеры получают возможность помечать как “свой” контент, полученный на основе творчества человеческих авторов, а позже лишь синонимизированный. И на основании такого окрашивания будет выстраиваться отношение к исходным идеям и публикациям. Максима “Компьютер не может ошибаться” приведёт к тому, что LLM-сервис, на основании значения метки, станут считать первоисточником. Причём, вот тут уже и не требуется, чтобы метки обрабатывал тот же провайдер, который предоставляет LLM-сервис.
Comments Off on Метки и окрашивание контента от LLM-систем
Сейчас модная тема – влияние AI/ИИ на математику. Из-за того, что эта тема очень хорошо “прогрета” хайпом, раздуваемым вокруг ИИ/AI в прессе широкого назначения, она уже стала довольно сильна и внутри математического сообщества. Недавний пример раздувания – публикация OpenAI решений очередных “важных задач” силами LLM-систем. Чуть более ранний пример “внутренней реакции” – The Leiden Declaration.
Тут, естественно, основной момент в том, что коммерческие компании начали активно использовать реально специальные математические задачи в качестве марекетингового хода. Такой грубый перелом социальной страты нравится далеко не всем. Мнения, в стиле “что же теперь нам всем делать”, есть разные. Иногда интересные. Вот, например, в свежей статье The Crisis of AI-generated Mathematics (Max Weinreich, препринт), в качестве ответа на публикации, генерируемые LLM, фактически, предлагается внедрение на стороне журналов нового процесса, который приведёт к построению “обратной капчи”. Такая “обратная капча” нужна для доказательства того, что кто-то, – то есть, “человеческий математик”, – претендующий на “владение темой статьи”, действительно хорошо разобрался в этой теме. Цитата (перевод с английского):
Традиционное авторство можно было бы заменить на принцип “совладения” для математических идей. В этой парадигме всякий математик, который продемонстрировал “императивное” (“авторитетное”, authoritative) понимание работы, – на уровне, ожидаемом от автора сейчас, – сможет претендовать на то, чтобы стать “совладельцем” идеи, даже после публикации основного результата. У каких-то статей будет несколько “совладельцев”, а у других – десятки или даже сотни. Журналы получат захватывающую, – но трудную, – роль по установлению норм подтверждения понимания и сопровождения инфраструктуры “совладения”. На это потребуется время, очень много времени. Детальное объяснение целой статьи скептически настроенной аудитории часто составляет предмет целого спецкурса. Но если математики более не заняты написанием статей, то у нас будет дополнительное время. Это время нужно вернуть математике, в её наиболее социальных и человеческих формах.
Ключевые слова тут – “социальной” и “человеческой”.
Кстати, я не так давно писал про тавтологические капчи. Это концептуально похожая идея.
Комментировать »
В Cloudflare на днях обновили свой сервис мониторинга логов Certificate Transparency (CT). Мониторинг отслеживает публикацию в логах (пре)сертификатов для заданного доменного имени. Напомню, что в прошлом году ни наличие сервиса мониторинга, ни наличие собственных логов CT, не помогли Cloudflare в течение нескольких месяцев выявить неавторизованный выпуск TLS-сертификатов для собственного же сервиса 1.1.1.1 (один из самых известных сервисов Cloudflare). Возможно, какие-то выводы были сделаны. Однако в этом контексте текущее обновление сервиса мониторинга CT выглядит ещё более странным. Дело в том, что это обновление отключает вывод оповещений о сертификтах, выпущенных системами Cloudflare. И делает это при помощи фильтра по открытым ключам.
То есть, если кратко, то клиентам, использующим веб-фронтенд Cloudflare и мониторинг CT, в этот самый мониторинг больше не будут приходить уведомления о том, что для их домена сертификат выпущен Cloudflare в рамках работы веб-фронтенда. Озвучиваемая причина: сертификаты выпускаются часто (у них короткий срок действия), оповещения дублируются, множатся, а их большой поток запутывает пользователя, который, в результате, перестаёт реагировать на подобные оповещения вообще. (Кстати, в истории с 1.1.1.1, “большое количество оповещений” прямо названо среди причин, по которым неавторизованные сертификаты не обнаружили своевременно – тут у Cloudflare все последовательно.)
Различать предлагается не сертификаты, а ключи. Так что сервис мониторинга CT больше не будет присылать уведомления об обнаружении в CT-логах серверных сертификатов, если эти сертификаты содержат тот же открытый ключ, который был сгенерирован Cloudflare для использования на TLS-прокси в сервисе веб-фронтэнда. И это весьма важный момент. Который, тем не менее, в сообщении Cloudflare освещается как-то однобоко. Да, по открытым ключам различать сертификаты удобнее, чем по отпечаткам полного сертификата. Я и сам так рекомендую делать, это здравый подход. Когда применяется правильно. Но нельзя забывать, что для выпуска сертификата Удостоверяющему Центру (УЦ) не нужен секретный ключ, соответствующий открытому ключу клиента.
То есть, то, что Cloudflare отслеживает и фильтрует сертификаты по ключу, не означает, что отслеживаются только сертификаты, выпущенные по запросу систем Cloudflare. Это совсем разные вещи, но про это Cloudflare не сообщает. Поскольку выпуск сертификата не требует секретного ключа, то, технически, какой угодно УЦ может выпустить сертификат для того же серверного открытого ключа, что использует и Cloudflare. Однако мониторинг CT, если верить описанию, этот сертификат не покажет. Проверка подписи в CSR и пр. – это, да, это всё привычные шаги, но, ещё раз, технически они никак на выпуск сертификата не влияют.
Конечно, такой выпуск сертификата для произвольного ключа – возможность весьма теоретическая, не поспорить: да, для выпуска секретный ключ не нужен, но, как минимум, чтобы использовать подобный “подменный” сертификат – тут секретный ключ уже потребуется. Это, однако, не отменяет странной подмены понятий: совпадающий открытый ключ – вообще никак не означает, что сертификат был выпущен по запросу систем Cloudflare, утверждать такое – ошибка.
Естественно, мониторинг CT с подобным фильтром “по ключам” в принципе не сможет проинформировать о некоторых критических событиях. Например, если скомпрометирован аккаунт в Cloudflare и кто-то выпускает “левые сертификаты”. Да, тут можно возразить, что если скомпрометирован аккаунт, то тогда и мониторинг можно отключить. Да, можно. Но не всегда аккаунт скомпрометирован полностью. Дело в том, что авария или взлом на стороне систем Cloudflare – тоже выпадают из новой версии мониторинга, а между тем, тут уже полезно было бы оповещение: потому что “сломаться” может и лишь та система, которая генерирует сертификаты, например.
Как именно отпечатки ключей используются? Возможно ли их “просачивание” между аккаунтами? Непонятно. Если такое возможно, то Cloudflare может использовать тот же открытй ключ, но для разных имён и, соответственно, разных сертификатов, хотя бы и по ошибке. Сертификаты будут опубликованы в CT-логах, но фильтрация по значению ключа такое не покажет.
Не менее интересно и то, что, если скомпрометирован сам фильтр, то можно добавить туда “нужные ключи” и – мониторинг перестанет выводить новые сертификаты. Ну или вообще там в результате атаки будет создан поток для добавления “правильных ключей” – такое нынче тоже нельзя исключать.
В общем, получилась подмена базовой концепции. Формулировка базового вопроса, стоящего за подобным мониторингом CT, такая: разрешил ли администратор имени выпуск этого конкретного сертификта? Но, получается, что её “незаметно” подменили на другую: узнаёт ли сервис Cloudflare данный открытый ключ из сертификата? Почувствуйте, как говорится, разницу.
Всё это, понятно, не делает мониторинг бесполезным, но всё же. Остаётся надеяться, что сделают флаг в настройках – “Показывать все сертификаты”.
Комментировать »
Новый