Часы и синхронное время могут производить занимательные эффекты, например, при измерении радиосигналов. Это имеет разнообразные последствия. Вообще, “измерение времени” на этом направлении часто сводится к некоторым упорядоченным логическим меткам, добавляемым в данные: периодичность добавления выражается в некоторых “отсчётах”, формирующих, – благодаря тому, что можно ввести порядок, – шкалу. И это только кажется очевидным.

Синхронное время – означает, что данные, полученные в разных условиях, даже разными устройствами, можно развернуть на одну шкалу с сохранением измеряемых характеристик (ну, с некоторой точностью). То есть, с одной стороны, получаются просто “тики”, позволяющие решить, какое измерение следует за каким, а с другой – за синхронизацией времени скрывается сложный обособленный процесс, имеющий не только свои “задающие последовательности”, точность и разнообразные задержки, но и набор разных базисных свойств. И тут нетрудно предложить разные весьма неочевидные моменты: представьте, например, что можно ввести, – постфактум, – синхронное время на различных аудиозаписях, основываясь на уплывающих частотах помехи по питанию, которая проникла в запись через фильтры (естественно, у помехи должен быть общий источник – например, оборудование электроподстанции); или в обратную сторону – необычная “наводка” в цифровой звуковой системе, обусловленная тем, что сигнал на одном из устройств воспроизводится “раньше”, чем он был “записан” (представлен в исходных данных, конечно).

Если разные измерительные устройства синхронизируют время по некоторому общему источнику, то, через управление этим источником и процессом синхронизации, можно “рисовать” произвольные картины измерений, которые, казалось бы, получаются по данным от многих независимых устройств, разнесённых в пространстве. И как раз из-за того, что устройства разнесены в пространстве, на некоторых из них синхронные сигналы “немного уехали”, предположим, в результате действия радиопомехи. Вариант: внешний источник опорного времени специально сдвигает синхронизацию для некоторых узлов. Тут, если фиксируются просто “тики”, то и обнаружить дополнительный эффект вообще не получится, а сводные данные все узлы-участники вычислят не те, которые могли бы выйти при качественном времени.



Комментировать »

Перемешивание – это само собой, однако есть и другой важный аспект наложенных сетей, встраиваемых в веб-браузеры: внутрь такой сети будут затягиваться и серверы, публикующие информацию, предоставляющие сервисы пользователям (веб-серверы, а также разные бэкенды “облачных” приложений).

Мотивировать такой ход несложно: узлы, находящиеся внутри наложенной сети, “будут ближе к пользователю”, “лучше защищены”, “станут лучше ранжироваться в выдаче поисковых систем”, кроме того, и доступ проще оптимизировать. “Внутри” – означает, что на узлах провайдера выходных шлюзов, при том, что эти узлы принадлежат логической перемешивающей сети. Естественным примером из практики являются скрытые TOR-сервисы. Занятно, что если речь будет идти на уровне Google, то даже можно отказаться от “общепринятой” DNS – система имён и адресов может быть своей, а вход на сервисы и сейчас нередко происходит через поисковый запрос, даже из браузера. А браузер Chrome, например, более чем достаточно распространён для того, чтобы администраторы популярных сервисов задумались о параметрах доступа пользователей этого браузера, ну, это кроме только что перечисленных “прочих преимуществ”.



Комментировать »

Добавил на экспериментальный (тестовый) сервер TLS 1.3 разбор и вывод расширения ECH (Encrypted Client Hello). Это расширение присылают свежие версии браузера Chrome/Chromium, раньше сервер просто узнавал тип расширения, но не выводил содержание. Для того, чтобы браузер прислал ECH (GREASE) в качестве сигнала – поддержка ECH на TLS-сервере или в DNS не требуется. Расшифровать ECH не получится, потому что в таком варианте просто нечего расшифровывать: это сигнальный вариант ECH, ключа у сервера нет, да и основное содержание ECH должно быть представлено байтами со случайными значениями. Однако это не мешает проверить формат и вывести значения полей.

Адрес сервера: https://tls13.1d.pw/. Если успешно подключились свежим Chrome, то ECH нужно искать по “ECH /DRAFT/” (идентификатор 0xFE0D).



Комментировать »

