id: Гость   вход   регистрация
текущее время 18:57 07/08/2020
Автор темы: Гость, тема открыта 15/07/2008 17:07 Печать
Категории: криптография, инфобезопасность, алгоритмы, симметричное шифрование
https://www.pgpru.com/Форум/Криптография/НужныТестовыеВекторыГОСТ28147-89
создать
просмотр
ссылки

Нужны тестовые векторы ГОСТ 28147-89

люди, пишу реализуцию, нужны векторы на правильность простой замены и имитовставки.



 
На страницу: 1, 2, 3 След.
Комментарии
— unknown (29/05/2010 11:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Да, разработку утилит они вообще хотели свернуть, оставив только либу.
— spinore (06/06/2010 04:03, исправлен 06/06/2010 04:05)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786

Ещё один гвоздь в гроб OpenSSL или "wipe диска – так ли это просто?"


В контексте /comment39565 для настройки полного шифрования терабайтного диска его надо было заполнить случайными данными. Казалось бы, всё просто, и неоднократные советы с форума типа "юз dd и urandom" окончательно решают проблему. Что же на самом деле? Начнём с более быстрого метода – OpenSSL:



Угарно, да? Кто не верит – попробуйте ;) После ряда тестов выясняется – дело в величине числа после rand, на которое есть фундаментальное ограничение в 231-1=2Гб. У вас диск больше 2Гб? Значит, не повезло.


shred в pkgsrc отсутствует, в базовой системе – также. Вариант отпадает.


Проблему можно решить 3мя вариантами:

  1. Писать арифметический цикл на bash для OpenSSL.
  2. Компилить прогу.
  3. Самому писать на C код, использующий libc'шный random и мануально затирающий диск.

Был выбран 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 дойду. Вот така убунта.


Кстати, есть один быстрый алгоритм:

The Mersenne twister is a pseudorandom number generator developed in 1997 by Makoto Matsumoto and Takuji Nishimura[1] that is based on a matrix linear recurrence over a finite binary field F2. It provides for fast generation of very high-quality pseudorandom numbers, having been designed specifically to rectify many of the flaws found in older algorithms.

но его нет в системной libc, хотя имеются сторонние реализации. Способ с "15тью строчками на С", возможно, был бы быстрее.


P.S.: пора хорошим людям собраться и убить всех плохих людей написать вменяемый CLI-фронтенд к криптопримитивам, а-ля mcrypt, только поменьше костылей, помодерновее, с поддержкой хэшей, PRNG, HMAC-ов (я не знаю, что еще понадобиться может), и это должны быть именно примитивы. Или, может быть, просто перл надо знать и писать на нём свои простейшие обертки вокруг OpenSSL'ных примитивов? У перла они, наверное, самые короткие будут, да и биндинги к нему уже есть.


P.P.S: нет, не себе Ubuntu ставлю – просто попросили поставить user-friendly-Linux и настроить его для того, кто в Linux никакой, да так, чтоб всё свистело, да работало, как в сказке. Мой первый Linux... чтоб его...

— unknown (06/06/2010 20:58, исправлен 06/06/2010 21:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это некриптостойкий генератор, хотя идеально проходящий все статистические тесты.
С таким же успехом можно использовать badblocks -t random.
С другой стороны, можно сначала поднять криптораздел и перед форматированием (mkfs) через dd заполнить его не медленным dd if=/urandom, а даже /dev/zero, но натравливать именно на поднятый криптораздел, чтобы нули шифровались. Конечно, противник сможет иметь больше оснований для предположении о наличии в открытом тексте раздела избыточного количества нулей, но это несущественный теоретический аспект.


Spinore, спасибо за тшательно разобранный и записанный пример, часто людям бывает лень делать подробный отчёт как для багрепорта.

— spinore (06/06/2010 23:03)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Всегда пожалуйста :)

The Mersenne twister
Это некриптостойкий генератор, хотя идеально проходящий все статистические тесты.

Так любой PRNG – некриптостойкий, а заполнить диск реальным рандомом – слишком длительная процедура, да и нужна ли? Криптостойкость — защита от предсказуемости, а не от "неслучайности". Т.е. не понятно
  1. Почему необходим "криптостойкий PRNG" (оксюморон?) для заполнения терабайта
  2. В принципе "криптостойкие PRNG" существуют для таких объёмов информации?

С таким же успехом можно использовать badblocks -t random.

Это интересная идея. Не додумал(ся,ись). Но он, может быть, менее случаен?

С другой стороны, можно сначала поднять криптораздел и перед форматированием (mkfs) через dd заполнить его не медленным dd if=/urandom, а даже /dev/zero, но натравливать именно на поднятый криптораздел, чтобы нули шифровались.

Тоже интересно. Проверил скорость (на объёмах порядка гигабайта) – 15Mb/s, т.е. в полтора раза быстрее было бы, чем используемый метод:


С другой стороны, если запускать с nice и долго ждать, то скорость записи потом постепенно снижается. Для моего метода она сейчас чуть больше 10 мегабайт; как было бы для нулей – не ясно, но, наверное, ничуть не хуже, да и технически это сделать куда проще.
— unknown (07/06/2010 10:21, исправлен 07/06/2010 10:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Может сообщим Шнайеру и Ко, чтобы он удалил свой кандидат с конкурса SHA-3, у него же универсальный криптопримитив, в том числе со свойствами PRNG. Всем другим разработчикам PRNG тоже будет интересно знать, что PRNG бывают исключительно некриптостойкие.


В стойком PRNG на самом деле все принципы такие же, как в обычном криптоалгоритме. Он мало отличается от потокового шифра, стойкость которого задаётся ключом. Из ключа разворачивается гамма практически бесконечной длины (ну там с ограничением до 2256 байт).


Для потокового шифра достаточно, чтобы:


  1. По этой гамме нельзя было восстановить ключ или внутреннее состояние шифра (быстрее, чем брутфорс).
  2. Зная фрагмент гаммы нельзя было предсказать другой фрагмент гаммы (слева или справа от имеющегося) быстрее, чем перебор грубой силой или хотя бы найти какие-то зависимости между фрагментами гаммы.

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


Чтобы не было путаницы в терминологии можно привести и критерий отличия PRNG от потокового шифра:


В PRNG как такового ключа нет и не нужно (поскольку не нужно ничего расшифровывать обратно). Есть заполнение первоначального внутреннего состояния какими-то случайными данными. Это состояние регулярно необратимо перетирается. Данные о предыдущих использованных внутренних состояниях уничтожаются. Если даже произойдёт взлом, то восстановление последующей гаммы PRNG более вероятно, чем восстановление предыдущих состояний (более сильная непредсказуемость влево по сравнению с потоковым шифром). Это свойство PFS (Perfect Forward Security), а под взломом может иметься ввиду не только криптоаналитический взлом, но и то что противник получил доступ к памяти и узнал внутреннее состояние генератора. Тогда всю последующую гамму он предскажет, но всё равно не предыдущую (в отличие от потокового шифра). В отдельных случаях — малый кусок предыдущей из-за определённого размера буфера внутреннего состояния.


То есть, данные из /dev/random инициализируют /dev/urandom и в принципе /dev/urandom должен был быть криптостоек (если бы его грамотно проектировали, но к сожалению это не так ). По крайней мере это живой более-менее криптостойкий PRNG (есть практические тонкости из-за которых он может фэйлить: неправильное обновление /var/lib/urandom/random-seed, неправильный порядок запуска в скриптах загрузки при полнодисковом шифровании, чем страдали некоторые системы).


На самом деле /dev/urandom из имеющегося — лучшее, что есть и доверить ему генерацию каких-либо кратковременно действующих ключей оправданно.


а заполнить диск реальным рандомом – слишком длительная процедура, да и нужна ли? Криптостойкость — защита от предсказуемости, а не от "неслучайности". Т.е. не понятно 1. Почему необходим "криптостойкий PRNG" (оксюморон?) для заполнения терабайта

Надеюсь понятно, что не оксюморон, выше дано простое определение. Но для заполнения терабайта именно криптостойкий PRNG действительно (почти) не обязателен. Однако может быть вот что: представим, что раздел заполнили некриптостойким легко взламывающимся PRNG. По фрагментам гаммы его можно различить и составить карту незаполненных и заполненных участков (где в контейнере уже что-то есть) и раздел будет выглядеть почти как если бы его и не заполняли. Т.е. истинные параноики или используют /dev/urandom перед поднятием криптораздела или /dev/zero или хотя бы слабый генератор после его поднятия (из badblocks, shred, wipe — один проход заполнения без затирания). Openssl значит здесь не нужен (и как бы провоцирует жестокий оффтопик на тему дискового шифрования), раз он валится после двух гигов.

— Гость (07/06/2010 21:01)   <#>
Спасибо. Недопонимание возникло из-за того, что все PRNG условно полагались некриптостойкими (частично – вопрос непонимания, и частично – вопрос использованных неверных определений).
— Гость (08/06/2010 09:32)   <#>
можно сначала поднять криптораздел и перед форматированием (mkfs) через dd заполнить его не медленным dd if=/urandom, а даже /dev/zero
или /dev/random
— unknown (08/06/2010 09:53, исправлен 08/06/2010 10:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

/dev/random быстро исчерпается и не будет выдавать следующие блоки данных, пока не получит энтропии от системы (это можно посмотреть в /proc/sys/kernel/random/entropy_avail). На несколько килобайт хватит, а дальше надо ждать и стучать по клавишам.


/dev/urandom не блокируется при нехватке энтропии в системе и может работать только от предыдущих состояний.

— SATtva (08/06/2010 11:44)   профиль/связь   <#>
комментариев: 11550   документов: 1036   редакций: 4094
На несколько килобайт хватит, а дальше надо ждать и стучать по клавишам.

При наличии аппаратного ГСЧ ситуация будет несколько лучше, /dev/random может выдавать поток даже быстрее, чем urandom.
— Гость (08/06/2010 11:45)   <#>
или используют /dev/urandom перед поднятием криптораздела или /dev/zero или хотя бы слабый генератор после его поднятия (из badblocks, shred, wipe — один проход заполнения без затирания)
причём второй способ предпочтительнее, поскольку в отсутствии идеальности возможно найти различитель криптораздела от /dev/urandom
— Гость (05/11/2012 13:03)   <#>
не могу найти тестовые входной вектор, таблицу замен и блок подстановок для режима гаммирования и имитовставки.кто разобрался может сказать где и как их найти?
— Гость (05/11/2012 20:20)   <#>
Искать в гугле.
Могу скинуть ссылку, но напиши тогда свою почту.
— Гость (05/11/2012 21:00)   <#>
И ФИО, чтобы знать, как к тебе в письме обращаться.
— Гость (05/11/2012 21:07)   <#>
Вот зачем этот сарказм?

Если пишу значит знаю о чем пишу.
Вот я решал задачку:
https://www.pgpru.com/forum/kr.....mogitesdelatjzadanie
вот еще одна
https://www.pgpru.com/forum/kr.....a/rasshifrovkateksta
и т.д.
— Гость (05/11/2012 21:11)   <#>
Просто не хочу тут заниматься тупой рекламой – типа вот зайди на сайт.
И в этом плане поддерживаю админа, который удаляет левые ссылки.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3