Сильную криптографию в массы!

"но пока шифрует только в режим простой замены" По другому не получится. Вот если делать шифрованую файловую систему(и обрубить у не операцию seek - как очень ресурсоемкую)...

IMHO этот алгоритм можно ускорить в несколько (десятков?)раз. При желании и наличии лишней памяти.

Херню сморозил-с.

Действительно, в пределах 1-2х блоков устройства могли бы что-то придумать. Тогда бы им seed нужен был бы меньшего размера :-) Cтоит ли овчинка выделки?

Мдяя и раньше тормозной был и сейчас :) Но защита сильнА.. :) Попробуем-сс... :)

> Мдяя и раньше тормозной был и сейчас Ну ты сделай не тормозной - XOR побайтно и не на что жаловаться будет :)) Либо сильное шифрование, либо высокая скорость, компромисса здесь не может быть.

где-то я ето уже читал ....
http://www.kerneli.org/cryptoapi/howto/cryptouser.pdf

Когда я был молодым и глупым(копирайт не мой) мне казалось, что я написал этот же алгоритм, работавший со скоростью около 150Кбайт в секунду на i486 33MHz. Правда, я использовал около 2Мб памяти для таблиц замены.

Так что либо время шифрования либо используемая память.

>Недоступность данных при отсутствии ключа и бэкапа гарантируется :-)
Нашли чему радоваться. У меня вот на winXP, что есть ключ, что нет ключа - всегда можно данные открыть! И без труда. И бекапа там нет, потому как бекапь, не бкапь - все равно все с дистрибутива переустанавливать. И где после этого ваша хваленая надежность линукса?

>Нашли чему радоваться. У меня вот на winXP, что есть ключ, что нет >ключа - всегда можно данные открыть!

Это теперь плюс системы защиты? :))))))

Так. Читаем стандарт на 28147-89.

Из него следует, что (пп. 1.7, 2.4) режим простой замены
допускается использовать только для зашифрования ключей
(случайных последовательностей) длиной не более 8 байт.

Теперь. В описании алгоритма есть такие слова:

1. Над исходными данными и изменяющей посылкой побайтно
производится операция XOR (исключающее или), при
этом синхропосылка используется циклически.
2. Результат, полученный после выполнения шага 1
фрагментами по 8 байт зашифровывается на ключе и
узле замен и записывается на диск

Рассмотрим такой xor с блоком нулей. Дальше - продолжать?
Расстояние единственности для простой замены - 8 байт
(это-так, для справки).
Как будут выглядеть несколько блоков нулей, зашифрованных
подобным образом? Ответ - одинаково.
И в чем же смысл маскирования?

Так что криптография действительно, "сильная" !
В общием, взяли хороший алгоритм и опошлили идею.

Regards!
GNS

Что-то я вас не догоню - если на нулевой блок наложить ваш хваленый ХОР, то получим ключ шифрования в явном виде, который можно даже по Ф3 в миднайт цумандере посмотреть? О чем речь?! - чем проще и быстрее криптовая математика тем легче она раскручивается. Быстрее разве что может быть только специальное криптующее оборудование и то натренированое на нивхребенный ключик и опупенным уровнем вложенности математики. И вообще - нет гарантии того что этот ключ той же математикой не раскрутят - уже давно есть мат. методы которые позволяют все это сделать. Дружно все рубим себе на носу что если есть "производная" - значит есть и ее "отображение". Любую функцию можна разложить в ряды, для элементов которых можно найти их обратные отображения. Подставляем в производный ряд ваши криптованые-нахер перекриптованые данные и получаем ваши данные в явном виде какой бы сложный алгоритм криптования ни был. Ну станок для разложения ваших закриптованых потоков должен быть дастатачна моцный. В россии таких нету, а вот у дяди сэма - есть. Так что криптуйте, перекриптуйте скока влезет - всеравно раскрутят :)))

64 битные ключи уже давно колупают как семечки, а вот на 128 пока мощностей не хватает. Здря чтоли янки на DES и пр. орут что юзинг аутсайд оф ЮС из прохабитет? - раскручивать-с не успевают-с :)))

К моему предыдущему письму следует сделать замечание.
Утверждение о двух зашифрованных блоках, выглядещих одинаково
верно только если размер seed'a меньше размера блока.

При использовании seed'a равного по длине размеру блока,
последовательные замаскированные описанным образом
и зашифрованные нулевые блоки будут, конечно различаться.
Но, как минимум, алгоритм не стоек к атаке "выбранным открытым
текстом".