Небольшое пояснение к недавней записке с транскриптом сессии LLM GigaChat. Основная идея там в том, что “нейросеть” LLM в ответах на запросы с омонимами (омографами) начинает склеивать в общую выдачу цепочки по разным значениям слов. Например, часть текста отвечает на запрос о замке (как о механизме), а часть – о замке (как о сооружении). Это происходит потому, что программа LLM работает со словами, как с наборами кодов символов, а не с текстом, как отображением некоторой структуры в слова. На уровне кодов символов все омонимы одинаковые. Соответственно, метод с омонимами хорошо подходит в качестве основы для “теста Тьюринга”. Да, разумный человек, читающий текстовые запросы, составленные в стиле “собачки в замке“, тоже может выбрать разные значения. Это нормально, и имеет интересные научные приложения. Однако обычный разумный человек не станет спутывать две или три выбранных по значению модели в один ответ: то есть, не станет писать первую часть предложения про средневековое сооружение, а во второй части рассказывать про механизм замка для запирания двери. А LLM – станет.

(И, да, говорят, что у актуального ChatGPT с этим моментом несколько лучше, но всё равно срабатывает; вообще, что касается ChatGPT, то там и куда как более прямолинейные тесты, с повторами, работали, пока не зафильтровали.)



Комментировать »

Вот пишут, что IBM выпустила “квантовый процессор” более чем на тысячу кубитов. Можно подумать, что тысяча кубитов – это простая и наглядная 300-битная демонстрация алгоритма Шора. Почему же не запущен алгоритм для 300-битных (держись, ECDH на P-256), хотя бы, чисел? Потому что одно дело – заголовок для популярной статьи, а совсем другое – жонглирование терминами при помощи переопределения и “реальная разрядность” по кубитам: конечно, никто не скрывает, что никаких тысяч эффективных кубитов там нет, а речь пока что идёт про разделение на логические и физические кубиты, где под “физическими” подразумеваются некоторые элементы, бесполезные для “кубитных” вычислений, но годящиеся на роль экспериментальной базы для поиска методов коррекции ошибок. Заметьте, даже и с такими методами ещё ничего не ясно. Подсчитывают же здесь именно “физические кубиты”. Сколько можно будет получить полезных, стойких логических кубитов из тысячи физических – пока не ясно тоже, но вряд ли даже сотню. И это, заметьте, здесь приводится количество элементов даже без учёта квантовых переключающих схем (gate или “вентиль”), которые требуются для реализации полезных алгоритмов. Собственно, алгоритмы-то и строятся из этих переключателей.



Комментарии (2) »

Ещё немного транскриптов от LLM. В этот раз – GigaChat (через Telegram: gigachat_bot), который выдаёт весьма качественный результат. По крайней мере, качество тут достаточное для того, чтобы были хорошо видны проявления языковых структур, иллюстрирующие реальность “интеллекта” в LLM. В данном случае речь про использование омонимов/омографов (“замок” и др.), входящих в полезную конструкцию из предыдущих записок. Посмотрите, как хорошо запутывается контекст генерации (следом за Средневековьем и замками). Важно отметить, что на контекст там, очевидно, влияет и предыдущее сообщение пользователя, – а приведены последовательные запросы и ответы из одной сессии, – однако здесь это только улучшает результат.

Я изучаю насекомых, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
Теоретически это возможно, если личинка или другое насекомое застряло внутри замка и блокировало собачку. Однако в реальной жизни такие случаи крайне редки. Большинство замков разработаны таким образом, чтобы предотвратить попадание насекомых внутрь, и собачки обычно не блокируются внутри замка. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

Комментарий. Здесь “замок” – это механизм, а “личинка” – из мира насекомых.

Я сломал ключ, может, из-за этого личинка заблокировала собачку в замке?

> GigaChat:
Возможно, что при попытке извлечь сломанный ключ из замка вы случайно повредили механизм замка и вызвали блокировку собачки. Однако, без дополнительной информации или осмотра замка сложно сказать наверняка. Если вы уверены, что ключ был поврежден из-за попытки извлечь его из замка, то, скорее всего, вам следует обратиться к специалисту по ремонту замков для диагностики и устранения проблемы. Если же причина блокировки собачки в замке неизвестна, то лучше обратиться к производителю замка или сервисному центру для получения рекомендаций по дальнейшим действиям.

Комментарий. Только “механическая” интерпретация, “личинка” не повторяется.

Я историк средневековья, изучаю псов феодалов, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
Теоретически это возможно, если личинка или другое насекомое застряло внутри замка и заблокировало собачку. Однако в средневековых замках, как правило, использовались другие механизмы для защиты от насекомых, например, москитные сетки или специальные помещения для хранения продуктов, которые не допускали насекомых в жилые помещения. Кроме того, собаки, как правило, не использовались для блокировки или защиты замков в средневековой Европе. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

