Я вскрывал ключи шифрования длиной 1000 бит. Можно ли использовать, как Вы написали, 256 битный ключ на элептеке для шифрования секретной информации? Однозначно, нет. Не хочу вдаваться в подробности криптографии. Я в статье задал простой вопрос о равновероятности ключей шифрования. Кто их проверял?
Крипто ПРО и другие средства шифрования проходили официальную сертификацию в ФСБ. Это совершенно другое. Просто встроить алгоритм шифрования без соответсвующих знаний обычно приводит к многочисленным ошибкам.

Анатолий Клепов   08.09.2024 11:25   Заявить о нарушении

"Я вскрывал ключи шифрования длиной 1000 бит. Можно ли использовать, как Вы написали, 256 битный ключ на элептеке для шифрования секретной информации? Однозначно, нет. Не хочу вдаваться в подробности криптографии. Я в статье задал простой вопрос о равновероятности ключей шифрования. Кто их проверял?
Крипто ПРО и другие средства шифрования проходили официальную сертификацию в ФСБ. Это совершенно другое. Просто встроить алгоритм шифрования без соответсвующих знаний обычно приводит к многочисленным ошибкам."

Что значит "вы вскрывали"? У вас есть cyphertext AEAD AES-256 GCM, симметричный блочный алгоритм, и вы из него получили 256-битный ключ? У вас есть публикации, чтобы я в это поверил?
И ещё не забывайте об эфимерности секретного ключа Диффи-Хеллмана на элиптических кривых, то есть ключи на одно сообщение одноразовые. Даже получив AES-ключ, вы взламываете только одно сообщение. Чтобы взломать канал, нужно взломать ECDH, то есть ассиметричное шифрование на 256-битных ключах, где происходит обмен только открытыми ключами, векторами и тэгами. Вы и такое делали? Поделитесь ссылкой на публикацию?

Понимаете, аппаратная генерация ключей не помогает улучшить криптостойкость самого алгоритма. Если вам удалось получить ключ из сайфер-текста, то не важно, что сгенерировало ключ. Единственное, что делает аппаратная генерация и RNG - делает генерацию псевдорандома более хаотичным засчёт добавления параметров с аппаратных датчиков и биометрии. Впрочем, биометрия может применяться и в software-варианте. Плюс - производительность выше и возможность влиять на генератор malware ниже. На криптостойкость алгоритма это не влияет. Аппаратное шифрование также гарантирует "железную" реализацию алгоритма по GOST, и ускорение самого шифрования, это удобно для фильтров пакетов сетевого уровня или TLS. Для Telegram это всё не нужно, ему не нужно соответствовать требованиям ФСБ и проходить лицензирование. Это не банковское ПО и не ПО для работы в генштабах, связи РВСН и в прочих критически важных местах. Это не значит, что Telegram имеет более слабый шифр. Я вам открою секрет: банковские системы используют алгоритмы ECDH-A256GCM, RSA и PS256, не аппаратные, и не GOST. Но они на это переходят и, как я уже писал выше, требования ФСБ заставят клиентов однажды ставить аппаратные криптомодули (рутокены например) и проходить аутентификацию не по OIDC, а по протоколу FIDO WebAuth. Это не потому GOST лучше ECDH и AES256. Это потому, что ФСБ так решило, это их право так считать.

Дмитрий Кальянов   08.09.2024 16:34   Заявить о нарушении

Анатолий, прошу прощения. Я занимаюсь платформой безопасности для банковского ПО и мы регулярно проходим лицензирование по ФАПСИ/ФСТЭК

Дмитрий Кальянов   08.09.2024 16:38   Заявить о нарушении

Я спас Россию от финансового краха поставив несколько десятков тысяч шифраторов в ЦБ РФ ( фальшивое авизо). Разработчик первого в мире аппаратного крипто смартфона и аппаратного крипто мессенджера. Мои крипто алгоритмы были сертифицированы Королевским Техногическим Коледжом Швеции. Заключении подписывал один из крупнейших в мире криптографов. исследование моего крипто алгоритма подписал начальник разведки ЮАР. Могу долго продолжать…
Дешифровал не один шифратор, имеющий самую высокую степень секретности…

Анатолий Клепов   08.09.2024 16:45   Заявить о нарушении

