Криптоанализ по частично известному тексту
Добрый день! Долго вчитывался в faq данного сайта, много интересного узнал. Но так пока и не справился однозначно с проблемой, в т.ч. с помощью гугла. Я совсем новичок в криптографии, поэтому мой вопрос, возможно, покажется наивным, но всё же...
Насколько устойчивы обычные (common) алгоритмы шифрования, например, RSA или IDEA, к криптоанализу при известной части текста исходного сообщения?
Практический смысл такой: я создают некий open-source проект, который подразумевает взаимодействие по сети, чего таить – пишется маленькая SCADA-система (диплом). Естественно, взаимодействие должно быть шифрованным, чтобы злоумышленник не мог ни подсмотреть параметры процесса, ни вмешаться в его управление.
В данном проекте будет реализовываться некий протокол связи отдельных модулей. В следствие открытости исходного кода, сам протокол будет известен потенциальному взломщику.
И тут меня мучает вопрос: если принципиально шифровать весь сетевой траффик между модулями, не сможет ли злоумышленник достаточно просто раскрыть шифр, пользуясь знанием протокола, в котором неизменной и открытой частью будут, к примеру, заголовки сообщений?
То есть:
1. Устройство зафиксировало изменение показаний датчика и должно оповестить диспетчера.
2. Формируется пакет данных, например: "УСТРОЙСТВО 1;ИЗМЕНЕНИЕ ПОКАЗАНИЙ;ДАТЧИК 32;НОВОЕ ЗНАЧЕНИЕ 922;ДАТЧИК 4;НОВОЕ ЗНАЧЕНИЕ 73.".
3. Пакет целиком шифруется и отправляется диспетчеру.
Так вот, потенциальный злоумышленник имеет доступ к исходному коду и знает протокол, т.е. тот факт, что отдельные зашифрованные пакеты в оригинале содержат такие слова, как "УСТРОЙСТВО", "ДАТЧИК" и т.п.
Вопрос в том, сильно ли ему поможет такое знание при криптоанализе пакетов?
1) добавьте вначале сообщения хеш пакета с информацией;
2) между хешем и информацией добавьте паддинг, чтобы все пакеты были одинаковой длины (или хотя бы кратной N байт, тогда паддинг должен быть с небольшой случайной вариацией длины)
знание о кусках начального текста поможет только если они будут шифроваться схожим образом в разных пакетах. Если каждое сообщение будет уникальным, то ничего страшного. К тому же – смотря от чего идет защита – от чтения данных или от их подмены (чтение некритично) ?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 3 документов: 1 редакций: 0
Кстати, счетчик у меня предусмотрен для идентификации порядка сообщений. Ну и контрольная сумма тоже =)
FAQ читал, стало быть, действительно не слишком внимательно, то было 4 часа ночи =)
комментариев: 11558 документов: 1036 редакций: 4118
Это довольно монстроидные приложения, которые могут быть неприменимы в данной среде. Тут, кстати, вопрос к топик-стартеру: какими ресурсами располагают SCADA-датчики? Крипто реализуется непосредственно на них или есть некие хабы с достаточным хардовым оснащением?
комментариев: 3 документов: 1 редакций: 0
Именно оконечное?.. Согласно гуглению, оконечное шифрование подразумевает открытость служебной информации, т.е. в моем случае получается, что шифруются только показания датчиков, но никак не "кодовые слова" протокола, верно я вас понял?..
В таком случае, соль служит для невозможности анализа объема шифрованных данных, т.е. показаний датчиков?
Честно говоря, целесообразность такой схема в моем случае мне не совсем ясна...
Тут всё куда проще, чем может казаться =) В моем проекте "выносится за скобки" хардверная часть, грубо говоря, показания аккумулируются на неком обслуживающем компьютере (способ подключения остается "за скобками"), потом уже шифруются и пересылаются диспетчеру. Т.е. шифрование полностью программное.
Задачу выбора алгоритмов с т.з. эффективности упрощает также формулировка темы, согласно которой система ориентирована на "медленно протекающие процессы", т.е. проектное время отклика потенциально настолько велико, что вопрос производительности стоит далеко не на первом месте =)
При правильно реализованном протоколе должна быть защищена и аутентифицирована вся передаваемая информация. Обычно такую задачу решают так: никто не сочиняет "свой криптопротокол" точно так же. как и не придумывает свой аналог tcp-стека, а вместо этого использует стандартные транспорты. Универсальный туннель по передаче данных, ложащийся поверх tcp, есть SSL (TLS). Далее каждая прога, кому нужно, его и использует. Не понятно зачем вам при такой постановке создавать свой протокол? Имхо, задача решается уже имеющимися и причём вполне стандартными средствами. Более того, даже в случае ограничений, подразумеваемых SATtva'ой, я почти уверен, что имеются стандартные уже разработанные решения с вполне внятным обоснованием. Делать здесь что-то самому своими руками — чисто спортивный/учебный интерес, разве что.
Про соль можете почитать здесь.
комментариев: 3 документов: 1 редакций: 0
Да, действительно... Им и воспользуюсь, благо есть JSSE.
Спасибо!
Просто для примера: есть библиотека crypt с тулзами к ней типа mcrypt, есть ssh-туннели (можно поднять универсальный шифрованный туннель с помощью одной команды, через который пустить любой иной протокол, например HTTP, причём от SSL оно не зависит никак), есть какие-то криптобиблиотеки, которые специально писались для джабберов типа libotr. Есть основанный на SSL готовый туннель-протокол OpenVPN, есть тулзы типа stunnel. В современом мире решений под шифрованный транспорт и соответствующих библиотек так много, что по ним можно было бы написать целый отдельный обзор. Чем хорош конкретно OpenSSL — тем, что он есть практически на любой UNIX-системе, т.е. де-факто стандарт, на который завязана масса продуктов, а, значит, и повышенные требования к функционалу — отсюда и идёт его "монструозность" :)