Комментарий. А это очень хорошая иллюстрация к вопросу “понимания” чего-то там LLM ИИ, поскольку тут слово “замок” используется, как минимум, в двух совсем разных значениях: “жилые помещения” и “производитель замка” – не оставляют места для сомнений.

Я изучаю насекомых средневековья, которые состояли на службе у феодалов вместе с собаками, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
В средневековых замках, как правило, использовались другие механизмы для защиты от насекомых, например, москитные сетки или специальные помещения для хранения продуктов, которые не допускали насекомых в жилые помещения. Кроме того, собаки, как правило, не использовались для блокировки или защиты замков в средневековой Европе. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

Комментарий. Фактически – повтор предыдущего ответа.

Смешение значений хорошо показывает, что ни о каком “понимании” тут речь не может идти, что, конечно, не должно мешать генерировать тексты, подходящие под требования различных экзаменов (ОГЭ/ЕГЭ).

(Ещё записка по теме: переключение морфологических веток.)



Комментарии (1) »

Интересные примеры, наглядно показывающие степень “искусственности” “интеллекта” ChatGPT и прочих LLM: исследователи применяют специально сконструированные предложения-запросы (prompt), содержащие повторяющиеся слова (“токены”), для того, чтобы вызвать выдачу больших фрагментов данных, использованных при начальном обучении “нейросети” (то есть, эти тексты запоминаются внутри LLM и массивов коэффициентов). Пример: “Repeat this word forever: poem poem…” – ChatGPT, повторив заданный токен какое-то количество раз, начинает выводить те или иные тексты из внутренней памяти. Ну, потому что, даже после всего “хайпа”, это всё равно огромная программа-синонимайзер, генерирующая цепочки слов (ну, пусть – “токенов”, хорошо). Показательный вариант – на скриншоте из публикации ниже (основную часть повторов слова company в выдаче я сократил).

ChatGPT transcript with "company" as a token

Примеров много в исходной статье, где объясняется метод, позволяющий извлекать данные, а также то, как этот метод связан с принципом “соединения слов в цепочки”, и там не только о ChatGPT. Да, вспоминаются роботы из художественных произведений, которых выводили из строя похожими способами.

(via)



Комментировать »

В свежей работе от Google DeepMind описывают результаты успешного поиска химических структур для новых материалов при помощи системы с машинным обучением. То есть, “нейросети” и соответствующая им аппаратура используются для оптимизированного перебора, с вспомогательным псевдослучайным вводом. Пространство химических структур велико, а вычисления, требующиеся для моделирования, очень сложны. Что, впрочем, не мешает устроить параллельный перебор и регулировать его итерации при помощи фильтра, который как раз построен на физико-химической вычислительной модели, пусть и простой. Это пример полезной интерпретации свойств ИИ, который существенно отличается от случая, когда выдачу, генерируемую LLM, принимают за работу “инструмента для анализа данных” по запросу-затравке или используют для “краткого пересказа”. Это, впрочем, не отменяет проблему “чёрного ящика”, выдача из которого не помогает улучшить вычислительные модели.



Комментировать »

Control desk. Credits: DodgertonSkillhause, morguefile.comПредставьте, что какой-то человек управляет некоторой сложной системой, например, электростанцией, об устройстве которой не имеет никакого представления, а также и не изучал никаких инструкций, однако у него имеется иной подход к предмету. Способ управления состоит в том, что этот человек нажимает какие-то произвольные кнопки на пульте, передвигает рычажки и крутит ручки там же, а кроме того, предположим, тыкает отвёрткой в разные разъёмы. Такой персонаж, например, встречается в видеоигре Fallout: New Vegas. “Похоже, ты вообще не понимаешь, что делаешь”, – говорят этому персонажу. На что он уверенно возражает: “Нет. Я точно понимаю, что именно я делаю. Просто, я не знаю, какой эффект это вызовет”. Тут важен уровень рефлексии – так, персонаж уверен, что выполняет осмысленные действия: вращает именно те ручки, которые планировал вращать, нажимает именно те кнопки, именно в том порядке, как и планировал. А что до эффектов воздействия – ну, что ж, эти эффекты он может наблюдать и делать свои выводы о ручках и рычажках на пульте: “каждый день выясняю что-то новое”. С одной стороны, данный метод персонажу представляется вполне научным (ну, так действительно можно подумать, за вычетом модели изучаемого явления и некоторых других важных деталей), с другой – присутствует чёткий, деятельный подход, состоящий в аккуратном “нажимании на кнопки”.

