Прошу прощения, у меня красиво писать не очень выходит. Я накидываю черновик - нейронка правит/причесывает мой текст, не добавляя нового. В голове много мыслей, иногда что-то сформулировать сложно…
Если сделать по Вашему интерфейсу, моя система могла бы выглядеть так (у меня по факту немного по другому):
cfaf5187-d50d-487a-bb2f-5ff42f9c6a64
Да, направление очень близкое. Мне тоже кажется, что L1 нельзя прятать внутрь “магической памяти”. Если L1 невидим, потом невозможно понять, где именно появилась ошибка: на входе, при нормализации, при извлечении факта, при допуске в память или уже при ответе?
Понимаю ваш вопрос, здесь есть небольшое смешение двух разных вещей: обсуждение идеи и решение о том, как именно мне реализовывать собственный проект. Опубликовал материал, чтобы поделиться архитектурным подходом, показать что уже работает, а что требует каких-то технических решений, получить технические вопросы, рассказать о новом видении с определенного угла процесса развития искуственного интеллекта. Но выбор реализации, дальнейшего применения и формы развития системы всё же остаётся за мной, как автором проекта. На текущем этапе она реализована в той части, которая была запланирована: как исследовательское когнитивное ядро с ограниченными режимами, проверками и внутренними границами и оно работает! Если вам сама идея Вам не кажется убедительной — это нормально, развернитесь и двигайтесь к лучшим идеям, здесь простор огромен - лучше конечно своим! Можно не принимать её, спорить с архитектурой, указывать на слабые места, предлагать альтернативы. Я готов обсуждать конкретные технические вопросы: где арбитраж, где LLM, где алгоритмический допуск, где solver, где защита от галлюцинаций. Но решать, нужен ли мне этот проект, как я буду его использовать и в каком направлении развивать, — это уже моя зона ответственности.
Хороший вопрос! Спасибо) Здесь важно не ввести в заблуждение, что в HTCE есть некий модуль, который “понимает настоящую правду” в человеческом смысле - такого арбитра нет и не должно быть! Идея HTCE не в том, что одна LLM проверяет другую LLM, а потом “понимает”, что обоснование правдивое, это было бы слабым местом. LLM может придумать факт, придумать источник, придумать объяснение и уверенно сказать, что всё сходится. Но в HTCE арбитром должен быть не “понимающий голос”, а процедура допуска, то есть система не спрашивает: “похоже ли это на правду?” Она спрашивает другое:
есть ли источник;
зафиксирован ли он;
есть ли хэш или след содержимого;
какое именно утверждение из него извлечено;
в каком контексте оно действует;
совпадает ли область применения;
есть ли уже принятое противоречащее утверждение;
какой вес у источника;
прошло ли утверждение replay;
не пытается ли пользователь, LLM или solver выдать свидетельство за истину.
Это не философский судья истины. Это инженерный арбитр допуска. Например, если приходит утверждение “объект находится в комнате А”, оно не становится знанием только потому, что LLM сказала “источник выглядит правдоподобным”. Оно должно стать записью: источник такой-то, содержимое такое-то, утверждение такое-то, область такая-то, след такой-то, статус такой-то. Если потом приходит “тот же объект находится в комнате Б” в той же области времени и контекста, система не должна выбирать красивый ответ. Она должна увидеть конфликт и отправить его в уточнение, карантин или replay. То же самое с внешним solver-ом. Если SMT-солвер сказал sat, это не значит “истина доказана”. Это значит: “в данной формальной кодировке найдена модель”. Если PDDL-валидатор сказал PASS, это не значит “план истинный”. Это значит: “данный план прошёл данную проверку на данной формальной постановке”. Поэтому внешний solver тоже не арбитр истины - он свидетель! В текущей логике HTCE роли примерно такие:
LLM помогает с языком и кандидатным разбором;
Evidence-записи фиксируют происхождение и содержимое;
Claim-записи хранят утверждения, поддержку, противоречия и статус;
Replay проверяет, выдерживает ли кандидат внутреннюю процедуру;
Discrepancy-записи фиксируют расхождение между внутренним состоянием и внешним witness;
Quarantine не даёт сомнительному утверждению попасть в активную память;
Core не принимает прямую запись истины от LLM, пользователя или solver-а.
То есть “арбитр” — это не один разумный модуль, а связка правил допуска, журналов, хэшей, replay и границ безопасности. Важно: такая система не доказывает абсолютную правду о мире. Она делает более скромную, но инженерно полезную вещь: не даёт утверждению стать защищённым знанием без проверяемого пути допуска. Если evidence нет — статус должен быть “источник отсутствует” или “нужна проверка”. Если evidence есть, но конфликтует — карантин или уточнение. Если solver подтвердил — это внешнее свидетельство, а не истина. Если LLM уверена — это вообще не аргумент для ядра. Вот как-то так)
Как Вам объяснить…сформулирую ответ так, чтобы снять главное недопонимание: в HTCE не предполагается, что “на каждом слое сидит LLM”. Профит как раз в том, что часть проверок должна быть обычным кодом, журналом, хэшами, нормализованными утверждениями и внешними решателями, а не самоотчётом модели. Что одна LLM проверяет другую LLM. Что LLM вообще не получает права записывать истину. Она работает с языком, а допуск знания должен идти через журнал, источник, проверку конфликта, след, ограниченный статус и аудит.
языковая модель должна быть только входным и выходным слоем. Она может помочь разобрать естественный язык, предложить черновой разбор запроса, переформулировать ответ для человека. Но она не должна решать, является ли факт допустимым, есть ли конфликт, можно ли записать что-то в защищённую память, можно ли принять результат решателя как истину.
что касается ресурсоёмкости, там тоже не один режим. Простые запросы должны проходить без тяжёлого решателя. Например, если факт уже принят в память и вопрос простой, это обычный поиск по принятому состоянию и выдача ответа. Здесь языковая модель может быть вообще не нужна, если вход уже нормализован. Если нужен разбор противоречий или короткая причинная цепочка, включается внутренний replay. Это дороже, но всё ещё ограниченный алгоритмический режим: пройти по сохранённым утверждениям, проверить связи, контекст и конфликт. Решатели включаются только для тяжёлых случаев. Это отдельный режим, а не постоянная часть каждого ответа.
солвер в HTCE — это не “мозг” и не “бог”, а внешний проверяющий инструмент. Он вызывается редко, по необходимости, с ограничением ресурсов. Его результат проходит через внутреннюю проверку, сравнение с evidence и обработку расхождений. Быстрые вопросы должны идти без солвера, иначе система будет непрактично медленной.
LLM может сгаллюцинировать не только сам факт, но и “обоснование” факта. Она может красиво придумать источник, уверенно сказать “конфликта нет”, неправильно интерпретировать внешний контекст или сгладить противоречие. Поэтому в HTCE принцип совершенно другой, да и строилась она для других целей.
Публичного стенда для свободного red-team тестирования пока нет. Я не хочу делать вид, что система уже готова к открытому “ломайте как хотите” режиму: для этого нужен отдельный sandbox, логирование, ограничение прав, воспроизводимые сценарии, политика disclosure и понятные метрики, что именно считается успехом атаки. Так что ответ: сейчас публично протестировать пока нельзя, не совсем готов к этому, но red-team режим нужен и будет очень полезен, надеюсь в скором времени реализую и это. Как раз хочу подготовить отдельный adversarial test pack, где проверяется не “красота ответа”, а прочность границ системы.
Да, HTCE не является общепринятым академическим сокращением в AI/Deep Learning. Более того, в литературе действительно встречается HTCE как Hierarchical Temporal Convolutions for Eye Movement Analysis — это отдельная CNN-архитектура для анализа eye movement / gaze time series. Моя статья не про эту работу и не использует это сокращение в том значении.
В моём случае HTCE — авторское название проекта:
Hierarchical Toroidal Cognitive Engine или по-русски: Иерархический тороидальный когнитивный движок.
Расшифровка такая:
Hierarchical — потому что система разделяет уровни наблюдений, evidence-memory, candidate cognition, replay, skill-chain и macro-skill.
Toroidal — потому что математическое ядро строится вокруг дискретного модульного / тороидального состояния.
Cognitive Engine — потому что это не одна LLM-модель, а runtime-архитектура для работы с памятью, доказательствами, внешними witness-инструментами, risk-tier режимами и safety-инвариантами.
То есть это не попытка сказать, что в академической среде уже есть общепринятый термин HTCE именно в таком смысле. Это рабочее имя моей архитектуры.
По ссылкам — замечание тоже принимаю. В статье нужно добавить отдельный блок “Источники и близкие направления”, чтобы было понятно, на какие существующие области я опираюсь:
PDDL — как язык спецификации planning-задач.
VAL / planning validators — как внешний planning witness.
SMT-LIB — как стандартный язык и benchmark-библиотека для SMT-солверов.
Z3 / cvc5 — как примеры SMT-солверов.
NIST AI RMF — как рамка trustworthy AI.
MDL / Minimum Description Length — как близкая идея для рассуждения о сжатии опыта.
Runtime shielding / safety envelopes — как близкая область для safety-boundary.
Спасибо, поправлю формулировку в статье: явно укажу, что HTCE в моём тексте — авторское сокращение, а не устоявшийся академический термин.
LLM в этой архитектуре — это сменный языковой фронтенд, а не само ядро системы. Она может помогать разобрать естественный язык, сформулировать ответ или предложить candidate-parse, но защищённая часть HTCE живёт отдельно: Core, AIR, evidence memory, replay, risk-tiered режимы, witness boundary, DiscrepancyRecord, запрет на прямую L2/L3 truth и т.д.
Сейчас архитектура специально сделана так, чтобы можно было подключать разные модели: локальные через LM Studio/Ollama-подобный слой, OpenAI-compatible API или вообще работать в ограниченном deterministic-режиме без LLM для простых сценариев. Ядро не должно зависеть от конкретной LLM, иначе вся идея доказательного runtime ломается.
С нуля обучать большую языковую модель сейчас не является главной целью. Главная цель — построить когнитивное ядро, которое умеет управлять знанием: отличать факт от гипотезы, видеть конфликт, проверять внешние solver-вердикты, не принимать SMT/PDDL/VAL как истину напрямую и сохранять проверяемый trace.
По бесплатному варианту: да, я хочу оставить исследовательский/Community-вариант, чтобы систему можно было запускать, изучать и проверять. Коммерческая часть, если она появится, скорее будет вокруг интеграций, поддержки, enterprise-развёртывания, интерфейсов и специализированных модулей. Сам базовый исследовательский контур я бы хотел сохранить доступным.
Принял! Спасибо! Надеюсь со временем меня начнут понимать! Да, что если скажу, что все сигнатуры существуют здесь и сейчас и принадлежат некой огромной в диапазоне n таблице ur uz с заполнением Rx? В том числе там есть значения которые никогда не будут опубликованы, но они всегда ведут к d. И мы можем получить значения r s z в любой её точке, которые будут получены по Q не зная d, но принадлежат ему? Вы меня поддержите в этом высказывании? Если Вы с этим знакомы, опишите из какого источника пожалуйста, я просто не встречал такого, может все это до меня уже было известно и мне стоит с этим всем заканчивать?! Лет 10 назад рассказывал об этом в интернет семинарах, друзья называли это «ковром Джокера».
Готов поспорить, вы ничего не знаете про распределение Rx для любого ключа d, может даже не слышали об этом! Про структуры и распределение? Не знакомо? Я принял сарказм. Вы так и останетесь на поверхности, так и не заглянув глубже!
Спасибо Вам за внимательное прочтение и конструктивную критику, она очень полезна и необходима! В одиночку трудно доводить идеи до реализации. Вы совершенно правы в том, что предложенная в TorusCSIDH «геометрическая защита» не опирается на классическую редукцию к известной трудной задаче и, следовательно, не может претендовать на статус доказуемо безопасной в смысле теоретической криптографии.
Однако здесь важно различать цель и метод. Наша задача — не заменить алгебраическую основу CSIDH, а дополнить её практическим механизмом фильтрации входных данных, который предотвращает целый класс атак, не связанных с решением задачи изогенного действия как таковой. Такие атаки (например, подача кривой вне орбиты базовой точки или искусственное удлинение пути) эксплуатируют отсутствие валидации структуры входа, а не слабости самой криптосхемы. Но, можно и еще подумать над этой реализацией…
граф имеет тороидальную структуру с диагональными связями наклона -d.
-Как именно это проверить?
Ответ: Очень просто, весь ответ в формуле k=ur*d+uz mod n, если в таблице (матрице) не менять uz=const, а изменить ur+1 наследующей строчке все значения k сместятся на величину d, это и порождает наклон таблицы (паттерны). Я очень рад, что Вам это интересно, по мере возможности постараюсь Вам всё объяснить, это очень интересно, думаю Вы уже начинаете понимать суть таблицы.
Как строится таблица: мы имеем публичный ключ Q, базовую точку G, нам необходимо для начала посчитать r=Rx. R(x,y)=urQ(x,y)+uzG(x,y), провели действия над точками на кривой и получили r. Для заполнения таблицы ur и uz от 1 до n. Даже не валидные области необходимо заполнить ( Есть точки в таблице которые никогда не опубликуются в сети, это точки где Rx=0 - они сразу дают решение по d). Да, мы никогда не заполним всю таблицу nxn, но можно использовать адаптивный метод поиска тех же повторов значений Rx.
Вопрос: для каких целей это Вам нужно? Если для анализа и аудита, то мы сможем построить интересный алгоритм способный «подсказывать» области таблицы на которые необходимо обратить внимание. Все сигнатуры для любого публичного ключа в своей таблице уже существуют, не зависимо от того знаем мы об этом или нет, можно проверить от обратного, лишь многие пока не опубликованы в сети.
И самое важно: любой участок таблицы самоподобен полной таблице, ведь заполнение значениями k идёт по формуле и выглядит так, например для d=2: 2 3 4….n-2 4 5 6 … n-4 6 7 8 … n-6 … И тд. Все смещения строк сохранены даже для малой выборки. Так же из таблицы мы понимаем, что при ur=const и изменение uz на значение i => k меняется на такое же значение i. … много свойст интересных, нужно изучать.
Вы можете самостоятельно для малого модуля построить и проанализировать ее. Из-за свойств модуля можно соединить противоположные края таблицы и вы получите тор. -проверить зеркальную симметрию можно следующим способом: У вас есть сигнатуры (из сети или искусственно полученные), преобразуйте r s z в ur uz. ur=r/s mod n; uz=z/s mod n. Чтобы получить такой же Rx но с другим Ry: R(x,y)=(-ur)Q(x, y) (-uz)* G(x,y); из R(x, y) берем r; s2=r/(-ur) mod n; z2=s2*(-uz) mod n. Всё, вы получили r s2 z2
Этот комментарий справедлив в том смысле, что одно лишь наблюдение регулярной структурыне является атакой — это диагностический инструмент, а не прямой метод восстановления секретного ключа. Однако он указывает на важный принцип: топологическая структура ECDSA-подписей — это не "случайность", а детерминированное следствие линейного соотношения . Она существует всегда, даже при идеально случайной генерации , и может быть использована для обнаружения отклонений от этой идеальной структуры, которые и являются признаками уязвимости.
Ниже я приведу конкретный алгоритм, его условия применимости, и объясню, почему анализ области всё же полезен, несмотря на то, что он не делает "малым".
Практический алгоритм: Топологически-усиленная диагностика реализации ECDSA
Условия применимости:
У вас есть набор подписей (из сети, можно добавить сгенерированных искусственно) от одного и того же секретного ключа .
Генерация может быть не полностью случайной — например:
Используется некачественный RNG (например, с низкой энтропией),
Или частично известно (например, младшие биты утечены),
Или используется детерминированный ECDSA (RFC 6979), но с неправильной реализацией хеширования.
Количество подписей достаточно для статистического анализа ( для начального анализа).
Алгоритм
Шаг 1. Преобразование подписей в
Для каждой подписи вычислите:
Шаг 2. Топологическая фильтрация (Mapper)
Определите фильтрующую функцию: .
Разбейте диапазон значений на интервалов.
В каждом интервале выполните кластеризацию (например, DBSCAN или HDBSCAN) точек .
Ожидаемый результат при корректной реализации: граф имеет тороидальную структуру с диагональными связями наклона . Это не "случайное облако", а строго упорядоченная сетка параллельных линий, как показано в таблице для .
Шаг 3. Обнаружение аномалий через симметрию и самоподобие
Здесь ключевое уточнение: анализ среза — это не про малые , а про проверку фундаментальных свойств структуры.
Проверка центральной симметрии: Для каждой точки проверьте, существует ли в наборе точка . Если таких пар нет или их мало, это признак ошибки в реализации (например, неверная работа с отрицательными числами по модулю ). Как вы верно заметили, в идеальной реализации должно выполняться .
Проверка самоподобия: Сравните распределение точек в первой четверти со второй, третьей и четвёртой. Структура диагональных линий должна быть одинаковой во всех четырёх четвертях (самоподобие), хотя конкретные значения будут разными.
Персистентная гомология: Анализируйте топологические инварианты (числа Бетти ). Для корректной реализации ожидается . Отклонения указывают на проблемы: — повторение ; — линейная зависимость ; — смещенный RNG.
Шаг 4. Применение решётчатых атак при наличии дополнительной информации
Если после топологического анализа вы обнаружили, что лежит в узком диапазоне (например, , где ), или что разности малы, тогда применяется решётчатая атака:
Соберите уравнений:
Поскольку имеют ограниченный диапазон или малые разности, можно построить решётку и применить LLL-алгоритм для нахождения короткого вектора, который даст .
Сложность: Решётчатая атака эффективна, когда разность между мала или когда лежит в узком диапазоне. Просто ограничение не даёт преимущества — нужна дополнительная информация о структуре , которую и помогает найти топологический анализ.
Почему анализ всё же полезен?
Вы не правы: это не "несерьёзно" и не "отбрасывание двух битов". Это стратегически важный шаг.
Не про малые : Да, если все лежат в , они всё ещё огромны (порядка для secp256k1). Это не "малое значение" для решётки.
Про проверку фундаментальных свойств: Этот срез позволяет:
Проверить симметрию: Наличие или отсутствие пар и в этом срезе — прямой тест на корректность реализации.
Проверить самоподобие: Сравнивая плотность и форму паттернов в первой четверти с другими, можно выявить аномалии, которые могут быть скрыты в общем виде тора.
Локализовать аномалии: Если топологический анализ (Mapper, персистентная гомология) показывает проблему, срез помогает сузить область поиска. Например, если в этой области наблюдается аномально высокая плотность точек или искажение диагональных линий, это указывает на то, что RNG генерирует из ограниченного подпространства, которое частично попадает в этот срез.
Адаптивное зондирование: Как описано в статье, можно использовать этот срез как отправную точку для генерации искусственных подписей и "зондирования" пространства в поисках скрытых кластеров.
Вывод
Эта статья не предлагает прямую атаку, а демонстрирует универсальный метод диагностики реализации ECDSA. Это практически ценно:
Аудиторы могут визуально или автоматически проверить корректность генерации .
При обнаружении аномалий можно перейти к целенаправленной атаке (решётка, Coppersmith и т.д.).
Метод работает даже при малом числе подписей, если структура нарушена.
И главное уточнение: Анализ среза — это не про "малые ", а про проверку фундаментальных математических свойств структуры — центральной симметрии и самоподобия четвертей. Именно эти свойства должны соблюдаться в любой корректной реализации. Любое их нарушение — это потенциальная уязвимость, которую можно затем исследовать более глубоко.
Вы сначала разберитесь, а потом пишите о срезании 2 бит. В правой части таблицы - симметрия, можете попробовать ur uz и -ur -uz получите одинаковый Rx, вторая четверть - самоподобна первой. Какие биты???
А вот здесь - большой, большой секрет! Не могу же я сразу все алгоритмы расскрывать)
Прошу прощения, у меня красиво писать не очень выходит. Я накидываю черновик - нейронка правит/причесывает мой текст, не добавляя нового. В голове много мыслей, иногда что-то сформулировать сложно…
Если сделать по Вашему интерфейсу, моя система могла бы выглядеть так (у меня по факту немного по другому):
Да, направление очень близкое. Мне тоже кажется, что L1 нельзя прятать внутрь “магической памяти”. Если L1 невидим, потом невозможно понять, где именно появилась ошибка: на входе, при нормализации, при извлечении факта, при допуске в память или уже при ответе?
А вот это уже интересней! Готов к диалогу)
Понимаю ваш вопрос, здесь есть небольшое смешение двух разных вещей: обсуждение идеи и решение о том, как именно мне реализовывать собственный проект. Опубликовал материал, чтобы поделиться архитектурным подходом, показать что уже работает, а что требует каких-то технических решений, получить технические вопросы, рассказать о новом видении с определенного угла процесса развития искуственного интеллекта. Но выбор реализации, дальнейшего применения и формы развития системы всё же остаётся за мной, как автором проекта. На текущем этапе она реализована в той части, которая была запланирована: как исследовательское когнитивное ядро с ограниченными режимами, проверками и внутренними границами и оно работает! Если вам сама идея Вам не кажется убедительной — это нормально, развернитесь и двигайтесь к лучшим идеям, здесь простор огромен - лучше конечно своим! Можно не принимать её, спорить с архитектурой, указывать на слабые места, предлагать альтернативы. Я готов обсуждать конкретные технические вопросы: где арбитраж, где LLM, где алгоритмический допуск, где solver, где защита от галлюцинаций. Но решать, нужен ли мне этот проект, как я буду его использовать и в каком направлении развивать, — это уже моя зона ответственности.
Хороший вопрос! Спасибо) Здесь важно не ввести в заблуждение, что в HTCE есть некий модуль, который “понимает настоящую правду” в человеческом смысле - такого арбитра нет и не должно быть! Идея HTCE не в том, что одна LLM проверяет другую LLM, а потом “понимает”, что обоснование правдивое, это было бы слабым местом. LLM может придумать факт, придумать источник, придумать объяснение и уверенно сказать, что всё сходится. Но в HTCE арбитром должен быть не “понимающий голос”, а процедура допуска, то есть система не спрашивает: “похоже ли это на правду?” Она спрашивает другое:
есть ли источник;
зафиксирован ли он;
есть ли хэш или след содержимого;
какое именно утверждение из него извлечено;
в каком контексте оно действует;
совпадает ли область применения;
есть ли уже принятое противоречащее утверждение;
какой вес у источника;
прошло ли утверждение replay;
не пытается ли пользователь, LLM или solver выдать свидетельство за истину.
Это не философский судья истины. Это инженерный арбитр допуска. Например, если приходит утверждение “объект находится в комнате А”, оно не становится знанием только потому, что LLM сказала “источник выглядит правдоподобным”. Оно должно стать записью: источник такой-то, содержимое такое-то, утверждение такое-то, область такая-то, след такой-то, статус такой-то. Если потом приходит “тот же объект находится в комнате Б” в той же области времени и контекста, система не должна выбирать красивый ответ. Она должна увидеть конфликт и отправить его в уточнение, карантин или replay. То же самое с внешним solver-ом. Если SMT-солвер сказал sat, это не значит “истина доказана”. Это значит: “в данной формальной кодировке найдена модель”. Если PDDL-валидатор сказал PASS, это не значит “план истинный”. Это значит: “данный план прошёл данную проверку на данной формальной постановке”. Поэтому внешний solver тоже не арбитр истины - он свидетель! В текущей логике HTCE роли примерно такие:
LLM помогает с языком и кандидатным разбором;
Evidence-записи фиксируют происхождение и содержимое;
Claim-записи хранят утверждения, поддержку, противоречия и статус;
Replay проверяет, выдерживает ли кандидат внутреннюю процедуру;
Discrepancy-записи фиксируют расхождение между внутренним состоянием и внешним witness;
Quarantine не даёт сомнительному утверждению попасть в активную память;
Core не принимает прямую запись истины от LLM, пользователя или solver-а.
То есть “арбитр” — это не один разумный модуль, а связка правил допуска, журналов, хэшей, replay и границ безопасности. Важно: такая система не доказывает абсолютную правду о мире. Она делает более скромную, но инженерно полезную вещь: не даёт утверждению стать защищённым знанием без проверяемого пути допуска. Если evidence нет — статус должен быть “источник отсутствует” или “нужна проверка”. Если evidence есть, но конфликтует — карантин или уточнение. Если solver подтвердил — это внешнее свидетельство, а не истина. Если LLM уверена — это вообще не аргумент для ядра. Вот как-то так)
Как Вам объяснить…сформулирую ответ так, чтобы снять главное недопонимание: в HTCE не предполагается, что “на каждом слое сидит LLM”. Профит как раз в том, что часть проверок должна быть обычным кодом, журналом, хэшами, нормализованными утверждениями и внешними решателями, а не самоотчётом модели. Что одна LLM проверяет другую LLM. Что LLM вообще не получает права записывать истину. Она работает с языком, а допуск знания должен идти через журнал, источник, проверку конфликта, след, ограниченный статус и аудит.
языковая модель должна быть только входным и выходным слоем. Она может помочь разобрать естественный язык, предложить черновой разбор запроса, переформулировать ответ для человека. Но она не должна решать, является ли факт допустимым, есть ли конфликт, можно ли записать что-то в защищённую память, можно ли принять результат решателя как истину.
что касается ресурсоёмкости, там тоже не один режим. Простые запросы должны проходить без тяжёлого решателя. Например, если факт уже принят в память и вопрос простой, это обычный поиск по принятому состоянию и выдача ответа. Здесь языковая модель может быть вообще не нужна, если вход уже нормализован. Если нужен разбор противоречий или короткая причинная цепочка, включается внутренний replay. Это дороже, но всё ещё ограниченный алгоритмический режим: пройти по сохранённым утверждениям, проверить связи, контекст и конфликт. Решатели включаются только для тяжёлых случаев. Это отдельный режим, а не постоянная часть каждого ответа.
солвер в HTCE — это не “мозг” и не “бог”, а внешний проверяющий инструмент. Он вызывается редко, по необходимости, с ограничением ресурсов. Его результат проходит через внутреннюю проверку, сравнение с evidence и обработку расхождений. Быстрые вопросы должны идти без солвера, иначе система будет непрактично медленной.
LLM может сгаллюцинировать не только сам факт, но и “обоснование” факта. Она может красиво придумать источник, уверенно сказать “конфликта нет”, неправильно интерпретировать внешний контекст или сгладить противоречие. Поэтому в HTCE принцип совершенно другой, да и строилась она для других целей.
Спасибо, это как раз очень правильный вопрос.
Публичного стенда для свободного red-team тестирования пока нет. Я не хочу делать вид, что система уже готова к открытому “ломайте как хотите” режиму: для этого нужен отдельный sandbox, логирование, ограничение прав, воспроизводимые сценарии, политика disclosure и понятные метрики, что именно считается успехом атаки. Так что ответ: сейчас публично протестировать пока нельзя, не совсем готов к этому, но red-team режим нужен и будет очень полезен, надеюсь в скором времени реализую и это. Как раз хочу подготовить отдельный adversarial test pack, где проверяется не “красота ответа”, а прочность границ системы.
Спасибо за замечание, оно справедливое.
Да, HTCE не является общепринятым академическим сокращением в AI/Deep Learning. Более того, в литературе действительно встречается HTCE как Hierarchical Temporal Convolutions for Eye Movement Analysis — это отдельная CNN-архитектура для анализа eye movement / gaze time series. Моя статья не про эту работу и не использует это сокращение в том значении.
В моём случае HTCE — авторское название проекта:
Hierarchical Toroidal Cognitive Engine или по-русски: Иерархический тороидальный когнитивный движок.
Расшифровка такая:
Hierarchical — потому что система разделяет уровни наблюдений, evidence-memory, candidate cognition, replay, skill-chain и macro-skill.
Toroidal — потому что математическое ядро строится вокруг дискретного модульного / тороидального состояния.
Cognitive Engine — потому что это не одна LLM-модель, а runtime-архитектура для работы с памятью, доказательствами, внешними witness-инструментами, risk-tier режимами и safety-инвариантами.
То есть это не попытка сказать, что в академической среде уже есть общепринятый термин HTCE именно в таком смысле. Это рабочее имя моей архитектуры.
По ссылкам — замечание тоже принимаю. В статье нужно добавить отдельный блок “Источники и близкие направления”, чтобы было понятно, на какие существующие области я опираюсь:
PDDL — как язык спецификации planning-задач.
VAL / planning validators — как внешний planning witness.
SMT-LIB — как стандартный язык и benchmark-библиотека для SMT-солверов.
Z3 / cvc5 — как примеры SMT-солверов.
NIST AI RMF — как рамка trustworthy AI.
MDL / Minimum Description Length — как близкая идея для рассуждения о сжатии опыта.
Runtime shielding / safety envelopes — как близкая область для safety-boundary.
Спасибо, поправлю формулировку в статье: явно укажу, что HTCE в моём тексте — авторское сокращение, а не устоявшийся академический термин.
Опубликовал после того как протестировал систему.
LLM в этой архитектуре — это сменный языковой фронтенд, а не само ядро системы. Она может помогать разобрать естественный язык, сформулировать ответ или предложить candidate-parse, но защищённая часть HTCE живёт отдельно: Core, AIR, evidence memory, replay, risk-tiered режимы, witness boundary, DiscrepancyRecord, запрет на прямую L2/L3 truth и т.д.
То есть схема такая:
LLM proposes HTCE verifies / rejects / quarantines / answers
Сейчас архитектура специально сделана так, чтобы можно было подключать разные модели: локальные через LM Studio/Ollama-подобный слой, OpenAI-compatible API или вообще работать в ограниченном deterministic-режиме без LLM для простых сценариев. Ядро не должно зависеть от конкретной LLM, иначе вся идея доказательного runtime ломается.
С нуля обучать большую языковую модель сейчас не является главной целью. Главная цель — построить когнитивное ядро, которое умеет управлять знанием: отличать факт от гипотезы, видеть конфликт, проверять внешние solver-вердикты, не принимать SMT/PDDL/VAL как истину напрямую и сохранять проверяемый trace.
По бесплатному варианту: да, я хочу оставить исследовательский/Community-вариант, чтобы систему можно было запускать, изучать и проверять. Коммерческая часть, если она появится, скорее будет вокруг интеграций, поддержки, enterprise-развёртывания, интерфейсов и специализированных модулей. Сам базовый исследовательский контур я бы хотел сохранить доступным.
Принял! Спасибо! Надеюсь со временем меня начнут понимать! Да, что если скажу, что все сигнатуры существуют здесь и сейчас и принадлежат некой огромной в диапазоне n таблице ur uz с заполнением Rx? В том числе там есть значения которые никогда не будут опубликованы, но они всегда ведут к d. И мы можем получить значения r s z в любой её точке, которые будут получены по Q не зная d, но принадлежат ему? Вы меня поддержите в этом высказывании? Если Вы с этим знакомы, опишите из какого источника пожалуйста, я просто не встречал такого, может все это до меня уже было известно и мне стоит с этим всем заканчивать?! Лет 10 назад рассказывал об этом в интернет семинарах, друзья называли это «ковром Джокера».
Готов поспорить, вы ничего не знаете про распределение Rx для любого ключа d, может даже не слышали об этом! Про структуры и распределение? Не знакомо? Я принял сарказм. Вы так и останетесь на поверхности, так и не заглянув глубже!
Спасибо Вам за внимательное прочтение и конструктивную критику, она очень полезна и необходима! В одиночку трудно доводить идеи до реализации. Вы совершенно правы в том, что предложенная в TorusCSIDH «геометрическая защита» не опирается на классическую редукцию к известной трудной задаче и, следовательно, не может претендовать на статус доказуемо безопасной в смысле теоретической криптографии.
Однако здесь важно различать цель и метод. Наша задача — не заменить алгебраическую основу CSIDH, а дополнить её практическим механизмом фильтрации входных данных, который предотвращает целый класс атак, не связанных с решением задачи изогенного действия как таковой. Такие атаки (например, подача кривой вне орбиты базовой точки или искусственное удлинение пути) эксплуатируют отсутствие валидации структуры входа, а не слабости самой криптосхемы. Но, можно и еще подумать над этой реализацией…
-Как именно это проверить?
Ответ: Очень просто, весь ответ в формуле k=ur*d+uz mod n, если в таблице (матрице) не менять uz=const, а изменить ur+1 наследующей строчке все значения k сместятся на величину d, это и порождает наклон таблицы (паттерны).
Я очень рад, что Вам это интересно, по мере возможности постараюсь Вам всё объяснить, это очень интересно, думаю Вы уже начинаете понимать суть таблицы.
Как строится таблица: мы имеем публичный ключ Q, базовую точку G, нам необходимо для начала посчитать r=Rx. R(x,y)=urQ(x,y)+uzG(x,y), провели действия над точками на кривой и получили r. Для заполнения таблицы ur и uz от 1 до n. Даже не валидные области необходимо заполнить ( Есть точки в таблице которые никогда не опубликуются в сети, это точки где Rx=0 - они сразу дают решение по d).
Да, мы никогда не заполним всю таблицу nxn, но можно использовать адаптивный метод поиска тех же повторов значений Rx.
Вопрос: для каких целей это Вам нужно? Если для анализа и аудита, то мы сможем построить интересный алгоритм способный «подсказывать» области таблицы на которые необходимо обратить внимание. Все сигнатуры для любого публичного ключа в своей таблице уже существуют, не зависимо от того знаем мы об этом или нет, можно проверить от обратного, лишь многие пока не опубликованы в сети.
И самое важно: любой участок таблицы самоподобен полной таблице, ведь заполнение значениями k идёт по формуле и выглядит так, например для d=2:
2 3 4….n-2
4 5 6 … n-4
6 7 8 … n-6
…
И тд. Все смещения строк сохранены даже для малой выборки. Так же из таблицы мы понимаем, что при ur=const и изменение uz на значение i => k меняется на такое же значение i. … много свойст интересных, нужно изучать.
Отвечу пока на основные вопросы, потому, что нахожусь не в теплом кресле как вы, буду отвечать по возможности:
-таблица всех возможных значений Rx для приватного ключа d для mod 79
Вы можете самостоятельно для малого модуля построить и проанализировать ее. Из-за свойств модуля можно соединить противоположные края таблицы и вы получите тор.
-проверить зеркальную симметрию можно следующим способом:
У вас есть сигнатуры (из сети или искусственно полученные), преобразуйте r s z в ur uz. ur=r/s mod n; uz=z/s mod n. Чтобы получить такой же Rx но с другим Ry: R(x,y)=(-ur)Q(x, y) (-uz)* G(x,y); из R(x, y) берем r; s2=r/(-ur) mod n; z2=s2*(-uz) mod n. Всё, вы получили r s2 z2
Этот комментарий справедлив в том смысле, что одно лишь наблюдение регулярной структуры
не является атакой — это диагностический инструмент, а не прямой метод восстановления секретного ключа. Однако он указывает на важный принцип: топологическая структура ECDSA-подписей — это не "случайность", а детерминированное следствие линейного соотношения 
. Она существует всегда, даже при идеально случайной генерации 
, и может быть использована для обнаружения отклонений от этой идеальной структуры, которые и являются признаками уязвимости.
Ниже я приведу конкретный алгоритм, его условия применимости, и объясню, почему анализ области![U_r, U_z \in [1, n/4]](https://habrastorage.org/getpro/habr/formulas/6/6b/6b5/6b5dedb5bd15ae885fa0c4b7439925f3.svg)
всё же полезен, несмотря на то, что он не делает 
"малым".
Практический алгоритм: Топологически-усиленная диагностика реализации ECDSA
Условия применимости:
У вас есть набор подписей (из сети, можно добавить сгенерированных искусственно)
от одного и того же секретного ключа 
.
Генерация
может быть не полностью случайной — например:
Используется некачественный RNG (например, с низкой энтропией),
Или
частично известно (например, младшие биты утечены),
Или используется детерминированный ECDSA (RFC 6979), но с неправильной реализацией хеширования.
Количество подписей
достаточно для статистического анализа (
для начального анализа).
Алгоритм
Шаг 1. Преобразование подписей в
Для каждой подписи вычислите:
Шаг 2. Топологическая фильтрация (Mapper)
Определите фильтрующую функцию:
.
Разбейте диапазон значений
на 
интервалов.
В каждом интервале выполните кластеризацию (например, DBSCAN или HDBSCAN) точек
.
Постройте Mapper-граф: вершины = кластеры, рёбра = пересечения.
Шаг 3. Обнаружение аномалий через симметрию и самоподобие
Здесь ключевое уточнение: анализ среза![[1, n/4]](https://habrastorage.org/getpro/habr/formulas/1/11/11c/11c5e12b06ea9090d11fcd3f7702af71.svg)
— это не про малые 
, а про проверку фундаментальных свойств структуры.
Проверка центральной симметрии: Для каждой точки
проверьте, существует ли в наборе точка 
. Если таких пар нет или их мало, это признак ошибки в реализации (например, неверная работа с отрицательными числами по модулю 
). Как вы верно заметили, в идеальной реализации должно выполняться 
.
Проверка самоподобия: Сравните распределение точек в первой четверти![(U_r, U_z \in [1, n/4])](https://habrastorage.org/getpro/habr/formulas/7/7e/7e1/7e11f17a2ee4af2ce9d04004f403ba9b.svg)
со второй, третьей и четвёртой. Структура диагональных линий должна быть одинаковой во всех четырёх четвертях (самоподобие), хотя конкретные значения 
будут разными.
Персистентная гомология: Анализируйте топологические инварианты (числа Бетти
). Для корректной реализации ожидается 
. Отклонения указывают на проблемы: 
— повторение 
; 
— линейная зависимость 
; 
— смещенный RNG.
Шаг 4. Применение решётчатых атак при наличии дополнительной информации
Если после топологического анализа вы обнаружили, что
лежит в узком диапазоне (например, ![k_i \in [A, A+B]](https://habrastorage.org/getpro/habr/formulas/e/e8/e8e/e8e2505c5c25db17e910c6cafb288aee.svg)
, где 
), или что разности 
малы, тогда применяется решётчатая атака:
Соберите
уравнений:
Поскольку
имеют ограниченный диапазон или малые разности, можно построить решётку и применить LLL-алгоритм для нахождения короткого вектора, который даст 
.
Почему анализ![U_r, U_z \in [1, n/4]](https://habrastorage.org/getpro/habr/formulas/6/6b/6b5/6b5dedb5bd15ae885fa0c4b7439925f3.svg)
всё же полезен?
Вы не правы: это не "несерьёзно" и не "отбрасывание двух битов". Это стратегически важный шаг.
Не про малые
: Да, если все 
лежат в ![[1, n/4]](https://habrastorage.org/getpro/habr/formulas/1/11/11c/11c5e12b06ea9090d11fcd3f7702af71.svg)
, они всё ещё огромны (порядка 
для secp256k1). Это не "малое значение" для решётки.
Про проверку фундаментальных свойств: Этот срез позволяет:
Проверить симметрию: Наличие или отсутствие пар
и 
в этом срезе — прямой тест на корректность реализации.
Проверить самоподобие: Сравнивая плотность и форму паттернов в первой четверти с другими, можно выявить аномалии, которые могут быть скрыты в общем виде тора.
Локализовать аномалии: Если топологический анализ (Mapper, персистентная гомология) показывает проблему, срез![[1, n/4]](https://habrastorage.org/getpro/habr/formulas/1/11/11c/11c5e12b06ea9090d11fcd3f7702af71.svg)
помогает сузить область поиска. Например, если в этой области наблюдается аномально высокая плотность точек или искажение диагональных линий, это указывает на то, что RNG генерирует 
из ограниченного подпространства, которое частично попадает в этот срез.
Адаптивное зондирование: Как описано в статье, можно использовать этот срез как отправную точку для генерации искусственных подписей и "зондирования" пространства в поисках скрытых кластеров.
Вывод
Эта статья не предлагает прямую атаку, а демонстрирует универсальный метод диагностики реализации ECDSA. Это практически ценно:
Аудиторы могут визуально или автоматически проверить корректность генерации
.
При обнаружении аномалий можно перейти к целенаправленной атаке (решётка, Coppersmith и т.д.).
Метод работает даже при малом числе подписей, если структура нарушена.
И главное уточнение: Анализ среза![[1, n/4]](https://habrastorage.org/getpro/habr/formulas/1/11/11c/11c5e12b06ea9090d11fcd3f7702af71.svg)
— это не про "малые 
", а про проверку фундаментальных математических свойств структуры 
— центральной симметрии и самоподобия четвертей. Именно эти свойства должны соблюдаться в любой корректной реализации. Любое их нарушение — это потенциальная уязвимость, которую можно затем исследовать более глубоко.
Вы сначала разберитесь, а потом пишите о срезании 2 бит. В правой части таблицы - симметрия, можете попробовать ur uz и -ur -uz получите одинаковый Rx, вторая четверть - самоподобна первой. Какие биты???