Опять-таки, из описания не понятно, как вычисляется величина
сдвига seed'a при операции записи/чтения блоков?
Как функция номера блока?

Если это так, то можно вычислять значение синхропосылки
(в смысле начального заполнения в режиме гаммирования)
как функции номера блока и еще чего-либо. Того же случайного
seed'a, например. После этого, можно пользоваться честным
гаммированием.

Утверждение, что гаммировать можно только каждый блок
по отдельности верно. Но почему из этого делается вывод,
что нельзя использовать режим гаммирования вовсе?

Стоит поспотреть как реализовано шифрование swap-партиции в
OpenBSD. IMHO, сходная задача.

Regards!
GNS

Первое: читая собственно гост, про блочную замену видим только фразу "позволяется зашифровывать только ключевую информацию". 8-байтами здесь и не пахнет. Более того, такая фраза значит "96 байт" - в точности ключ+узел замен. Ошиблись в 12 раз :-) Это раз. Теперь два: для атаки с известным открытым текстом в вашем распоряжении не так уж и много исходных данных: суперблок FS и блок нулей. Все хреновей и хреновей, верно? А то, что собственно в ГОСТ подаются совсем не 512-байтные блоки нулей, а 512-байтные блоки хрен-знает-чего (нули "сксоренные" с искажающим блоком) сделает вашу жизнь еще более "приятной и пушистой", ведь это еще 4096 двоичных неизвестных в систему уравнений :-) Впрочем, здесь нужны профессионалы, только они дадут точный ответ. Ну и напоследдок три: гаммирование с обратной связью автоматически означает перешифрование всех блоков следующих за текущим, а без обратной связи даст если не худший, то и не лучший результат с учетом большого количества фрагментов гаммы, особенно при незначительном заполнении девайса.

>особенно при незначительном заполнении девайса.

Собственно сама идея шифровать тучу нулей и управляющую информацию файловой системы кажется неразумной. Лучше уж файлы - почти наверняка можно обеспечить отсутствие информации для анализа зажав данные. И гаммирование почти всегда будет возможно.

"Не сразу все устроилось..." - так кажется в песне было?

>Первое: читая собственно гост, про блочную замену видим только >фразу "позволяется зашифровывать только ключевую информацию". >8-байтами здесь и не пахнет. >Более того, такая фраза значит "96 байт" - в точности ключ+узел >замен. Ошиблись в 12 раз :-) Это раз.

Согласен. Ошибку в 12 раз признаю. Имелся ввиду размер блока одного раунда шифрования. Погорячился. Но,- 32 байта - случайных с датчика и 64 - непонятно каких и общих для "сети ЭВМ". Но шифрование "упрядоченных" данных - недопустимо и про это явно сказано. Но это - так. Формальность.

>Теперь два: для атаки с известным открытым текстом в вашем >распоряжении не так уж и много исходных данных: суперблок FS и блок >нулей.

Неправда Ваша :). В моем распоряжении Ваш алгоритм, Ваш диск (весь, доступный посекторно), мой диск для экспериментов и незнание Ваших ключей. Таковы стандартные условия анализа.

>Все хреновей и хреновей, верно? >А то, что собственно в ГОСТ подаются совсем не 512-байтные блоки >нулей, а 512-байтные блоки хрен-знает-чего (нули "сксоренные" с >искажающим блоком) сделает вашу жизнь еще более "приятной и пушистой", >ведь это еще 4096 двоичных неизвестных в систему уравнений :-) >Впрочем, здесь нужны профессионалы, только они дадут точный ответ.

А кто вообще сказал, что жизнь криптоаналитика легка и приятна? :)))

>Ну и напоследдок три: гаммирование с обратной связью автоматически >означает перешифрование всех блоков следующих за текущим, а без

Не факт. Можно рассматривать каждый блок как новый текст и производить генерацию гаммы для каждого блока заново с новой синхропосылкой.

>обратной связи даст если не худший, то и не лучший результат >с учетом большого количества фрагментов гаммы, особенно при >незначительном заполнении девайса.

Да, пожалуй верно. Стат. анализ большого числа кусков гаммы может многое прояснить. Терзают меня смутные сомнения, что и Ваш способ с маскированием хуже гаммирования. Хотя-бы из-за периода гаммы.

А, кстати, что происходит с неиспользованным местом на девайсе? Оно так же шифруется или "пустые" блоки остаются незашифрованными? Если шифруются и на них - FF-ы (ну диcк был новый, или вчера отформатированный :)), то это еще огромадное поле для исследований. Кстати, за FF - не помню. но. по-моему, низкоуровневый формат записывает какой-то стандартный паттерн во все сектора).