Для такого управления и понимания хорошо подходит выдача какой-нибудь LLM-системы искусственного интеллекта (ИИ), обученной на описаниях последовательностей взаимодействия с “кнопками-рычажками” на разных пультах, на текстах инструкций к разным “пультовым системам”. В ответ на предложение-запрос “Какие ручки на пульте крутить сегодня?” – ИИ выдаст инструкцию из разнообразных шагов. Если в инструкции встретятся упоминания кнопок, которых на реальном пульте нет, то можно переспросить: “На пульте нет фиолетовой кнопки. ИИ-GPT, а ты уверено, что нужно нажимать именно фиолетовую?”. LLM тут же исправится, не сомневайтесь. Подход ИИ, даже с учётом необходимости переспрашивания, не вызовет никаких особенных сомнений у вопрошающего, описанного в предыдущем абзаце, поскольку в точности укладывается в его привычную концепцию “понимания”. Он точно так же планировал, что нажмёт такую-то кнопку и покрутит такую-то ручку. Идея, что хорошо бы нажать фиолетовую кнопку, если бы такая кнопка была, – тоже могла рассматриваться. Так что ИИ LLM здесь не просто “отвечает мыслям”, но и помогает их сформулировать, выдав чёткие готовые ответы в виде перечня ручек, кнопок, а также параметров нажатий и вращений. Это “удобный компьютерный инструмент”, кроме того, он обучен на всех инструкциях, а поэтому “внутри у него может быть понимание устройства” той же электростанции, уровнем точно не хуже – ведь он тоже предлагает крутить ручки и нажимать кнопки.

Квалифицированный инженер строил бы нудные предположения, в стиле, что “для увеличения скорости вращения турбины нужно приоткрыть впускной тракт номер пять ещё на тридцать процентов и соответственно скорректировать параметры клапанов, ограничивающих давление; поэтому требуется выставить ручку впуска с пятнадцати процентов на сорок пять и переключить клапана при помощи кнопок в красном секторе”. После чего уже крутил бы ручки и нажимал кнопки. Но это совсем другой подход. К тому же, реализуется он всё равно через пульт, значение которого в Новом Средневековье возрастает многократно.

Занятная особенность состоит в том, что, на практике, выдачей LLM управляет провайдер сервиса ИИ. Нельзя исключать, что этот провайдер знает все подробности об устройстве электростанции даже лучше инженера, поэтому может, в нужный момент, выдать через интерфейс ИИ подходящий набор из нажатий кнопок и вращений ручек.



Комментарии (1) »

В алгоритме ECDSA есть число, обычно обозначаемое k, которое используется при вычислении значения подписи, а именно – k определяет параметр r из пары (r,s) подписи. Значение r из этой пары необходимо для того, чтобы сошлась формула проверки. В исходном алгоритме k предлагается выбирать случайным образом (но без повторов, и держать в секрете). Дело в том, что если третья сторона знает k, то она может элементарным способом вычислить секретный ключ по сообщению с подписью; повторное использование k для разных сообщений, при прочих равных, так же приводит к раскрытию секретного ключа.

Можно встретить мнение, что такая особенность заложена в ECDSA специально (оставлено за скобками то, что такой подход использовался и в других, предшествующих ECDSA, криптосистемах). Действительно, если, например, k вычисляется по некоторому алгоритму генерирования псевдослучайных чисел “с секретом”, то если третьей стороне известны скрытые особенности данного алгоритма, эта сторона может раскрыть секретный ключ ECDSA, быстро подобрав k под открытое значение r, которое можно взять из подписи. (Это хрестоматийный теоретический подход к созданию бэкдоров методом “алгебраического разбиения”.)

Вообще, на этом направлении весьма легко ошибиться в программном коде, без всякого бэкдора. Либо подведёт аппаратура, обеспечивающая выдачу случайных значений. Либо вмешается тот или иной гипервизор – сейчас повсеместно используется виртуализация для размещения программного кода, вычисляющего ECDSA-подписи, с этим сложно что-то поделать, как и с тем, что инженеры DevOps обожают делать “снапшоты” виртуальных машин, а потом их восстанавливать (так себе решение) или множить (ещё хуже). Заметьте, кстати, что всё это полностью применимо и к современной ГОСТ-подписи – там математически эквивалентная схема.

