Нужны тестовые векторы ГОСТ 28147-89
люди, пишу реализуцию, нужны векторы на правильность простой замены и имитовставки.
![]() |
![]() |
![]() |
![]() |
|
![]() |
![]() |
||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 1515 документов: 44 редакций: 5786
Ещё один гвоздь в гроб OpenSSL или "wipe диска – так ли это просто?"
В контексте /comment39565 для настройки полного шифрования терабайтного диска его надо было заполнить случайными данными. Казалось бы, всё просто, и неоднократные советы с форума типа "юз dd и urandom" окончательно решают проблему. Что же на самом деле? Начнём с более быстрого метода – OpenSSL:
Угарно, да? Кто не верит – попробуйте ;) После ряда тестов выясняется – дело в величине числа после rand, на которое есть фундаментальное ограничение в 231-1=2Гб. У вас диск больше 2Гб? Значит, не повезло.
shred в pkgsrc отсутствует, в базовой системе – также. Вариант отпадает.
Проблему можно решить 3мя вариантами:
Был выбран 1ый вариант, как "самый простой" (в UNIX самый простой вариант – самый сложный, т.к., в конце концов, [типично] оказывается, что всё равно не работает, и потому надо было сразу браться за самый ручной и трудоёмкий способ). Итак, первый блин таков:
Он даже, кажется, работает, а по -SIGINFO, посылаемому dd, можно смотреть сколько записалось, только скорость... 2 недели для терабайтного диска – всё правильно? Проверяем скорость самого OpenSSL и скорость записи на диск:
USB-стэк? Хотя... если писать в файл на файловой системе – всё нормально:
Почему писать напрямую в device – намного медленее, чем на ФС? Синхронная запись? Или... здесь повлияло то, что объём был мал, и он влез в оперативную память? Оказалось, что дело совсем не в этом. Итак, было нарыто:
Магия?
Почему "block mode" такой ежовый? Итак, теперь в raw mode:
Без
доброжелательностиnice'а I/O будет тормозить ужасно. Оценочное время исполнения – 25 часов; не быстро, но уже приемлемо. И тут ВНЕЗАПНО:Умный openssl закрыл канал, и dd тут же вывалилось. Цикл не работает, и вот простейший пример для демонстрации (почему-то Linux'овый dd умнее и там этой проблемы нет):
Можно попробовать и так:
или вот так:
– результат тот же. Раз уж такие сложности, не вспомнить ли про рекомендованный "более медленный /dev/urandom"?
nice почти не помогает. I/O вешается почти намертво, с компом работать невозможно, кое-как прерывается, особенно при bs=128m. Да-а, с такой скоростью долго прийдётся ждать вайпа. Не вариант. Может, хакнуть OpenSSL с его 231-1-ограничением?
Есть ещё одна идея: сделать тупой арифметический цикл с оффсетами а-ля сишный for: берем кусок в гигабайт размером, пишем в него, затем переходим к следующему... например:
и запускаем:
Полёт пока нормальный – уже 49 гигов завайплено:
Решение проблемы – 2 головы и 4 часа времени, т.е. 8 человекочасов. Страшно представить, что будет, когда до LVM дойду. Вот така убунта.
Кстати, есть один быстрый алгоритм:
но его нет в системной libc, хотя имеются сторонние реализации. Способ с "15тью строчками на С", возможно, был бы быстрее.
P.S.: пора хорошим людям собраться и
убить всех плохих людейнаписать вменяемый CLI-фронтенд к криптопримитивам, а-ля mcrypt, только поменьше костылей, помодерновее, с поддержкой хэшей, PRNG, HMAC-ов (я не знаю, что еще понадобиться может), и это должны быть именно примитивы. Или, может быть, просто перл надо знать и писать на нём свои простейшие обертки вокруг OpenSSL'ных примитивов? У перла они, наверное, самые короткие будут, да и биндинги к нему уже есть.P.P.S: нет, не себе Ubuntu ставлю – просто попросили поставить user-friendly-Linux и настроить его для того, кто в Linux никакой, да так, чтоб всё свистело, да работало, как в сказке. Мой первый Linux... чтоб его...
комментариев: 9796 документов: 488 редакций: 5664
Это некриптостойкий генератор, хотя идеально проходящий все статистические тесты.
С таким же успехом можно использовать badblocks -t random.
С другой стороны, можно сначала поднять криптораздел и перед форматированием (mkfs) через dd заполнить его не медленным dd if=/urandom, а даже /dev/zero, но натравливать именно на поднятый криптораздел, чтобы нули шифровались. Конечно, противник сможет иметь больше оснований для предположении о наличии в открытом тексте раздела избыточного количества нулей, но это несущественный теоретический аспект.
Spinore, спасибо за тшательно разобранный и записанный пример, часто людям бывает лень делать подробный отчёт как для багрепорта.
комментариев: 1515 документов: 44 редакций: 5786
Так любой PRNG – некриптостойкий, а заполнить диск реальным рандомом – слишком длительная процедура, да и нужна ли? Криптостойкость — защита от предсказуемости, а не от "неслучайности". Т.е. не понятно
Это интересная идея. Не додумал(ся,ись). Но он, может быть, менее случаен?
Тоже интересно. Проверил скорость (на объёмах порядка гигабайта) – 15Mb/s, т.е. в полтора раза быстрее было бы, чем используемый метод:
С другой стороны, если запускать с nice и долго ждать, то скорость записи потом постепенно снижается. Для моего метода она сейчас чуть больше 10 мегабайт; как было бы для нулей – не ясно, но, наверное, ничуть не хуже, да и технически это сделать куда проще.
комментариев: 9796 документов: 488 редакций: 5664
Может сообщим Шнайеру и Ко, чтобы он удалил свой кандидат с конкурса SHA-3, у него же универсальный криптопримитив, в том числе со свойствами PRNG. Всем другим разработчикам PRNG тоже будет интересно знать, что PRNG бывают исключительно некриптостойкие.
В стойком PRNG на самом деле все принципы такие же, как в обычном криптоалгоритме. Он мало отличается от потокового шифра, стойкость которого задаётся ключом. Из ключа разворачивается гамма практически бесконечной длины (ну там с ограничением до 2256 байт).
Для потокового шифра достаточно, чтобы:
Или самый сильный критерий: невозможность нахождения различителя между потоковым шифром и идеализированным генератором истинно случайных чисел быстрее чем атаки грубой силой. С учётом не только простых статистических тестов, но и криптоаналитических атак на основе знания алгоритма. Ну и атаки со знанием ключа не должны показывать различие входа и выхода с идеальной моделью, куда же теперь без них. Атак на тексты нет (он тупо ксорится, как в одноразовом блокноте, поэтому анализируют только гамму).
Чтобы не было путаницы в терминологии можно привести и критерий отличия PRNG от потокового шифра:
В PRNG как такового ключа нет и не нужно (поскольку не нужно ничего расшифровывать обратно). Есть заполнение первоначального внутреннего состояния какими-то случайными данными. Это состояние регулярно необратимо перетирается. Данные о предыдущих использованных внутренних состояниях уничтожаются. Если даже произойдёт взлом, то восстановление последующей гаммы PRNG более вероятно, чем восстановление предыдущих состояний (более сильная непредсказуемость влево по сравнению с потоковым шифром). Это свойство PFS (Perfect Forward Security), а под взломом может иметься ввиду не только криптоаналитический взлом, но и то что противник получил доступ к памяти и узнал внутреннее состояние генератора. Тогда всю последующую гамму он предскажет, но всё равно не предыдущую (в отличие от потокового шифра). В отдельных случаях — малый кусок предыдущей из-за определённого размера буфера внутреннего состояния.
То есть, данные из /dev/random инициализируют /dev/urandom и в принципе /dev/urandom должен был быть криптостоек (если бы его грамотно проектировали, но к сожалению это не так ). По крайней мере это живой более-менее криптостойкий PRNG (есть практические тонкости из-за которых он может фэйлить: неправильное обновление /var/lib/urandom/random-seed, неправильный порядок запуска в скриптах загрузки при полнодисковом шифровании, чем страдали некоторые системы).
На самом деле /dev/urandom из имеющегося — лучшее, что есть и доверить ему генерацию каких-либо кратковременно действующих ключей оправданно.
Надеюсь понятно, что не оксюморон, выше дано простое определение. Но для заполнения терабайта именно криптостойкий PRNG действительно (почти) не обязателен. Однако может быть вот что: представим, что раздел заполнили некриптостойким легко взламывающимся PRNG. По фрагментам гаммы его можно различить и составить карту незаполненных и заполненных участков (где в контейнере уже что-то есть) и раздел будет выглядеть почти как если бы его и не заполняли. Т.е. истинные параноики или используют /dev/urandom перед поднятием криптораздела или /dev/zero или хотя бы слабый генератор после его поднятия (из badblocks, shred, wipe — один проход заполнения без затирания). Openssl значит здесь не нужен (и как бы провоцирует жестокий оффтопик на тему дискового шифрования), раз он валится после двух гигов.
комментариев: 9796 документов: 488 редакций: 5664
/dev/random быстро исчерпается и не будет выдавать следующие блоки данных, пока не получит энтропии от системы (это можно посмотреть в /proc/sys/kernel/random/entropy_avail). На несколько килобайт хватит, а дальше надо ждать и стучать по клавишам.
/dev/urandom не блокируется при нехватке энтропии в системе и может работать только от предыдущих состояний.
комментариев: 11558 документов: 1036 редакций: 4118
При наличии аппаратного ГСЧ ситуация будет несколько лучше, /dev/random может выдавать поток даже быстрее, чем urandom.
Могу скинуть ссылку, но напиши тогда свою почту.
Если пишу значит знаю о чем пишу.
Вот я решал задачку:
https://www.pgpru.com/forum/kr.....mogitesdelatjzadanie
вот еще одна
https://www.pgpru.com/forum/kr.....a/rasshifrovkateksta
и т.д.
И в этом плане поддерживаю админа, который удаляет левые ссылки.