Ну, во-первых сильная криптография уже давно в массах, так что название топика чем-то воняет.
Во-вторых реализация GOST как раз наиболее применима в подневольных госучреждениях, а не в массах ;-)
В-третьих, что есть GOST? Аналог DES.
А в четвертых, для масс (а так же для правительства США) уже давно работают
неплохие реализации AES (Rijndael), в частности для линукс давно доступен модуль loop-AES.
Прекрасно работает, и не надо нам этих гостов. А судя по бенчмаркам он примерно вдвое быстрее GOST.
Ну и напоследок... где-то я видел реалицацию шифрования/дешифрования GOST в виде 6 строчек на perl.
Медленно, но зато точно для масс ;-)

Ну во первых, ГОСТ будет по устойчивей ДЭСа.
Во вторых, данный алгоритм действительно предназначен для шифрования таблицы перестановок + новый ключ. Так определили в ГОСТе люди, которые умнее меня, и я склонен им доверять.
И третье, относительно использования в массах. ИМХО использование алгоритмов ГОСТА предполагает лицензирование. Т.е. если ты сам для себя что-то шифруешь компетентным органам вроде дела нет, но вдруг ты масхадовским боевикам наводку на новые дома даешь :)?
Как дело обстоит с этим - может кто просветит? А то я уже давненько к закрытым работам не причастен, могу быть не в курсе новых веяний...

Для anonymous (*) (2002-08-09 05:40:32.667)

>GOST? Аналог DES.

Все автомобили аналогичны. В гораздо большей степени, чем ГОСТ аналогичен DES...

ГОСТ скорее аналог AES. По скорости-стойкости. Недостаток у него один - отсутствия критериев выбора подстановочных таблиц. Посему (видимо) доверять ему можно только если кто-то из лобастых криптоаналитиков их тщательно проверит на предмет отсутствия возможности каких-либо типов анализа.

А про скорость - кол-во операций при шифровании у них тоже довольно похожие. Так что большой выигрыш в скорости получится только если в аппаратной реализации один из алгоритмов лучше распаралеливается.

>Ну станок для разложения ваших закриптованых потоков должен быть дастатачна моцный. В россии таких нету, а вот у дяди сэма - есть.

Загляни-ка сюда, плиз: http://www.jscc.ru/

В общем, сейчас я занимаюсь версией 1.0.3, в которой будет реализовано гаммирование с обратной связью в рамках одного блока. Скоро будет, надеюсь :-)

> Все автомобили аналогичны. В гораздо большей степени, чем ГОСТ аналогичен DES...

Нашел интересное неформальное описание GOST:

GOST is a cryptographic algorithm from Russia that appears to be the Russian analog to DES both
politically and technologically. Its designers took no chances, iterating the GOST algorithm
for 32 rounds and using a 256 bit key.

Although GOST's conservative design inspires confidence, John Kelsey has discovered a key-relation
attack on GOST, described in a post to sci.crypt on 10 February 1996. There are also weak keys in GOST,
but there are too few to be a problem when GOST is used with its standard set of S-boxes.

> ГОСТ скорее аналог AES.
Можно хоть одну ссылочку на тех, кто еще так же думает?

> А про скорость - кол-во операций при шифровании у них тоже довольно похожие.
И на это высказывание хотелось бы увидеть хоть один линк с цифрами или графиками.
До сих пор было известно лишь то, что по скорости GOST равносилен DES, а DES в свою
очередь примерно вдвое тормознее AES.

У вас какие-то дикие цифры, анонимус... AES быстрее чем DES раз этак как минимум в 10 - почитайте описания алгоритмов, и все увидите.

Почитать описания? Я предпочитаю сравнения реальных реализаций.
Если AES быстрее чем DES раз этак как минимум в 10, то тогда на ваших тестах
AES должен быть быстрее GOST не менее, чем в те же 10 раз...
А вообще, я так и не увидел линка на цифирь с живыми бенчмарками ;)

Анонимус, сравнивать надо количество и порядок количества операций, а не реализации...

2no-dashi (*) (2002-08-11 22:41:36.612)

Вот тебя и просили в связи с этим дать линк на авторитетный источник, где
проводились подобные сравнения. А ты продолжаешь вилами по воде писать.

