Криптоанализ по частично известному тексту
Добрый день! Долго вчитывался в faq данного сайта, много интересного узнал. Но так пока и не справился однозначно с проблемой, в т.ч. с помощью гугла. Я совсем новичок в криптографии, поэтому мой вопрос, возможно, покажется наивным, но всё же...
Насколько устойчивы обычные (common) алгоритмы шифрования, например, RSA или IDEA, к криптоанализу при известной части текста исходного сообщения?
Практический смысл такой: я создают некий open-source проект, который подразумевает взаимодействие по сети, чего таить – пишется маленькая SCADA-система (диплом). Естественно, взаимодействие должно быть шифрованным, чтобы злоумышленник не мог ни подсмотреть параметры процесса, ни вмешаться в его управление.
В данном проекте будет реализовываться некий протокол связи отдельных модулей. В следствие открытости исходного кода, сам протокол будет известен потенциальному взломщику.
И тут меня мучает вопрос: если принципиально шифровать весь сетевой траффик между модулями, не сможет ли злоумышленник достаточно просто раскрыть шифр, пользуясь знанием протокола, в котором неизменной и открытой частью будут, к примеру, заголовки сообщений?
То есть:
1. Устройство зафиксировало изменение показаний датчика и должно оповестить диспетчера.
2. Формируется пакет данных, например: "УСТРОЙСТВО 1;ИЗМЕНЕНИЕ ПОКАЗАНИЙ;ДАТЧИК 32;НОВОЕ ЗНАЧЕНИЕ 922;ДАТЧИК 4;НОВОЕ ЗНАЧЕНИЕ 73.".
3. Пакет целиком шифруется и отправляется диспетчеру.
Так вот, потенциальный злоумышленник имеет доступ к исходному коду и знает протокол, т.е. тот факт, что отдельные зашифрованные пакеты в оригинале содержат такие слова, как "УСТРОЙСТВО", "ДАТЧИК" и т.п.
Вопрос в том, сильно ли ему поможет такое знание при криптоанализе пакетов?
Ссылки
[link1] http://www.pgpru.com/faq/kriptografijaobschievoprosy#h37247-9
[link2] http://www.pgpru.com/comment29611
[link3] http://www.pgpru.com/comment37071
[link4] https://secure.wikimedia.org/wikipedia/en/wiki/Salt_(cryptography)
[link5] http://www.pgpru.com/comment25910
[link6] http://www.pgpru.com/comment37669
Ищите 3DES и AES либы, ну или ГОСТ :) и не переживайте по этому поводу.
Если использовать сильные криптосистемы, то никак не поможет. Единственное что злоумышленник сможет попытаться сделать, так это подменить зашифрованные блоки. Поэтому было-бы неплохо еще метку времени какую-нить воткнуть и в конце пакета его хеш дописать, для верификации корректности при приеме.
Странно вы вчитывались. Цитирую:/faq/kriptografijaobschievoprosy#h37247-9[link1] Также см. /comment29611[link2] и /comment37071[link3], где то же самое объяснено ещё более пальцевым методом
мои варианты "извращений на коленке" :
1) добавьте вначале сообщения хеш пакета с информацией;
2) между хешем и информацией добавьте паддинг, чтобы все пакеты были одинаковой длины (или хотя бы кратной N байт, тогда паддинг должен быть с небольшой случайной вариацией длины)
знание о кусках начального текста поможет только если они будут шифроваться схожим образом в разных пакетах. Если каждое сообщение будет уникальным, то ничего страшного. К тому же – смотря от чего идет защита – от чтения данных или от их подмены (чтение некритично) ?
А если неуникальным? :) Не поручусь за стандартную симметрику типа AES, но для PGP одинаковым открытым текстам будут соответствовать разные шифротексты, т.к. последние получаются от шифрования PGP-ключом случайного (т.е. каждый раз нового) пароля для AES, которым, в свою очередь, шифруется уже сам целевой открытый текст.
Поэтому необходим режим шифрования с уникальным вектором инициализации или неповторяющимся счётчиком.
Всех благодарю за пояснения!
Кстати, счетчик у меня предусмотрен для идентификации порядка сообщений. Ну и контрольная сумма тоже =)
FAQ читал, стало быть, действительно не слишком внимательно, то было 4 часа ночи =)
Кстати да, как я мог забыть. Достаточно вспомнить что любое оконечное шифрование обязано использовать соль (salt).Настоятельно советуется не писать криптолибы самому (лучше чем есть, не сделаете, а вот хуже — наверняка, в том числе и в плане безопасности), а использовать уже существующие общепризнанные (хотя бы даже тот же OpenSSL или GnuTLS).
Это довольно монстроидные приложения, которые могут быть неприменимы в данной среде. Тут, кстати, вопрос к топик-стартеру: какими ресурсами располагают SCADA-датчики? Крипто реализуется непосредственно на них или есть некие хабы с достаточным хардовым оснащением?
Именно оконечное?.. Согласно гуглению, оконечное шифрование подразумевает открытость служебной информации, т.е. в моем случае получается, что шифруются только показания датчиков, но никак не "кодовые слова" протокола, верно я вас понял?..
В таком случае, соль служит для невозможности анализа объема шифрованных данных, т.е. показаний датчиков?
Честно говоря, целесообразность такой схема в моем случае мне не совсем ясна...
Тут всё куда проще, чем может казаться =) В моем проекте "выносится за скобки" хардверная часть, грубо говоря, показания аккумулируются на неком обслуживающем компьютере (способ подключения остается "за скобками"), потом уже шифруются и пересылаются диспетчеру. Т.е. шифрование полностью программное.
Задачу выбора алгоритмов с т.з. эффективности упрощает также формулировка темы, согласно которой система ориентирована на "медленно протекающие процессы", т.е. проектное время отклика потенциально настолько велико, что вопрос производительности стоит далеко не на первом месте =)
Под "оконечностью" понималась уже готовая к употреблению схема, где все внутренности алгоритмов подобраны так, чтобы криптографических уязвимостей не было (на уровне практического применения речь идёт о протоколе, использующем криптопримитивы, где последний может оказаться некриптостойким несмотря на хорошо выбранные сами криптопримитивы. Когда начинают вести речь о счётчиках, добавлении подписи, атуентификации, защите от атак перепосылки фактически уже идёт обсуждение самого протокола). Связи со служебной информацией я здесь не вижу.Соль нужна для того, чтобы одинаковые открытые тексты не давали одинаковые шифротексты — раз, и чтобы затруднить словарные атаки злоумышленнику — два.
При правильно реализованном протоколе должна быть защищена и аутентифицирована вся передаваемая информация. Обычно такую задачу решают так: никто не сочиняет "свой криптопротокол" точно так же. как и не придумывает свой аналог tcp-стека, а вместо этого использует стандартные транспорты. Универсальный туннель по передаче данных, ложащийся поверх tcp, есть SSL (TLS). Далее каждая прога, кому нужно, его и использует. Не понятно зачем вам при такой постановке создавать свой протокол? Имхо, задача решается уже имеющимися и причём вполне стандартными средствами. Более того, даже в случае ограничений, подразумеваемых SATtva'ой, я почти уверен, что имеются стандартные уже разработанные решения с вполне внятным обоснованием. Делать здесь что-то самому своими руками — чисто спортивный/учебный интерес, разве что.
Про соль можете почитать здесь[link4].
Да, действительно... Им и воспользуюсь, благо есть JSSE.
Спасибо!
Может есть какие-то более простые и менее "монструозные решения", но я уже тут не советчик.
Просто для примера: есть библиотека crypt с тулзами к ней типа mcrypt, есть ssh-туннели (можно поднять универсальный шифрованный туннель с помощью одной команды, через который пустить любой иной протокол, например HTTP, причём от SSL оно не зависит никак), есть какие-то криптобиблиотеки, которые специально писались для джабберов типа libotr. Есть основанный на SSL готовый туннель-протокол OpenVPN, есть тулзы типа stunnel. В современом мире решений под шифрованный транспорт и соответствующих библиотек так много, что по ним можно было бы написать целый отдельный обзор. Чем хорош конкретно OpenSSL — тем, что он есть практически на любой UNIX-системе, т.е. де-факто стандарт, на который завязана масса продуктов, а, значит, и повышенные требования к функционалу — отсюда и идёт его "монструозность" :)
Кстати, вопрос поставлен верно и ответ на него, собственно, уже дан. Подробнее обсуждалось здесь: /comment25910[link5] и /comment37669[link6].