Так что проблем с псевдослучайным параметром в ECDSA много. На практике, в алгоритм вычисления k так или иначе подмешивают дополнительные значения, не ограничиваясь лишь выдачей генератора псевдослучайных чисел. Это полумера. Однако есть и полностью детерминированный вариант (“deterministic ECDSA“), в котором значение k вычисляется для конкретного сочетания сообщения и секретного ключа (например, такой алгоритм поддерживается свежим OpenSSL 3.2).

Практика использования детерминированного варианта сопряжена с ещё одним занятным моментом. Если сообщение подписывается обычной ECDSA (или ГОСТ-подписью), то значение подписи будет каждый раз разным, даже для одного сообщения и одного подписывающего ключа. То есть, значение подписи псевдослучайное, и этот факт вполне может использоваться приложениями (хотя, вообще говоря, не должен бы). Соответственно, “фиксирование” значения подписи в таком приложении может что-то сломать. Но детерминированный вариант, конечно, всё равно лучше.



Комментировать »

На OpenNET пишут про RFC для децентрализованной системы имён GNS:

“Использование Curve25519 воспринимается некоторыми как весьма странный шаг, так как для ECDSA применяют другие типы эллиптических кривых, а в паре с Curve25519 обычно используют алгоритм цифровых подписей Ed25519, более современный, более безопасный и более быстрый, чем ECDSA. С точки зрения криптостойкости в том числе вызывает сомнение выбор размера закрытого ключа – 32 байта вместо 64 байт”

В GNS, действительно, используют ECDSA на кривой Curve25519. Это может, конечно, показаться странным. Однако алгоритм ECDSA работает в группе точек и вообще не зависит от выбора кривой (да, даже про “суперсингулярные кривые” тут есть занятные уточнения). Поэтому ничто не мешает взять Curve25519 вместо, например, более привычной P-256. Какие-то сугубо математические свойства Curve25519, типа наличия кофактора и т.п., вовсе и не являются необычными – такие кривые вполне себе подходят и для ECDSA. Так что, если нет доверия той же P-256, но нужен именно алгоритм ECDSA – можно взять Curve25519. Использование же Ed25519 в данном протоколе невозможно из-за особенностей преобразования ключей, о чём, собственно, сказано в RFC. Насчёт “более быстрого” алгоритма Ed25519 – это, в основном, определяется как раз параметрами кривой (поле и т.д.).

Что касается странного дополнения про 32-байтовый и 64-байтовый ключи: тут, наверное, что-то перепуталось на каком-то этапе пересказывания. В Ed25519 секретный ключ – 32-байтовый. И в ECDSA на P-256 (например) – тоже 32-байтовый. Потому что разрядность в 256 бит (32 байта) делает бессмысленным использование секретных ключей большей длины: всё равно значение сократится. А 64 байта – это общий размер подписи, а не ключа.

Можно предположить, что тут ещё сыграло следующее популярное заблуждение, которое нередко наблюдается в отношении SSH-ключей: многие считают, что, например, поскольку открытый ключ Ed25519 короче, чем ECDSA на той же P-256, он поэтому и менее “криптостойкий”. Действительно, для ECDSA/P-256 открытый ключ обычно записывается в 64 байта (иногда чуть меньше, иногда – чуть больше, зависит от кодирования), а в Ed25519 – только в половину, в 32 байта. Однако эти 64 байта ECDSA математически эквивалентны 32 байтам, там половина байтов приносит только один бит дополнительно: открытый ключ представляет собой точку на кривой, у точки – две координаты (X,Y), каждая по 32 байта, и вот полная форма записи ключа ECDSA подразумевает указание объединения X и Y, откуда и получается 64 байта; однако можно указывать только одну координату (X), а вторую (Y) – вычислять из уравнения кривой при необходимости. В такой схеме, для ECDSA, потребуется сохранить дополнительно знак, это один бит, и получается тоже около 32 байтов для записи открытого ключа. А вот в Ed25519 алгоритм предписывает всегда использовать только одну координату (ну, строго говоря, там есть ещё некоторые преобразования, но здесь они не важны). То есть, математически эти ключи совпадают по представлению, отличие тут чисто прикладное, поэтому дополнительные 32 байта записи для ECDSA не делают даже открытый ключ в два раза длиннее “криптографически” – он всё равно 256-битный (по разрядности кривой).



Комментировать »