[root@main loop-GOST-1.0.2]# ./configure Использовать упрощеное шифрование (y/n) [n] Путь для инсталяции glosetup [/usr/bin]: Для какого ядра компилировать модуль [2.4.18-3smp] [root@main loop-GOST-1.0.2]# ./make all bash: ./make: No such file or directory [root@main loop-GOST-1.0.2]# make all make module make[1]: Вход в каталог `/install/Crypt/loop-GOST-1.0.2' gcc -nostdinc -I- -I. -I/usr/lib/gcc-lib/i386-redhat-linux/2.96/include -I/lib/modules/2.4.18-3smp/build/include -D__KERNEL__ -DMODULE -c -o loop-gost.o loop-gost.c make[1]: Выход из каталог `/install/Crypt/loop-GOST-1.0.2' make glosetup make[1]: Вход в каталог `/install/Crypt/loop-GOST-1.0.2' gcc -o glosetup glosetup.c make[1]: Выход из каталог `/install/Crypt/loop-GOST-1.0.2' [root@main loop-GOST-1.0.2]# make install cp loop-gost.o /lib/modules/2.4.18-3smp/kernel/drivers cp glosetup /usr/bin depmod -a -F /boot/System.map-2.4.18-3smp 2.4.18-3smp depmod: *** Unresolved symbols in /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o make: *** [install] Ошибка 1

Где ошибка-то? [root@main loop-GOST-1.0.2]# modprobe loop-gost /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o: unresolved symbol loop_register_transfer /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o: unresolved symbol loop_unregister_transfer /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o: insmod /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o failed /lib/modules/2.4.18-3smp/kernel/drivers/loop-gost.o: insmod loop-gost failed

Да, в loop-gost.o 00000e20 t __memcpy 00000000 ? __module_kernel_version 0000001b ? __module_license 00000040 ? __module_parm_desc_max_loop 00000027 ? __module_parm_max_loop 000007d8 T cleanup_module 00000000 t gcc2_compiled. 000012cc t get_current 000007d8 T gost_exit 00000004 D gost_func 000006ac T gost_init 000004f0 T init_gost 000006ac T init_module 00000214 T ioctl_gost 00000004 C keys U kfree U kmalloc U loop_register_transfer U loop_unregister_transfer 00000000 d max_loop U printk 00000558 T release_gost 00000004 C seeds 000008e0 T swap 00000000 T transfer_gost

Что я не так сделал, только по проще объясните, пожалуйста.

Вы невнимательно прочли README (шутка с долей правды). На самом деле такая ошибка возникает в случае, если у вас отключен модуль поддержки loop-устройств, то бишь вы не указали этот драйвер при конфигурации ядра. Обычно это делается указанием CONFIG_BLK_DEV_LOOP=m или CONFIG_BLK_DEV_LOOP=y в /usr/src/linux/.config
Спасибо за сообщение, этот баг будет отнесен к багам Makefile и будет исправлен в версии 1.0.3 :-)
Если не секрет, какой дистрибутив?
Пересобирали ли вы ядро самостоятельно?

Куда уж более "авторитетный" источник, чем собственно алгоритм??? Почитай Шнайера, у него много чего написано по этому поводу. Еще можешь поискать где-нибудь описание BlowFish'а (оно открыто и бесплатно, в т.ч. с примером) - так вот ГОСТ очень похож на него (64-х разрядный, +схема Фейстеля, принципиальная разница только в количестве циклов - 16 у рыбки и 2 у госта). А про BlowFish говорится, что он в несколько десятков раз быстрее DES'а (там же в описании). Напоследок - кинь в меня своим мылом, когда закончу со следующей весией - приведу тебе оптимизированный код ГОСТ'а, а потом ты посмотришь где-нибудь на код DES'а и почувствуешь разницу. На всякий случай поясню, что ГОСТ - это:

Цикл по i от 1 до 32
Сложение двух 32-битных целых
Циклический сдвиг 1-го 32-битного целого
4 замены по 1 байту каждая вида a[0]=b[a[0]];
XOR 2-х 32-битных блоков
Обмен местами двух 32-битных блоков
Конец цикла.

Что может быть быстрее???

Кстати, могу помочь с, на мой взгляд, довольно быстрой реализацией ГОСТ (простая замена с расширением узла замены до двух килобайт и гаммирование с обратной связью), оттестированной на SPARC и INTEL. Проблемы с big- и little-endian решены.

Сделать совместимую реализацию режима гаммирования мне пока не удалось. Если надо - пишите на e-mail в регистрационных данных.

