Криптоанализ по частично известному тексту

Ищите 3DES и AES либы, ну или ГОСТ :) и не переживайте по этому поводу.

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

Долго вчитывался в faq данного сайта, много интересного узнал. Но так пока и не справился однозначно с проблемой, в т.ч. с помощью гугла.

Странно вы вчитывались. Цитирую:

Очевидно, что такая модель используется впервую очередь для проектирования блочных шифров. При этом к такому шифру предъявляются самые высокие критерии безопасности по нахождению различителя от идеальной модели. Шифр должен быть не только устойчив к атакам с известными, подобранными, адаптивно-подобранными открытыми и шифртекстами, но и к более экзотическим атакам: любые действия с шифром должны требовать не меньше ресурсов, чем простой перебор в отношении к идеальной модели — например такие "атаки" — найти ключ, который из данного открытого текста даёт заданный шифртекст, использовать вход открытого текста и ключ в качестве функции сжатия для хэш-функций (при такой атаке противнику известны и ключ, и открытый текст, и шифртекст, и полное внутреннее состояние шифра на каждом раунде) и др.

/faq/kriptografijaobschievoprosy#h37247-9 Также см. /comment29611 и /comment37071, где то же самое объяснено ещё более пальцевым методом

мои варианты "извращений на коленке" :
1) добавьте вначале сообщения хеш пакета с информацией;
2) между хешем и информацией добавьте паддинг, чтобы все пакеты были одинаковой длины (или хотя бы кратной N байт, тогда паддинг должен быть с небольшой случайной вариацией длины)

знание о кусках начального текста поможет только если они будут шифроваться схожим образом в разных пакетах. Если каждое сообщение будет уникальным, то ничего страшного. К тому же – смотря от чего идет защита – от чтения данных или от их подмены (чтение некритично) ?

Если каждое сообщение будет уникальным, то ничего страшного

А если неуникальным? :) Не поручусь за стандартную симметрику типа AES, но для PGP одинаковым открытым текстам будут соответствовать разные шифротексты, т.к. последние получаются от шифрования PGP-ключом случайного (т.е. каждый раз нового) пароля для AES, которым, в свою очередь, шифруется уже сам целевой открытый текст.

Поэтому необходим режим шифрования с уникальным вектором инициализации или неповторяющимся счётчиком.

Всех благодарю за пояснения!

Кстати, счетчик у меня предусмотрен для идентификации порядка сообщений. Ну и контрольная сумма тоже =)

FAQ читал, стало быть, действительно не слишком внимательно, то было 4 часа ночи =)

Поэтому необходим режим шифрования с уникальным вектором инициализации или неповторяющимся счётчиком.

Кстати да, как я мог забыть. Достаточно вспомнить что любое оконечное шифрование обязано использовать соль (salt).

Кстати, счетчик у меня предусмотрен для идентификации порядка сообщений.

Настоятельно советуется не писать криптолибы самому (лучше чем есть, не сделаете, а вот хуже — наверняка, в том числе и в плане безопасности), а использовать уже существующие общепризнанные (хотя бы даже тот же OpenSSL или GnuTLS).

использовать уже существующие общепризнанные (хотя бы даже тот же OpenSSL или GnuTLS).

Это довольно монстроидные приложения, которые могут быть неприменимы в данной среде. Тут, кстати, вопрос к топик-стартеру: какими ресурсами располагают SCADA-датчики? Крипто реализуется непосредственно на них или есть некие хабы с достаточным хардовым оснащением?

Кстати да, как я мог забыть. Достаточно вспомнить что любое оконечное шифрование обязано использовать соль (salt).

Именно оконечное?.. Согласно гуглению, оконечное шифрование подразумевает открытость служебной информации, т.е. в моем случае получается, что шифруются только показания датчиков, но никак не "кодовые слова" протокола, верно я вас понял?..

В таком случае, соль служит для невозможности анализа объема шифрованных данных, т.е. показаний датчиков?

Честно говоря, целесообразность такой схема в моем случае мне не совсем ясна...

Тут, кстати, вопрос к топик-стартеру: какими ресурсами располагают SCADA-датчики? Крипто реализуется непосредственно на них или есть некие хабы с достаточным хардовым оснащением?

Тут всё куда проще, чем может казаться =) В моем проекте "выносится за скобки" хардверная часть, грубо говоря, показания аккумулируются на неком обслуживающем компьютере (способ подключения остается "за скобками"), потом уже шифруются и пересылаются диспетчеру. Т.е. шифрование полностью программное.

Задачу выбора алгоритмов с т.з. эффективности упрощает также формулировка темы, согласно которой система ориентирована на "медленно протекающие процессы", т.е. проектное время отклика потенциально настолько велико, что вопрос производительности стоит далеко не на первом месте =)

Именно оконечное?

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

В таком случае, соль служит для невозможности анализа объема шифрованных данных, т.е. показаний датчиков?

Соль нужна для того, чтобы одинаковые открытые тексты не давали одинаковые шифротексты — раз, и чтобы затруднить словарные атаки злоумышленнику — два.

Честно говоря, целесообразность такой схема в моем случае мне не совсем ясна...

При правильно реализованном протоколе должна быть защищена и аутентифицирована вся передаваемая информация. Обычно такую задачу решают так: никто не сочиняет "свой криптопротокол" точно так же. как и не придумывает свой аналог tcp-стека, а вместо этого использует стандартные транспорты. Универсальный туннель по передаче данных, ложащийся поверх tcp, есть SSL (TLS). Далее каждая прога, кому нужно, его и использует. Не понятно зачем вам при такой постановке создавать свой протокол? Имхо, задача решается уже имеющимися и причём вполне стандартными средствами. Более того, даже в случае ограничений, подразумеваемых SATtva'ой, я почти уверен, что имеются стандартные уже разработанные решения с вполне внятным обоснованием. Делать здесь что-то самому своими руками — чисто спортивный/учебный интерес, разве что.

Про соль можете почитать здесь.

Универсальный туннель по передаче данных, ложащийся поверх tcp, есть SSL (TLS).

Да, действительно... Им и воспользуюсь, благо есть JSSE.

Спасибо!

Может есть какие-то более простые и менее "монструозные решения", но я уже тут не советчик.

Просто для примера: есть библиотека crypt с тулзами к ней типа mcrypt, есть ssh-туннели (можно поднять универсальный шифрованный туннель с помощью одной команды, через который пустить любой иной протокол, например HTTP, причём от SSL оно не зависит никак), есть какие-то криптобиблиотеки, которые специально писались для джабберов типа libotr. Есть основанный на SSL готовый туннель-протокол OpenVPN, есть тулзы типа stunnel. В современом мире решений под шифрованный транспорт и соответствующих библиотек так много, что по ним можно было бы написать целый отдельный обзор. Чем хорош конкретно OpenSSL — тем, что он есть практически на любой UNIX-системе, т.е. де-факто стандарт, на который завязана масса продуктов, а, значит, и повышенные требования к функционалу — отсюда и идёт его "монструозность" :)

Насколько устойчивы обычные (common) алгоритмы шифрования, например, RSA или IDEA, к криптоанализу при известной части текста исходного сообщения?

Кстати, вопрос поставлен верно и ответ на него, собственно, уже дан. Подробнее обсуждалось здесь: /comment25910 и /comment37669.