Анатолий, добавлю ещё по длине ключа. Вы апелируете к его длине как к параметру криптостойкости, это верно. Для шифра можно использовать и 2045-битные ключи. Но дело в том, что увеличивая длину ключа, вы увеличиваете размер сообщения это раз, а во-вторых делаете криптооперации слишком дорогими в условиях миллиарда сообщений в день. Умные люди посчитали, например, что SHA-256 уже слабоват, поэтому рекомендуют SHA-256, а SHA-1 помечен как устаревший, аналогично MD5. Просто криптооперация SHA стала дешевле и значит разумно повысить длину хэша.

Дмитрий Кальянов   08.09.2024 16:46   Заявить о нарушении

Анатолий, я не сомневаюсь в ваших заслугах, я просто хочу прочитать, каким образом вы взломали AES-256. Потому что 90-е годы - это не 2020-е. Там и производительность процей увеличилась, и появились криптомодули, и криптофонами не удивить. Только их плюс - в производительности, что позволяет шифровать каналы на низком уровне без потерь в передаче данных, прозрачно и быстро. Да, у ключей повысится энтропия, но криптостойкость алгоритма не увеличится. Потому что не важно, используете вы GOST 28147-89 на чипе или в программной библиотеке, результат будет один. Поэтому раздолбать телегу - это такое... Из разряда влажных фантазий юных хакеров. Понимаете, дело не в ключах. Сейчас используются более современные KDF (например, ConcatKDF) и GCM (AEAD).

Дмитрий Кальянов   08.09.2024 17:01   Заявить о нарушении

И вот уж если на то пошло, взять к примеру ECDH, то вам для генерации KEK необходимо сформировать пару Secret/Open (Элис), и такую же пару SEcret/Open имеет ваш визави (Боб). Обмен выполняется только open-ключами, а Secret сохраняется в защищённом хранилище клиента. Представьте, СОРМ, к Паше приходят следаки и требуют отдать ключи для расшифровки сообщений. У Паши нет ключей, они у Боба и Элим. Паша рад помочь, но он сделал очень крутую защиту, поэтому отправляет оперов искать этих Боба и Элис. Боб в США, Элис в России. Если у вас один секретный ключ Элис, вы можете прочесть только сообщения от Боба к Элис. Если учесть, что клиенты используют аппаратные контейнеры-кейгены, как например Крипто-Про, то вероятность получения такого ключа, даже попади смартфон в руки спецслужб, нулевая. Тут придётся использовать терморектальный криптоанализ, ну а против него уже никакая защита не спасёт.

Дмитрий Кальянов   08.09.2024 17:15   Заявить о нарушении

Я не только в 90-е года делал. Я говорю о принципах. Есть криптографические методы дешифрования. Которые нигде не публикуются.
Кстати, мои уникальная стелс криптография до сих пор не имеет аналогов в мире.
Можете посмотреть сайт моей швейцарской компании www.mttgroup.ch
Там приведено множество уникальных алгоритмов шифрования, в том числе аппаратные генераторы ключей.

Анатолий Клепов   08.09.2024 17:18   Заявить о нарушении

MTProto — криптографический протокол, используемый в системе обмена сообщениями Telegram для шифрования переписки пользователей. Протокол был разработан Николаем Дуровым и другими программистами Telegram.

В основе протокола лежит оригинальная комбинация симметричного алгоритма шифрования AES (в режиме IGE), протокола Диффи-Хеллмана для обмена 2048-битными RSA-ключами между двумя устройствами и ряда хеш-функций. Протокол допускает использование шифрования end-to-end с опциональной сверкой ключей

Как вы считаете, он слабый?

Дмитрий Кальянов   08.09.2024 18:28   Заявить о нарушении

Вот на хабре статья
http://habr.com/ru/articles/590667/

Дмитрий Кальянов   08.09.2024 18:33   Заявить о нарушении

И ещё, Анатолий, я вам расскажу несколько причин, почему тормозиться внедрение криптожелезок. Просто времени нет описывать много, скажу только, что в настоящий момент всё не так плохо, и тенденция идти туда есть. Проблема в другом. Если интересно, я поделюсь с вами практикой применения.

Дмитрий Кальянов   08.09.2024 18:37   Заявить о нарушении