Ядро не пересобирал (RH7.3), делел make menuconfig - стояло CONFIG_BLK_DEV_LOOP=m, но после того, как поставил y вместо m, то все установилось - проблема появилась следующая: mke2fs /dev/loop0 пишет: Devise size repoted to be zero.Invalid partition specified, or partition table wasn't reread after running fdisk ... и т.д. Да, вопрос: что делается при "очистке от мусора" (см. readme.txt) dd if=/dev/zero of=/dev/zero bs=1024 count=256 ? Почему count=256?

Получилось. Это моя не первая попытка установить закрытую файловую систему на RH7.2-7.4. Сразу говорю, что в Linux я разбираюсь не очень. Что хотелось бы сказать: 1.Если устройство loop включено, как модуль - ничего не работает. 2.В инструкции неплохо было бы в примере указать, что файл, который обращается в блочное устройство надо создавать только командой dd, и при этом все директории в которых создается этот файл должны быть созданы заранее (мне как начинающему было не понятно с первого раза). 3.Пояснить опцию count=256 при "очистке мусора" - почему 256? 4.Рассказать как более-менее автоматизировать процесс монтирования файловой системы при перегрузке (питание пропало и т.п.) с учетом того что необходимо использовать дискету с ключем - иначе мы имеем продукт для личного использования и с трудом применимый в офисе. Хотя, в последнем пункте я могу быть и не прав.

Последовательность действий:
1. Для начала проверить, что поддержка loop-устройств вообще есть в ядре - последовательно проделать следующие шаги.

dd if=/dev/zero of=/tmp/myfile count=100

modprobe loop -- если ругается, пишем на листок букву "a"

losetup /dev/loop0 /tmp/myfile -- если losetup выругался, то пишем на тот же листок еще и букву "б"

Теперь смотрим - если написано "aб" - то предстоит пересборка ядра :-(, если написано "а" - то драйвер статически зашит в ядро, если ничего не написано, то драйвер зашит модулем, если написано только "б" - то забыли в самом начале теста сделать losetup -d /dev/loop0 :-)

2. Сделать ./configure; make ; make install для loop-GOST
3. dd ... ; modprobe loop-gost; glosetup ... ; dd <опции для очистки мусора>

Что такое "очистка мусора": после расшифрования "полностью нулевой" цепочки (которая генерируется dd) получается ну такая белиберда, что драйвер ext2, например, даже после сделанного mke2fs в перепуге пищит, что это совсем не ext2. Для этого мы и забиваем loop-устройство нулями, которые зашифровываются и превращаются в нечитаемую последовательность в файле на диске (которая позже расшифруется в исходные данные) - так что и нам спокойно, и драйвер ext2 рад...

4. Автомонтирование... Лучше пошлите на dalth@mail.ru свой почтовый адрес и вопрос, и я отвечу вам по почте.

2gns: Спасибо, я уже реализовал такую же методику пару дней назад :-) Тоже развернутый массив, в котором матрица замен и хранится, и также рещены проблемы с порядками байтов :-)

> Куда уж более "авторитетный" источник,

Опять избегаем прямого ответа, либо этого ответа не существует...
Я все еще пытаюсь вытянуть из тебя хоть какой-то источник, который хоть
как-то подтвердил твои _слова_ про десятикратное преимущество в скорости GOST
по-сравнению с DES.

Вот тебе намек на то, что от тебя ожидается:
http://www.randombit.net/misc/x86_comp.php

У меня есть несколько источников, и нигде GOST по скорости не лучше DES...

anonymous, ты уже достал - при софтварной реализации ГОСТ может быть медленнее ДЕСа только если его специально замедлять. Цитата: "В силу намного большей длины ключа ГОСТ гораздо устойчивей DES'а к вскрытию "грубой силой" - путем полного перебора по множеству возможных значений ключа. Функция шифрования (*) ГОСТа гораздо проще функции шифрования DES'а, она не содержит операций битовых перестановок, коими изобилует DES и которые крайне неэффективно реализуются на современных универсальных процессорах (хотя очень просто аппаратно - путем разводки проводников в кристалле или на плате). В силу сказанного, при вдвое большем количестве раундов (32 против 16) программная реализация ГОСТа на процессорах Intel x86 более чем в 2 раза превосходит по быстродействию реализацию DES'а. Естественно, сравнивались близкие к оптимуму по быстродействию реализации". (с) г. Винокуров

anonymous, зайди на http://www.enlight.ru/crypto/ - там есть pdf статьи, в которой сравнивается ГОСТ и AES (Rijndal). Разница в скорости у них составляет ~20% уж во скольку раз AES быстрее DES'а, ты сам найдешь, заколебал уже...