Интересует, какие есть алгоритмы избыточного шифрования (и есть ли) когда одна и таже информация, дважды зашифрованная одним и тем же ключем, никогда не повториться в виде одинаковой зашифрованной последовательности. Алгоритм открытых-закрытых ключей не подходит, так как при одном и том же наборе открытых ключей он даст один и тот же траффик. Открытые ключи можно перехватить, и если правильно предположить передаваемую информацию, можно доказать факт ее передачи. Если я ошибаюсь, поправльте меня, плиз ЗЫ: Че-то навеяно интервью Ms Rem'a
Для того чтобы одинаковые данные шифровались всегда разным образом можно применить простой и эффективный прием, суть которого состоит в том, что данные всегда шифруются случайно сгенерированым ключем, а этот ключ шифруется ключем используемым для обмена информацией (неважно симмитричным, или ассиметирчным) и передается вместе с данными. В случае, если делается криптопротокол для передаче данных по сети, то следует обращать внимание на любые мелочи, так как тут возможны несколько видов уязвимостей не проявляющихся при шифровании данных хранящихся на диске. Например: 1) Злоумышленик может не только видеть, но и изменять трафик, врезаясь в сессию и подмняя данные своими. К этому следует внимательно отнестись при разработке протоколов обмена ключами. 2) Злоумышленник может получить информацию о передаваемых данных (или даже расшифровать их) не вскрывая сам шифр. В качестве примера возьмем любой протокол обменивающийся сообщениями разного размера, и имеющий разный размер сообщений разных типов. В этом случае можно определить тип передаваемого сообщения по размеру шифрованых пакетов данных. Для защиты от такой атаки необходимо приводить все пакеты к фиксированому размеру. 3) Злоумышленик может анализировать время и интенсивность прохождения пакетов, и определить протокол скрывающийся под шифром, и возможно даже передаваемые данные. От этого метода спасает только передача случайного трафика постоянной интенсивности, в котором будут прятаться передаваемые данные, но такой метод к сожалению не всегда применим. 4) Злоумышленик может измерять время обработки сервером запросов аутентификации, и попытаться вычислить по нему секретный ключ. Это возможно потому, что на шифрование разных наборов данных на определенном ключе может затрачиваться разное время. Защититься от этого можно путем стандартизации времени ответа. Можно придумать еще много видов подобных атак, так что следует твердо помнить, что стойкость шифра при передаче данных по сети не обязательно означает стойкость протокола передачи.
Злоумышленник может еще и MITM замутить - тогда все твои данные через него пойдут - и ключи и зашифрованные данные. (Справедливо для LAN,ADSL) - DialUp не подвержен. А насчет асимметричного шифрования - если на той стороне у тебя приватный ключ уже есть, от передачи открытого ключа в самом канале ничего нельзя будет прочитать по любому (только факторизовав открытый ключ, что при длине ключа более 1024 бит за обозримое время невозможно) - отсюда и название - криптография с открытым ключом.А для получения разных данных каждый раз - введи пяток байт от фонаря (случайных) и доролняй ими свою информацию - зная, где (в начале или конце твоего сообщения у тебя этот рандом стоит) легко отделить его после расшифровки - при этом данные будут каждый раз уникальны (в обозримом количестве разов - зависит от разрядности выбираемого рандома)
Почему это не подвержен? что мешяет провайдеру это делать? Это плохое решение, так как блочные шифры шифруют инфорацию фиксироваными блоками, и может просто поизойти сдвиг блоков. Причем пяток байт этого явно мало, длина случайной последовтельности должна быть не менее чем длина ключа. И дополнять ею надо ключ, а не данные.
Я не про блочные шифры, а про PKI. В идеале, достаточно и одного рандомного бита для полного изменения зашифрованных данных. Провайдер может снифать данные, но MITM едва ли станет делать (снифать проще). Опять же, если есть такие подозрения - возьми VPS хостинг, подыми там VPN сервер и лазай куда хочешь через VPN - тогда провайдер отдохнет от попыток снифать, ибо не поможет с VPN.
Спасибо за ответы. Еще такой вопрос: насколько сейчас актуальна атака MITM и методы защиты от нее? Я слышал мнения что эта атака неактуальна по причине легкой доказуемости факта подмены ключей. Можно ли доверять корневым центрам сертификации? И вообще, если два человека в сети никогда друг друга не видели и не собираются, могут ли они уверенно сказать что между ними нет атаки MITM?
Я говорю про MITM на уровне твоей сети - от тебя до шлюза, через ARP poisoning, например. То есть, если некто забьет твой ARP кеш и подменит ARP адрес шлюза своим, а затем шлюзу представится тобой, ты пойдешь через него как через шлюз (а следовательно и ключ для расшифровки блочного ключа передашь через него). Дополнительно, можно и DNS кеш тебя/твоего провайдера забить и тогда если ты по FQDN законнектишься, попадешь опять же на злоумышленика, который подменил FQDN того, к кому ты коннектился на свой айпишник. Опять же, это решается установкой VPN сервера на каком-нибудь хостинге, допускающем запуск сервера.
Доверять можно только самому себе. А нужные сертификаты я думаю центр сертификации может сделать для злоумышленика за определенную сумму. Для понижения такой вероятности, следует передать ключи несколько раз разными способами. Тоесть например по почте, через icq, через irc, через пересылку файла ключа в архиве с паролем и.т.п. Очень маловероятно, что автоматический софт для подмены ключей сумеет справиться со всеми случаями, ну а если делает это человек - то неуспеет все отследить. Но всеравно гарантировать ничего нельзя. Установка VPN сервера тоже не панацея, так как злоумышленнику будет достаточно подкупить хостера, чтобы он снифал твой трафик после впн.
Ms Rem А если, к примеру, персональный модератор тормоз, а ты будешь думать что тормоз тот, с кем ты общаешься? Хотя я был бы польщен вниманием
Или ломануть хостера Но, с другой стороны, все супернадежные алгоритмы имеют смысл, если они одинаково надежны на обоих концах канала связи. И не только канала, а в том числе и на машинах - твоей и твоего контрагента.
существует гораздо более простой метод - добавление случайных данных в начало или конец блока (salt).
Этот велосипед давно изобретен. И это даже не salt , хотя и подсолка применяется для коротких сообщений. Для любого алгоритма существуют режимы со сцеплением блоков (с обратной связью) и вектором инициализации. Их цель именно в том, чтобы одинаковые блоки открытого текста не выглядели одинаково в шифртексте...