Знаете Алексея Кузьмина? Мой большой Друг. Вместе писали научные статьи. Уникальный метод как создавать равновероятный ключи. Я все потом экспериментально подтвердил. Мой учитель - В. Козлов. Член корреспондент АН СССР. В 1953 году доказал, что ключи шифрования были не равновероятны. Вы знаете как делали ключи шифрования в 1940 году? Лохотрон. Два шарика падали на перфоленту случайным образом.

Анатолий Клепов   08.09.2024 19:21   Заявить о нарушении

Ха, почитайте, как работает randomseed у Cloudflare) Шарики отдыхают)

Дмитрий Кальянов   08.09.2024 19:50   Заявить о нарушении

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

Дмитрий Кальянов   08.09.2024 19:55   Заявить о нарушении

Или вот пример раздолбайства сертификации. Белорусский "Авест", аналог (а может и копия) нашего GOST, реализован и сертифицирован как CSP для Windows. Соответственно на OpenSSL под Linux его библиотеки не портированы. Возможно, это дело времени, но шёл 2022 год, и уже давно все сервисы перешли на Linux. А наши RedOS и AstraLinux это вообще отдельные темы, именно благодаря переходу наших с винды на линь, у компаний-производителей сертифицированных алгоритмов появились нормальные человеческие SDK для интеграций в сервисы, приложения и браузеры. Пример: CryptoPro, которые медленно, но верно охватывают все популярные платформы разработки.

Дмитрий Кальянов   08.09.2024 20:00   Заявить о нарушении

Кузнечик разрабатывал Алексей Кузьмин.

Анатолий Клепов   08.09.2024 21:40   Заявить о нарушении

Правда, в сети фигурируют фамилии Кузнецова и Нечаева.. ну, допустим, Кузьмин.

Дмитрий Кальянов   08.09.2024 22:23   Заявить о нарушении

Самая большая проблема внедрения аппаратных методов шифрования - необходимость встраивания аппаратных решений в инфраструктуру сервисов, с которыми они работают. Дело в том, что непосредственно сами алгоритмы напрямую ни один программный продукт не использует. Для этого есть абстракции, такие как SChannel, OpenSSL, SSL/TLS, Kerberos/GSSAPI или Windows CSP, PKI (x509) и т.д. То есть например если требуется SSL/TLS канал между браузером и сервером, сервер при установке соединения не делает низкоуровневый хендшейк и не выполняет шифрование сессионных ключей, уходя в "железку", а использует для это какой-то криптографический API. Аналогично, при валидации подписи JWT-токена в OAuth вам не нужно ходить в "железо", за это сделать CSP на Windows либо OpenSSL на Linux. То есть, понимаете, что даже делая шифрование GOST или вычисляя хэши GOST с аппаратным рандомсидом, вы всё равно идёте через API того фреймворка, в котором разрабатывается приложение. Это могут быть DotNet, Java, Python, C++, Rust, Go и т.д. Не важно принцип один - матрёшка из API. Железка это хорошо. У неё есть драйверы, провайдеры, она встаёт в ОС и можно использовать её для генерации ключей и шифрования на уровне OC. Хотите керберос, хотите OAuth, хотите mTLS - не важно. Но вот сейчас для управления сервисами используется контейнеризация Docker, DockerSwarm, Kubernetes. А это означает, что ваш сервис не привязан к железке, а разворачивается в виртуальных машинах, кластерах, контейнерах. И вообще, в чужих датацентрах. И тут начинаются проблемы. Разрабочики железок не дают инструменты интеграции с Docker и с оркестраторами. Оркестрация уже дефакто стандарт. Хотите вы этого или нет, современное ПО разрабатывается на основе западных стандартов, спецификаций, RFC и API, и соскочить с этих рельс невозможно: отечественных замен просто нет. Вариант решения один - разработка какого то keyvault-сервера внутри стэка сервисов, что открывает довольно мощные уязвимости: ваш аппаратный модуль превращается в сервис, работающий по протоколу, например, gRpc. И перехватив пакеты или взломав сам сервис, всё преимущество аппаратного шифрования летит к чёрту. Какой-то vault сейчас разрабатывают наши, но до внедрения этого пройдёт ещё не один год.

Дмитрий Кальянов   08.09.2024 22:40   Заявить о нарушении