Компания Cisco открыла (http://blogs.cisco.com/security/open-sourcing-fnr-an-experim... исходные тексты экспериментального предметно-ориентированного блочного шифра FNR (http://eprint.iacr.org/2014/421) (Flexible Naor and Reingold), предназначенного для шифрования таких объектов (до 128 бит), как номера кредитных карт, IPv6/IPv4/MAC-адреса, номера сетевых портов, короткие строки и числовые значения. Код библиотеки с реализацией FNR опубликован (https://github.com/sashank/libfnr) под лицензией LGPLv2.1. Ключевым назначением FNR является обеспечение анонимности данных телеметрии и записей в логах.Отличительной чертой FNR от таких шифров, как AES, является отсутствие необходимости дополнения блоков до номинального размера (padding (http://ru.wikipedia.org/wiki/%D0%A0%D0%B... что позволяет обеспечить неизменность размера данных до и после шифрования. Указанная особенность FNR позволяет интегрировать поддержку шифрования в существующие системы, рассчитанные на фиксированные размеры полей, например, в NetFlow коллекторы. FNR также можно использовать для шифрования фиксированных полей в пакетах и реализации систем шифрования данных в БД, подобных cryptdb (http://css.csail.mit.edu/cryptdb/).
В частности, при использовании AES 256 размер блока на выходе составит 32 байта, даже если шифрование применялось к IPv4-адреcу, размер которого 4 байта. Подобное увеличение размера становится критичным при обеспечении шифрования отдельных параметров в логах. В случае FNR зашифрованный IPv4-адреc по-прежнему будет занимать 4 байта.
FNR продолжает развитие идей Мони Наора (Moni Naor) и Омера Рейнголда, предложивших переработанный вариант классического метода построения блочных шифров на основе сети Фейстеля (http://ru.wikipedia.org/wiki/%D0%A1%D0%B... в котором для обеспечения дополнительной рандомизации и защищённости предлагалось использовать две попарно-независимые перестановки на первом и последнем раунде формирования LR-конструкций (PWIP, pair-wise independent permutation). Проблема метода Наора и Рейнголда заключается в применении функции PWIP, основанной на теории конечного поля Галуа (http://ru.wikipedia.org/wiki/%D0%9A%D0%B... которая достаточно сложна в реализации для входных данных разного размера (GF(2^n)). Для обхода данной проблемы в FNR функции PWIP основаны на случайных инвертируемых матрицах "N X N".URL: http://blogs.cisco.com/security/open-sourcing-fnr-an-experim.../
Новость: http://www.opennet.me/opennews/art.shtml?num=40060
Последний абзац походу зашифрован
Кичитесь своим незнанием?
Являются ли числа Фибоначчи полем Галуа?
Все - нет. Любые на выбор - да.
Учитесь дети: вот так выглядит ответ настоящего математика. Возможно даже программиста.
Ага,...
- Какая вероятность встретить динозавра на улице?
- 50/50!
- ?!%^$@#$&^*???
- Либо встретишь, либо нет!
Походу программисты-ремесленики. До программиста-инженера высшего образования не хватает... :)Хмм а у меня то в дипломе, я уж и забыл - программист-математик, специализация: прикладная математика.. А щас чего в дипломах то пишут?
Кроме записи в дипломе и расчёсанного ЧСВ, чем конкретным можешь ещё похвастать ?
у меня-то
в дипломах-то
> у меня-то
> в дипломах-то..
> Хмм а у меня то в дипломе, я уж и забыл - программист-математик, специализация: прикладная математика..Дюже! Азъ по грамоте, изтъупился - доблемудрый-разлогатый, положенный: заручная разлога.
> Хмм а у меня то в дипломе, я уж и забыл - программист-математикА в форуме профайл - "овоща-тормоза".
> Последний абзац походу зашифрованДа, его понимают только те кто интересовался криптографией. И алгоритм на основе сетей Фейстеля - далеко не предел мечтаний. Большинство независимых криптографов нынче предпочитает иные схемы, более стойкие и более быстрые. А криптоанализ этой штуки где?
И если кому padding мешал, arcfour и подобные поточные шифры уже давным-давно придумали. Правда, там свои проблемы обнаружились. Но есть пофикшенные варианты, не страдающие проблемами оригинала.
> И если кому padding мешал, arcfour и подобные поточные шифры уже давным-давно
> придумали. Правда, там свои проблемы обнаружились. Но есть пофикшенные варианты, не
> страдающие проблемами оригинала.собственно, есть salsa, есть rabbit. переданы eSTREAM, свободны, быстрые. ни для одного пока полноценных атак не найдено. для железа есть eSTREAM hardware profile. но у них всех, само собой, Фатальный Недостаток.
ну скажем так для NetFlow коллекторов это не настолько нужо, а сам шифр FNR интереснный но к сожалению для него нет много данных, я тут от том как он например реагирует на всакий сайд чанел при 12+ раундов , тут думаю паул кохер потирает ручки. Тем боле что измерить время работы функций в софте легче. Я уж не говорю о том что на сайте они дают сравнения FNR в ECB а не CBC.
для NetFlow-коллекторов
.
> для NetFlow-коллекторовДля
И что, использовать такой алгоритм выгоднее, чем, допустим, тот же гост-28147 с его размером блока в 8 байт? Тем более, что для фиксированной длины поля добавить/отбросить заранее известное число байт не должно составить проблему.
Тем что объем данных при шифровании не увеличивается, а для логов это важно.
И еще рекомендую подумать на тему влияния ваших добавочных байтов на криптостойкость.
Идея FNR хорошая, мне нравится.
Сплю и вижу, как буду это использовать там и сям.
Но! Меня терзают смутные сомнения, что какой-то негодяй будет на вход подавать числа от 0 до (2^32)-1 и получит всё распределение, почитав выход.Надо юз-кейс поглядеть, что именно этим защищают. Кредитки выглядят весьма полезно, как юз-кейс, их сложно использовать как открытый тест на входе, в силу того, что обертывающих алгоритмов вокруг этого шифрования будет гора с кучкой сверху.
Факт подбора кода выявят очень быстро и прищемят злоумышленнику что-нибудь важное дверью холодильника на собственной кухне.
aга согласен, оссобенно когда довавычные рандом байты в начале первого цикла, вроде IV's инициализированный нулями а мы храним милиард строк статистики вроде "http://www." ну ту подарки прямо с небо падают.
> Идея FNR хорошая, мне нравится.И чего там такого хорошего?
В смысле, что есть определённый формат строки лога, в которой надо 4 байта IP-адреса заменить ровно на 4 байта, чтобы "в табличке всё не съехало"? Ну, может быть в этом и есть смысл...
Если паддить по-настоящему случайными, то, полагаю, положительно.
> В частности, при использовании AES 256 размер блока на выходе составит 32
> байта, даже если шифрование применялось к IPv4-адреcу, размер которого 4 байта.Ась? Размер блока в AES 16 байт. Откуда у вас 32?
... размер блока на выходе
> ... размер блока на выходеУ AES и на входе, и на выходе блок 16 байт.
>> ... размер блока на выходе
> У AES и на входе, и на выходе блок 16 байт.Key sizes of 128, 160, 192, 224, and 256 bits are supported by the Rijndael algorithm,
but only the 128, 192, and 256-bit key sizes are specified in the AES standard.Block sizes of 128, 160, 192, 224, and 256 bits are supported by the Rijndael algorithm,
but only the 128-bit block size is specified in the AES standard.
И в каком месте он соврал? Rijndael - суперсет AES. Он говорил про AES. Так что все честно.
В новости написано про AES256, но анонимуз прочёл только первый три буквы."... в частности, при использовании AES 256 размер блока на выходе составит 32 байта, ..."
> . . . but only the 128-bit block size is specified in the AES standard.Павлик, подели 128 на 8 и дай нам знать о результатах.
>> . . . but only the 128-bit block size is specified in the AES standard.
> Павлик, подели 128 на 8 и дай нам знать о результатах.
>... Key sizes of 128, 160, 192, 224, and 256 bits are supported by the Rijndael algorithm,Аноник, прочитай новость по буквам и подели найденную цифру, рядом с буквами AES, на 8,
и дай нам знать о результатах.
Cледи за руками:
число "рядом с AES" -- 128, 192 или 256 -- это длина ключа в битах;
размер блока в AES -- 16 байт вне зависимости от длины ключа.
> Аноник, прочитай новость по буквам и подели найденную цифру, рядом с буквами
> AES, на 8,
> и дай нам знать о результатах.Павлик, не путай блину блока данных и длину ключа. Вот товарищ выше тебе уже всё растолковал.