Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ.
Нет. Достаточно перехватить на этапе обращения к авторитативному серверу. Пункт 3 в вашем списке - "[DNS resolvers] -> [ Authorative DNS ]". Авторитативных серверов может быть несколько, но не факт, что УЦ и опрашивает несколько, сравнивая ответы. Как я и написал выше, если нет DNSSEC, то здесь полностью аналогичная HTTP схема: HTTP-узлов так же может быть несколько, они могут быть "в AWS", "в облаке" и т.д.
(Отмечу ещё раз, что, конечно, проверка через DNS, в целом, это существенно более надёжный вариант. Но для стороны УЦ, а не с точки зрения перехвата на уровне провайдера.)
Фактически он предлагает параллельно строить ещё одну сеть доверия
Так DNS уже построена. DANE - базируется на DNS. DANE вообще весьма хорошая, архитектурно, технология. Такое редко встречается в этих интернетах.
причём на базе технологии которая для этого изначально не была предназначена.
DNS - это распределённая БД, хранить там, вообще говоря, позволяется что угодно. Есть SSHFP и пр., скажем. Относительно новая часть, необходимая для DANE - DNSSEC - это да, это такая хрупкая пристройка-надстройка. Но, всё ж, она и предложена-то, буквально, для того, чтобы удостоверять значение записей. Другое дело, что с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень.
Да, с DANE не сложилось - заменили на Certificate Transparency. (Кстати, единственный способ, который мог бы как-то заметно повлиять на исходную ситуацию с подменой сертификата - это сравнение отпечатков ключей клиентом.)
В режиме Must-Staple нагрузка на их резолвер становится почти никакой.
Это если считать, что весь трафик - строго штатный. К сожалению, в интернетах это не так. При этом stapling никак не отменяет требований по доступности OCSP-респондера: респондер всё равно должен быть выставлен наружу и быть готов обсуживать огромный поток запросов - иначе начнёт отваливаться и stapling.
Вообще, там всё несколько сложнее. Балансировка нагрузки с HTTP (например) - это только одна часть. Но для того, чтобы поддерживать OCSP-респондер, нужно ещё вести внутри УЦ большую базу актуальных статусов сертификатов - не так, как с CRL. Эта база активно раздувается, что, однако, не должно мешать успешной привязке к респондеру. Ответы респондера - нужно подписывать (не так, как CRL), а для этого требуется организовать более или менее безопасную работу с ключами. В практике УЦ - это всё очень затратные и сложные, с инженерной точки зрения, операции и процессы.
И никакой блокировки для клиентов в итоге - вся проверка идёт локально.
Это верно, но только если у сервера всё ещё есть валидный OCSP-ответ, то да. Если OCSP-респондер упал, то уже нет. Когда УЦ обслуживает сотни миллионов сайтов - сложно угадать, в какой момент какой сервер придёт за OCSP-ответом.
Я не нашел в открытых источниках запрета на использование в качестве закрытого ключа (p-1)/2
В мультипликативном DH (FFDH) давно есть типовое требование: использовать для алгоритма циклическую подгруппу (простого) порядка (p-1)/2. Это то же самое. См., например, RFC 7919 (группы FFDH для TLS) или документы NIST 800.
Но тут, конечно, как всегда вопрос баланса безопасности и сложности
Да. И пока все обсуждают "сверхразумный ИИ" - TLS-сертфикаты для веба, ловким движением, превращаются в безотзывные короткоживущие токены, типа Kerberos, только в другую сторону: чтобы к вашему ресурсу было разрешено подключаться клиентам - нужно в онлайн-режиме серверу получать подтверждающий токен в центре сертификации. https://habr.com/ru/posts/900692/
Мягко говоря, OCSP - не очень хороший протокол, и так себе технология. Про "приватность" - это верно, но вовсе не является критически важным моментом для УЦ. Причина отказа со стороны УЦ в том, что наслаивается огромная куча проблем с поддержкой высоконагруженного транзакционного онлайн-сервиса, который, при разумном использовании, оказывается блокирующим для клиентов, проверяющих сертификаты. И представьте, что нужно выпускать миллионы сертификатов в месяц.
OCSP как раз правильно, что убрали. Насчёт CRL - вопрос спорный, но что уж поделать.
Так Certificate Revocation Lists никуда не уходят вроде бы
Уходит всё вместе, и CRL тоже. Отзыв в браузерах давно не работает фактически, а со сверхкороткими сертификатами - официально убирают совсем: "Our six-day certificates will not include OCSP or CRL URLs". В требованиях CA/B-форума - тоже достаточно давно убрали.
Certificate Transparency и прочий мониторинг - это, без сомнения, хорошо и полезно, но работает постфактум и не предотвращает выпуск подменного сертификата и, технически, никак не мешает использованию такого сертификата.
Сейчас вот перейдут на TLS-сертификаты без информации о способе проверки статуса, - то есть, без отзыва, - и даже чисто формальной возможности отозвать неверный сертификат, кроме как через обновление браузера, не останется. А клиенты с доверием TLS-сертификатам - это не только браузеры.
Закрывает, но только для себя, а не для домена. Есть другие УЦ, ключам которых верят браузеры. Валидный сертификат для подмены можно выпустить от любого из них.
Но в случае перехвата DNS это надо делать между CA и DNS.
А в случае HTTP - между системами CA и веб-сервером. То есть, с точки зрения подключения, то же самое.
(Например между Azure DNS и LE). Как мне кажется это намного сложнее сделать чем перехватить трафик на уровне хостера.
Так и Azure - это тоже хостер. Пусть, в данном случае, DNS-хостер.
В принципе, для DNS может потребоваться более сложная схема, но вовсе необязательно она более сложная. Например, в DNS, обычно, несколько узлов (серверов имён) - однако далеко не факт, что сервис проверки DNS УЦ проверяет несколько ответов (от нескольких узлов). В DNS базовый транспорт - UDP. Далеко не факт, что сервис проверки УЦ подключается по TCP (а это, в данном случае, необходимо делать). И т.д., и т.п. Let's Encrypt, например, из-за требований ACME вообще следует CNAME - что, вэтомслучае, делать нельзя в принципе, так как это сильно увеличивает реальную поверхность атаки.
То есть, у DNS свои особенности, это факт. Я бы считал, что, в целом, универсальныйперехват тут действительно сложнее - DNS вообще очень сложная система. Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостеров (см. рекурсивный опрос и CNAME).
При этом, в теории, HTTP-доступ тоже может оказаться устроен сильно сложнее базового варианта: тоже может быть много узлов, какой-нибудь навороченный anycast с десятком балансировщиков и т.д. Проверяет ли всё это система УЦ? Я бы предположил, что далеко не всегда проверяет.
ограничение валидации методом dns-01 (который требует внесения изменений в DNS-зону, а не контроля над трафиком)
Это не совсем верно: контроль над трафиком DNS-сервера позволяет "внести" любые изменения в ответы - для клиента это будет эквивалентно внесению изменений в зону. То есть, точка атаки просто переносится на DNS-серверы. UDP даже может быть проще подменить - типа, просто ответить раньше и т.д. (Это всё по модулю DNSSEC, конечно.)
сделало бы атаку значительно сложнее
Насчёт "значительно" - тут как повезёт: точно сложнее было бы в том случае, если авторитативных серверов много, их точки подключения распределены по Интернету, а система УЦ проверяет DNS тоже из нескольких точек и обращаясь ко многим авторитативным серверам. Это не всегда так.
а использование DNSSEC доменом могло бы сделать её вовсе невозможной.
Это при условии, что УЦ корректно проверяет DNSSEC-подписи по всей цепочке. Let's Encrypt, вроде, сейчас проверяют. Однако достаточно найти УЦ, который не проверяет - это позволит "подменить" записи в ответах, перехватив DNS-трафик (см. выше).
Поэтому здесь либо мошенничество, либо утечка засекреченной информации.
Либо рядовое накручивание хайпа типовыми методами массмедиа: "секретная встреча", "вы всё равно не поймёте", "приборы не покажем, но там ого-го!", "придёт время -- все ахнут!" и т.д.
Вот, кстати, человек пишет, что он участвовал в упомянутом "симпозиуме" в качестве приглашённого специалиста, и что некоторые моменты в публикации "несколько преувеличены". По ссылке есть и пример задачи, для которой LLM даёт неверное решение, но верный ответ. Да, задача сформулирована на очень техничном языке, - видимо, в этом и состоял смысл, - но вообще-то представляет собой вполне обычный для спецкурса по топологии вопрос о двух зацепленных окружностях-лепестках (или про "конфигурационные пространства" - как хотите), поэтому что-то задача не тянет даже на заявленный в начале критерий сложности - "должна требовать около недели времени для решения математиком". Но LLM - не справляется. Там же написано, что та же LLM не справилась с задачами, требовавшими корректной интерпретации результатов промежуточных шагов.
Я согласен, что в общем виде это не числа, но для человека незнакомого с концепцией проще её понять если использовать простые и знакомые термины, поэтому написал как написал.
Так главное - не перевернуть обобщение: рациональные числа образуют поле, но не очень хорошо писать, упрощая в другую сторону, что "поле - это рациональные числа".
Точно также не считаю зазорным объясняя понятие "матрицы" для человека не знакомого с линейной алгеброй использовать описание "прямоугольная таблица с числами".
А вот это обобщение лучше. Потому что "прямоугольные таблицы с числами" - это заведомо шире определение, чем матрицы. А "поля - числа" - наоборот.
А вообще можете объяснить на чем там криптостойкость основана? Не на GF же?
Так весь AES можно переписать "в GF" - так и называется: Rijndael-GF. Поэтому, в каком-то смысле, практическая стойкость прямо связана с арифметикой в конечном поле, да. Но, если чуть ближе к вычислительной реальности, то предположение о стойкости AES основывается лишь на том, что не удалось найти методов, позволяющих на практике использовать внутреннюю структуру шифра для того, чтобы отличить выдачу для конкретного открытого текста (и неизвестного ключа) от случайной последовательности той же длины, что и блок. Ну или есть другие варианты моделирования стойкости, но они похожи - смысл всё тот же: повторное комбинаторное перемешивание стирает "все" следы структуры шифра (и поля, кстати). Но строго это не доказано, конечно.
А то закрадываются мысли о том, что "рекомендовано NIST" можно трактовать как любят спецслужбы: обыватель не сможет взломать, а мы сможем.
Есть и такое мнение, факт. И алгебраичность AES только способствует "закрадыванию" таких мыслей. Но, скорее, если уж и взломать, то через ошибки реализации и утечки по побочным каналам.
(AES) [...] Проконсультировался с коллегами алгебраистами, так если честно и не понял почему и зачем именно такое преобразование используется, напишите в комментариях если знаете зачем.
В AES конечное поле используется потому, что это относительно простой способ задать строгую структуру с нужными свойствами на конечном наборе элементов. То есть, когда отображения внутри множества гарантированно будут взаимно однозначными (биекция), а поэтому можно получить для зафиксированного элемента a "равномерное" отображение на той же структуре, что и делается в AES, но при помощи умножения (шаг MixColumns базового преобразования). Конкретно в AES - схема используется для перемешивания значений, с некоторой гарантией отсутствия наложения результатов; то есть, наблюдая статистику на выходе преобразования - сложно различить входные значения (это прямо следует из того, что используемые операции биективны). Собственно, по этим же причинам конечные поля используются в прикладной криптографии вообще.
(Естественно, есть и обратный эффект: если структуры "слишком много", то, зная некоторый секрет, можно построить разбиение входных значений по выходным. Это одно из направлений поиска "закладок" алгебраическими методами. Поле - не всегда хорошо для криптосистемы. Группа - лучше.)
Да, вот прям чувствуется, как ИИ выполняет: в коде веб-страницы ssi.inc (Safe Superintelligence) долгое время был единственный <div>, но и тот не закрыт; потом это исправили, однако <!DOCTYPE> отсутствует и сейчас.
Попробуйте подобрать исходную фразу для хешей 377, 777 или 333.
Для 333. Можно в уме.
Нам нужно 333 (mod 1000). Будем целить в 1333 - выглядит так, что можно столько набрать на трёх слагаемых. Запись искомого числа оканчивается на 3, значит оно равно 3 (mod 10). 3 (mod 10) можно получить несколькими способами. Действуя наобум и немного прикинув частотность имеющихся чисел, выбираем 8 + 8 + 7 == 23 == 3 (mod 10). То есть, нам подходят только числа, оканчивающиеся на 8 и 7, но их тут, похоже, достаточно. Выписываем такие числа: 927, 567, 797, 957, 987, 287, 198, 758, 678, 368. Вспоминаем, что нам нужно 8 + 8 + 7, но при этом должно быть 33 (mod 100). Это означает, что достаточно рассмотреть по две последних цифры записи. И у нас уже есть повторы. Удобно, что почти все двузначные числа, соответствующие выбранным, достаточно большие, то есть, при десятках - пять и более единиц. Поэтому 133 выглядит слишком малым целевым числом (уже 3 * 44 == 32), его недостаточно, чтобы обеспечить вариативность по трём слагаемым. Прицеливаемся на 233. Смотрим примерные числа и проверяем (должна быть сигнатура 8, 8, 7): 78 + 68 + 87 == 233. Сразу подходит, угадали. Проверяем результат для трёх цифр: 678 + 368 + 287 == 1333 == 333 (mod 1000). Готово. Нашли один из ответов: ЭЖУ.
У Let's Encrypt должен быть свой резолвер.
Нет. Достаточно перехватить на этапе обращения к авторитативному серверу. Пункт 3 в вашем списке - "[DNS resolvers] -> [ Authorative DNS ]". Авторитативных серверов может быть несколько, но не факт, что УЦ и опрашивает несколько, сравнивая ответы. Как я и написал выше, если нет DNSSEC, то здесь полностью аналогичная HTTP схема: HTTP-узлов так же может быть несколько, они могут быть "в AWS", "в облаке" и т.д.
(Отмечу ещё раз, что, конечно, проверка через DNS, в целом, это существенно более надёжный вариант. Но для стороны УЦ, а не с точки зрения перехвата на уровне провайдера.)
Так DNS уже построена. DANE - базируется на DNS. DANE вообще весьма хорошая, архитектурно, технология. Такое редко встречается в этих интернетах.
DNS - это распределённая БД, хранить там, вообще говоря, позволяется что угодно. Есть SSHFP и пр., скажем. Относительно новая часть, необходимая для DANE - DNSSEC - это да, это такая хрупкая пристройка-надстройка. Но, всё ж, она и предложена-то, буквально, для того, чтобы удостоверять значение записей. Другое дело, что с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень.
Да, с DANE не сложилось - заменили на Certificate Transparency. (Кстати, единственный способ, который мог бы как-то заметно повлиять на исходную ситуацию с подменой сертификата - это сравнение отпечатков ключей клиентом.)
Это если считать, что весь трафик - строго штатный. К сожалению, в интернетах это не так. При этом stapling никак не отменяет требований по доступности OCSP-респондера: респондер всё равно должен быть выставлен наружу и быть готов обсуживать огромный поток запросов - иначе начнёт отваливаться и stapling.
Вообще, там всё несколько сложнее. Балансировка нагрузки с HTTP (например) - это только одна часть. Но для того, чтобы поддерживать OCSP-респондер, нужно ещё вести внутри УЦ большую базу актуальных статусов сертификатов - не так, как с CRL. Эта база активно раздувается, что, однако, не должно мешать успешной привязке к респондеру. Ответы респондера - нужно подписывать (не так, как CRL), а для этого требуется организовать более или менее безопасную работу с ключами. В практике УЦ - это всё очень затратные и сложные, с инженерной точки зрения, операции и процессы.
Это верно, но только если у сервера всё ещё есть валидный OCSP-ответ, то да. Если OCSP-респондер упал, то уже нет. Когда УЦ обслуживает сотни миллионов сайтов - сложно угадать, в какой момент какой сервер придёт за OCSP-ответом.
Нет, не такой же. CNAME подразумевает замену имёни и дополнительные запросы. Корректная настройка на стороне зоны - тоже требует усилий.
В мультипликативном DH (FFDH) давно есть типовое требование: использовать для алгоритма циклическую подгруппу (простого) порядка (p-1)/2. Это то же самое. См., например, RFC 7919 (группы FFDH для TLS) или документы NIST 800.
Да. И пока все обсуждают "сверхразумный ИИ" - TLS-сертфикаты для веба, ловким движением, превращаются в безотзывные короткоживущие токены, типа Kerberos, только в другую сторону: чтобы к вашему ресурсу было разрешено подключаться клиентам - нужно в онлайн-режиме серверу получать подтверждающий токен в центре сертификации.
https://habr.com/ru/posts/900692/
Мягко говоря, OCSP - не очень хороший протокол, и так себе технология. Про "приватность" - это верно, но вовсе не является критически важным моментом для УЦ. Причина отказа со стороны УЦ в том, что наслаивается огромная куча проблем с поддержкой высоконагруженного транзакционного онлайн-сервиса, который, при разумном использовании, оказывается блокирующим для клиентов, проверяющих сертификаты. И представьте, что нужно выпускать миллионы сертификатов в месяц.
OCSP как раз правильно, что убрали. Насчёт CRL - вопрос спорный, но что уж поделать.
Уходит всё вместе, и CRL тоже. Отзыв в браузерах давно не работает фактически, а со сверхкороткими сертификатами - официально убирают совсем: "Our six-day certificates will not include OCSP or CRL URLs". В требованиях CA/B-форума - тоже достаточно давно убрали.
Certificate Transparency и прочий мониторинг - это, без сомнения, хорошо и полезно, но работает постфактум и не предотвращает выпуск подменного сертификата и, технически, никак не мешает использованию такого сертификата.
Сейчас вот перейдут на TLS-сертификаты без информации о способе проверки статуса, - то есть, без отзыва, - и даже чисто формальной возможности отозвать неверный сертификат, кроме как через обновление браузера, не останется. А клиенты с доверием TLS-сертификатам - это не только браузеры.
Закрывает, но только для себя, а не для домена. Есть другие УЦ, ключам которых верят браузеры. Валидный сертификат для подмены можно выпустить от любого из них.
А в случае HTTP - между системами CA и веб-сервером. То есть, с точки зрения подключения, то же самое.
Так и Azure - это тоже хостер. Пусть, в данном случае, DNS-хостер.
В принципе, для DNS может потребоваться более сложная схема, но вовсе не обязательно она более сложная. Например, в DNS, обычно, несколько узлов (серверов имён) - однако далеко не факт, что сервис проверки DNS УЦ проверяет несколько ответов (от нескольких узлов). В DNS базовый транспорт - UDP. Далеко не факт, что сервис проверки УЦ подключается по TCP (а это, в данном случае, необходимо делать). И т.д., и т.п. Let's Encrypt, например, из-за требований ACME вообще следует CNAME - что, в этом случае, делать нельзя в принципе, так как это сильно увеличивает реальную поверхность атаки.
То есть, у DNS свои особенности, это факт. Я бы считал, что, в целом, универсальный перехват тут действительно сложнее - DNS вообще очень сложная система. Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостеров (см. рекурсивный опрос и CNAME).
При этом, в теории, HTTP-доступ тоже может оказаться устроен сильно сложнее базового варианта: тоже может быть много узлов, какой-нибудь навороченный anycast с десятком балансировщиков и т.д. Проверяет ли всё это система УЦ? Я бы предположил, что далеко не всегда проверяет.
Да, хорошо.
Это не совсем верно: контроль над трафиком DNS-сервера позволяет "внести" любые изменения в ответы - для клиента это будет эквивалентно внесению изменений в зону. То есть, точка атаки просто переносится на DNS-серверы. UDP даже может быть проще подменить - типа, просто ответить раньше и т.д. (Это всё по модулю DNSSEC, конечно.)
Насчёт "значительно" - тут как повезёт: точно сложнее было бы в том случае, если авторитативных серверов много, их точки подключения распределены по Интернету, а система УЦ проверяет DNS тоже из нескольких точек и обращаясь ко многим авторитативным серверам. Это не всегда так.
Это при условии, что УЦ корректно проверяет DNSSEC-подписи по всей цепочке. Let's Encrypt, вроде, сейчас проверяют. Однако достаточно найти УЦ, который не проверяет - это позволит "подменить" записи в ответах, перехватив DNS-трафик (см. выше).
Либо рядовое накручивание хайпа типовыми методами массмедиа: "секретная встреча", "вы всё равно не поймёте", "приборы не покажем, но там ого-го!", "придёт время -- все ахнут!" и т.д.
Вот, кстати, человек пишет, что он участвовал в упомянутом "симпозиуме" в качестве приглашённого специалиста, и что некоторые моменты в публикации "несколько преувеличены". По ссылке есть и пример задачи, для которой LLM даёт неверное решение, но верный ответ. Да, задача сформулирована на очень техничном языке, - видимо, в этом и состоял смысл, - но вообще-то представляет собой вполне обычный для спецкурса по топологии вопрос о двух зацепленных окружностях-лепестках (или про "конфигурационные пространства" - как хотите), поэтому что-то задача не тянет даже на заявленный в начале критерий сложности - "должна требовать около недели времени для решения математиком". Но LLM - не справляется. Там же написано, что та же LLM не справилась с задачами, требовавшими корректной интерпретации результатов промежуточных шагов.
Так главное - не перевернуть обобщение: рациональные числа образуют поле, но не очень хорошо писать, упрощая в другую сторону, что "поле - это рациональные числа".
А вот это обобщение лучше. Потому что "прямоугольные таблицы с числами" - это заведомо шире определение, чем матрицы. А "поля - числа" - наоборот.
Так весь AES можно переписать "в GF" - так и называется: Rijndael-GF. Поэтому, в каком-то смысле, практическая стойкость прямо связана с арифметикой в конечном поле, да. Но, если чуть ближе к вычислительной реальности, то предположение о стойкости AES основывается лишь на том, что не удалось найти методов, позволяющих на практике использовать внутреннюю структуру шифра для того, чтобы отличить выдачу для конкретного открытого текста (и неизвестного ключа) от случайной последовательности той же длины, что и блок. Ну или есть другие варианты моделирования стойкости, но они похожи - смысл всё тот же: повторное комбинаторное перемешивание стирает "все" следы структуры шифра (и поля, кстати). Но строго это не доказано, конечно.
Есть и такое мнение, факт. И алгебраичность AES только способствует "закрадыванию" таких мыслей. Но, скорее, если уж и взломать, то через ошибки реализации и утечки по побочным каналам.
Всё ж, наверное, не "множество чисел".
В AES конечное поле используется потому, что это относительно простой способ задать строгую структуру с нужными свойствами на конечном наборе элементов. То есть, когда отображения внутри множества гарантированно будут взаимно однозначными (биекция), а поэтому можно получить для зафиксированного элемента a "равномерное" отображение
на той же структуре, что и делается в AES, но при помощи умножения (шаг MixColumns базового преобразования). Конкретно в AES - схема используется для перемешивания значений, с некоторой гарантией отсутствия наложения результатов; то есть, наблюдая статистику на выходе преобразования - сложно различить входные значения (это прямо следует из того, что используемые операции биективны). Собственно, по этим же причинам конечные поля используются в прикладной криптографии вообще.
(Естественно, есть и обратный эффект: если структуры "слишком много", то, зная некоторый секрет, можно построить разбиение входных значений по выходным. Это одно из направлений поиска "закладок" алгебраическими методами. Поле - не всегда хорошо для криптосистемы. Группа - лучше.)
Да, вот прям чувствуется, как ИИ выполняет: в коде веб-страницы ssi.inc (Safe Superintelligence) долгое время был единственный <div>, но и тот не закрыт; потом это исправили, однако <!DOCTYPE> отсутствует и сейчас.
Для 333. Можно в уме.
Нам нужно 333 (mod 1000). Будем целить в 1333 - выглядит так, что можно столько набрать на трёх слагаемых. Запись искомого числа оканчивается на 3, значит оно равно 3 (mod 10). 3 (mod 10) можно получить несколькими способами. Действуя наобум и немного прикинув частотность имеющихся чисел, выбираем 8 + 8 + 7 == 23 == 3 (mod 10). То есть, нам подходят только числа, оканчивающиеся на 8 и 7, но их тут, похоже, достаточно. Выписываем такие числа: 927, 567, 797, 957, 987, 287, 198, 758, 678, 368. Вспоминаем, что нам нужно 8 + 8 + 7, но при этом должно быть 33 (mod 100). Это означает, что достаточно рассмотреть по две последних цифры записи. И у нас уже есть повторы. Удобно, что почти все двузначные числа, соответствующие выбранным, достаточно большие, то есть, при десятках - пять и более единиц. Поэтому 133 выглядит слишком малым целевым числом (уже 3 * 44 == 32), его недостаточно, чтобы обеспечить вариативность по трём слагаемым. Прицеливаемся на 233. Смотрим примерные числа и проверяем (должна быть сигнатура 8, 8, 7): 78 + 68 + 87 == 233. Сразу подходит, угадали. Проверяем результат для трёх цифр: 678 + 368 + 287 == 1333 == 333 (mod 1000). Готово. Нашли один из ответов: ЭЖУ.
(Подсказка: можно ещё проще.)