Задачка. 1. полное отсутствие ошибок при передаче инфы в пакете(ах) низкоскоростного канала связи (30-200 кб/c); 2. алгоритмы и полиномы восстановления битовых искажений не интересуют; 3. математики и криптоаналитики, судя по гугл-анализу говорят - CRC32 фигня. Для 100%контроля полной целостности пакетов не годятся, есть реальная вероятность такого искажения бит-потока, пакета, когда CRC32 даст НОРМУ! А это НЕДОПУСТИМО! 4. решение - пакет передается всегда равными блоками, никакой CRC не использовать, он просто шифруется, допустим AES-256 на передаче, ключ известен на приемной и передающей стороне. Сбой=отсутствие дешифрации пакета, для этого внутри пакета, помимо данных закладываем опознавательную сигнатуру, ну и некий сетевой номер, пусть это некий аналог IP. Совсем неясно, не занаю, как доказать (математически ну очень желательно) невозможность прохождения ложного (сбойного искаженного) пакета на приемной стороне? Вот про то, как невозможно, проблемно, сложно подобрать ключ, вероятность этого дела к разным криптоалгоритмам читал, находил, а как Вам задачка, так сказать с другой стороны? Аналогов не видел. Может ссылку дадите или разрулите сходу, что данное решение верно?
VaStaNi Я не совсем вкурил в задачу, но чебы не использовать какой-нибудь "сильный" хэш для каждого пакета, и соответственно вероятность "ошибки" будет настолько низка по определению этого алгоритма, что можно считать ее равно 0.
а чем AES-256 не сильный хеш??? допустим у меня 32 байта блок, в нем 24 байта DATA, а отстальное, добавочки, что говорил. Пропускаем через AES-256, далее "выплюнул" в канал. КАК ДОКАЗАТь, что приемник НИКОГДА не подхватит ЛОЖЬ? НУ пусть для злобы дня и темы ,перед глазами Япония и ее АЭС управление представится Не моделировать годами в подхвате сбоя!? А как вероятность показать? ЗЫ тут про AES так пишутhttp://diskcryptor.net/wiki/CryptoUsageRisks Код (Text): Поэтому стойким считается тот шифр, для которого пока что не придумали практичного метода взлома. Однако если такого метода ещё не придумали, то это не значит что его не придумают никогда, хотя применительно к хорошо изученным шифрам (AES, Twofish, Serpent) вероятность взлома в ближайшие 10 лет пренебрежительно мала.
VaStaNi ну смотри. надо просто посмотреть какова вероятность что при сбое биты изменятся так что хэш получится правильный. Я тебе сразу говорю что вероятность -> 0. Как доказывать мат корректно я не помню, но думаю надо рассмотреть условные вероятности для битов те P(h(1)=x1,...,h(n)=xn | d(z)=L) h хэш d данные, те мы смотрим вероятность что хэш получится правильный для измененных данных (x1,x2,..,xn) при условии что на z позиции произошел сбой, но я еще раз повторяю она стремится к 0, просто следует из "сильности" хэша. Возможно пишу бред, криптографией не когда не занимался делаю прикидки на основе тер вера.
А вот насчет никогда ответ простой НИКАК. Просто вероятность будет стремится к 0, на самом деле этого достаточно.
Да и я никогда не занимался и тем более настолько математически не покажу... Ну а показать выкладки хотелось бы, дабы сторонний суперматематический ум там некий, проверочные организации там всякие приняли однозначный вывод да стремится к нулю и на 100000.... лучше чем ... ... ... и CRC32, который вот тут вот ...., а ЭТО ДАННОЕ РЕШЕНИЕ - достойная модернизация .... Ну и самому спать спокойно, тоже нужно, зачем лишнее на себя брать
http://ru.wikipedia.org/wiki/Обнаружение_и_исправление_ошибок http://www.insidepro.com/kk/027/027r.shtml http://book.itep.ru/2/28/corec_28.htm
О чем же всё таки вопрос ? Сколько бит необходимо для гарантии незначимости вероятности ошибки ? Возьмите суммарную пропускную способность Ваших каналов (например, 16 х 200 кбит/с = 3.2 Мбит/с). Выберите период, на который Вы сделаете прогноз (например, 5 лет) - на бесконечность Вам никогда не дадут, т.к. есть экспоненциальное увеличение мощностей и пропускных способностей - даже документы по стойкости шифров рассчитываются на определенный весьма небольшой период. Рассчитайте, сколько пакетов по 32 байта будет передано, если использовать этот канал этот период времени со 100% загрузкой - (3.200.000/8/32*3600*24*365*5)=2^41 штук. Задайтесь, приемлемой вероятностью события - например 0,001 - т.е. "это вероятность того, что за 5 лет в используемых каналах связи будет хотя бы однажды не обнаружено повреждение переданных данных". И получите : 41 бит + 10 бит = 51 бит контрольной суммы необходимы Вам в каждом 32-байтном пакете для решения Вашей задачи. или Может ли внутри контейнера, защищенного блочным шифром, использоваться обычная CRC для контроля целостности (без угроз подделки CRC извне) ? Я считаю, что может, если у Вас есть ограничения по вычислительным мощностям и Вы не можете позволить по-настоящему криптостойкую сумму. Но если ключ шифрования фиксированный, то серьезно подумайте о методе создания цепочек (chaining modes), т.к. на мой взгляд OFB или CFB здесь будут не очень удачным решением. CBC - наверное, да, а лучше всего сразу искать цепочки со встроенным подтверждением целостности - таких уже разработано за последние годы много. А если содержимое пакетов однотипно, то защищайтесь еще и от replay attack, иначе Ваши пакеты не дешифруя могут "подкинуть" в канал через определенное нужное злоумышленнику время повторно.
ближе второе. Сейчас попытаюсь изложить и сформулировать еще раз ну вот тут вижу как бы что это лишнее(в смысле CRC внутри, это же доп.затраты? А эффект?), хотя если это совет, как грамотного криптоаналитика, то прислушаюсь... можно сказать и ограничения есть, т.к. вторая сторона пусть управляющие контроллеры АСУТП, пусть на AVR контроллерах, хотя и на других можно. Есть уже (нашел) сорцы ассемблерные AES на них в реализации! Режимы там всякие CFB, OFB пока смутно понимаю, вкуривать пытаюсь... Надеюсь помогут вот тут. Ну хоть ткнуть, конктерно поняв мою задачу(ниже). Типа тебе вот типа CFB надо, ключ не менее... будет толк и точка. где то толковое почитать есть? Сориенироваться не могу, что мне лучше в них, какой вот? в AES это достижимо? Опять же сорцы есть, хочется не заморачиваться. Кто такие, где читать если нет в нем этого? ну про "подкинуть", как бы не ставится задачка защищаться Хотя если учитывать всякое там перемешивание бит в крипто, то можно в пакетик данных счетчик времени, даты текущий ставить или некое время жизни пакета, как в TCP... тогда это устраняется, да? Я в нужном русле решаю проблемс этот? ИТАК. 1. Пусть необходимо максимально достоверно передать блок данных конкретному устройству в некой низкоскоростной сети. Таких устройств пусть их 30 шт. Полудуплекс. Блок данных унифицирован, т.е. известен его формат внутри, длина постоянна, пусть это 32 или 64 или 128 байт, пока решаю, как дробить на фрагменты, так сказать элементарных достоверных передач! Есть там и сетевой номер и сигнатура (будет ли верно это?) по которой собственно + номер этот сетевой - устройство понимает решение(!), что пакет дешифрирован ВЕРНО и ДАННЫЕ - это его данные! Тогда принимаем данные за абсолютную истину и ВЫПОЛНЯЕМ свою функцию по ним! Ни чужое(другого устройства), ни искаженное типа молниями, облучениями, ни магнитными бурями ни чем другим, не должно быть принято к исполнению! 2. Пусть выбрано, также, что блоки эти шифруются/дешифруются AES-256 с известным ключём по всем сетевым точкам (устройствам, включая хост или комп.) Понятно, что идеального в нашем несовершенном мире ничего нет, но! Вопрос тут в максимально достижимости устойчивости данных (ну и системы вцелом, естественно) ПОСРЕДСТВОМ КРИПТОалгоритмики, как более совершенного средства защиты целостности информации и распознания фальши(сбоев)! Понимаю так, что чем круче крипто, тем более "чувствуется" искажение любого бита в любом месте пакета в данном случае, а значит ЛОЖЬ(сбой) не пройдет, или максимально НЕ пройдет. Понятно и то, что чем лучше базовые принципы - тем лучше итог, но как, насколько не могу оценить, показать, доказать... Чувствовать мало. Может и так быть, думаю, что длина пакета влияет на результат и длина ключа(это понятно в принципе) и неоднородность данных на выявление ложного случая(сбоя)... С удовольствием выслушаю взвешенные под задачу советы, замечания, мои заблуждения быть может.
Если у тебя блок из 24 байтов, то тагда количество комбинаций равно 2^(8*24), для ЦРЦ 32 количество элементов в списке коллизий, при условии канешн што твой пакет (24 байта) не меняет размер, равно 160 - это значит в этом блоке возможно столько комбинаций которые дадут одинаковый ЦРЦ, следовательно вероятность пропущения ошибки равна 160/2^(8*24) это колосальное число у меня даже не влазит в калькулятор 2.5489470578119236432462086364286e-56, Но если тебя и эта вероятность не устраивает тагда можно взять для ЦРЦ другой порождающий полином G(x), равный допустим 24 байтам, тогда теоритически вероятность равна нулю, но! нужно учесть что и полином может так измениться что совпадет битый ЦРЦ с битыми данными, но вероятность просто фантастически маленькая, но всё же не ноль!
вот этот математически доказуемый факт очень не нравится. Потенциально. При том, что на тех же аппаратно-программных средствах, можно сделать и лучше, и устойчивее, и жестче. Т.к. доверять будем лишь одному - факту успешной дешифрации принятого пакета. Вот еще интересный для себя под задачку алгорим присмотрел - ANUBIS. Вики говорит Тут опять пишут ТОЛЬКО про уязвимость со стороны ключа. Непонятно вот почему про сами данные ни словца. Либо с данными (мутации всякие, перестановки, комбинаторика) все еще более серьезно обстоит и это даже НЕ обсуждается и НЕ доказывается в плане безопасности(и это типа только мне не понятно, а остальным все и так ясно, как Божий день), либо так сложно, что нет смысла этим заниматься... годы нужны для этого? Ну вот типа инволюции обратимы, написано. Это для аппаратуры типа просто для реализации, я так понял. А как это на устойчивости сказывается неясно. Лучше это скажем AESа или нет? Или это "на пальцах" не покажешь, суровая математика нужна... Может тут все банально получается. И если для ключа(со стороны ключа) нужно 2^127 комбинаций, допустим, то "автоматически" это означает, что для данных это значение НЕ МЕНЬШЕ? Или не факт?????
>1. полное отсутствие ошибок при передаче инфы в пакете(ах) низкоскоростного канала связи Любая нормальная хеш функция. Если задача именно о ошибках а не о злонамеренном вмешательстве.
VaStaNi В сообщении #9 OLS вроде бы достаточно ясно изложил суть, но вот анекдот по данной теме: Какова вероятность встретить на улице динозавра? 1/2 - либо встречу, либо нет. В общем тебе нужно рассуждать точно так же, если от блока данных вычислить хорошую хеш функцию длиной n бит, то все её значения сделует считать равновероятными, а вероятность что у искажённого сообщения окажется такой же хеш - 1/2^n. Если количество переданных сообщений N существенно меньше 2^n, то вероятность незамеченной ошибки можно считать равной N/2^n.
Black_mirror, спасибо за рассуждения ну вот пытаюсь определиться с понятием "хорошая" следующим образом. Получается у меня, обобщив посты следующее: 1. чем меньше блок и чем больше ключ тем лучше 2. длина пакета передачи не может быть меньше блока шифрования и очень хорошо если кратна им. Дополнение данных дописыванием байт до кратности блоку лишь улучшает достижение цели, особенно если дописывание имеет динамику и информационный, справочный смысл функционирования (текущее время передачи пакета, например) 3. по рекомендациям OLS, лучше использовать CBC mode, но при длине пакета = 1-2 блока шифрования его преимущества теряются, глядя сюда 4. при равенстве степеней полиномов в AES и Anubis, Anubis видится более выгодным под задачу, т.к. можно заюзать по п.1 ключ в 320 бит при блоке в 128 бит, возможно при этом будет плюсом, что выбор в пользу tweak для чипов малой мощности даст плюс, как упрощение в реализации программного кода... Если есть существенные заблуждения, неправильная оценка и ошибки, просьба указать. PS. Всмотревшись в блок-схемы по CBC "вижу" сетевой номер и пр. ID устройства типа серийный номер изделия... в таком чудесном блочке как: "вектор инициализации". Если это будет работать, тогда только CBC! Крутой битовый замес, а-ля "белый шум"... Вижу это, как МегаФичу при решении задачи... несладко придется хосту однако, но все для победы!
Если у Вас есть проблемы с вычислительной сложностью, возьмите в качестве блочного шифра - ГОСТ 28147-89 в качестве контрольной суммы любые 8 байт от MD2. В качестве IV в схеме CBC лучше подавать не сырые данные (время, номер пакета, сетевой номер, ID и т.п.), а уже прошедшие один цикл шифрования, чтобы убрать любые корреляции. Учтите, что IV приемная сторона должна иметь возможность узнать/вычислить, т.е. все ее части должны быть несекретными и каким-то образом передаваться на приемную сторону.
Винокуров пишет в сравнительной статье, что и ГОСТ и AES почти равны по всем статьям включая 8 битки для выполнения алгоритма... Конечный выбор видимо будет судя по сложности воплощения в жизнь в железе. это типа MAC? Или это с "другой песни"? ) Мне уже от аббревиатур этих в глазах рябит и череп сносит, начитался этой пурги...))) Или тут должен быть иной алгоритм (совсем не "родной") для первичного, так сказать преобразования открытых известных значений типа ID для получение этого вектора инициализации? В виках:
Я предлагал просто пройтись один раз тем же самым криптоалгоритмом тем же самым ключом по открытым данным, которые Вы планируете использовать в качестве IV, для того, чтобы убрать возможную явную корреляцию между битами IV (ведь с схеме CBC он (IV) накладывается на первый блок обычным XOR-ом).
Вернулся к расчету вероятности. Хотябы ориентировочный, оценочный расчет, опираясь на пост #14 вижу так. - пусть, например, битовый объем данных = ключу = хешу = 128 бит - вероятность НЕОБНАРУЖЕННОЙ ошибки НЕ белее чем 128 / 2^128 = 3,76 E-37, что практически ноль. Учитывая, что в процессе очень ответственных управленческих задач АСУ ТП хост, как правило, не ограничивается одним управляющим пакетом(приказ выполнить управление, регулирование), а требует замыкающего ответного квитирования от подчиненного(как ответ "ЕСТЬ мой генерал!"), то в итоге можно считать цель достигнутой. Т.е. 100% гарантия построения надежной системы идеологически достигнута, сабж можно считать исчерпаным.
