IV в mcrypt не выводят из пароля согласно PBKDF2, а генерят случайно и хранят в файле.

-salt use a salt in the key derivation routines. This option should ALWAYS be used unless compatibility with previous versions of OpenSSL or SSLeay is required. This option is only present on OpenSSL versions 0.9.5 or above.
-nosalt don’t use a salt in the key derivation routines. This is the default for compatibility with previous versions of OpenSSL and SSLeay.

-iv IV the actual IV to use: this must be represented as a string comprised only of hex digits. When only the key is specified using the -K option, the IV must explicitly be defined. When a password is being specified using one of the other options, the IV is generated from this password.

1. при IV=0 CBC становится ECB и это плохо,
2. если у шифртекстов равны IV и пароли, и они имеют общие куски, то эти куски можно установить.

Вообще, если не нравится, можно использовать openssl с солью и отпиливать magic (первые 8 байт), а перед использованием запиливать обратно

In Summery the "openssl" command is deficient:

• You can't create a encrypted file that included an ic
• You can't even specify the ic for the encryption (it just 1)
• You can't pass Key and IV other than as command line arguments! (making them visible in process listings!)
• You can't even use the "openssl" command to just do the basic conversions of pass-phrase + salt + count --TO-> key + IV perhaps with options for base64 or base16 (hexadecimal) output. For either PBKDF 1.5 using EVP_BytesToKey() or for PBKDF 2 using PKCS5_PBKDF2_HMAC_SHA1()

At the end of the day, OpenSSL is a library, not an end-user product, and enc(1) and friends are developer utilities and "demo" tools. When you need a product, you build something useful with the library. Yes, enc(1) should be better, but it is likely not a priority relative to improving the library.

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

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

# openssl rand 1099511627776 | dd of=/dev/sd1d bs=131072 0+0 records in 0+0 records out 0 bytes transferred in 0.059 secs (0 bytes/sec)
Угарно, да? Кто не верит – попробуйте ;) После ряда тестов выясняется – дело в величине числа после rand, на которое есть фундаментальное ограничение в 2³¹-1=2Гб. У вас диск больше 2Гб? Значит, не повезло.

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

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

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

Был выбран 1ый вариант, как "самый простой" (в UNIX самый простой вариант – самый сложный, т.к., в конце концов, [типично] оказывается, что всё равно не работает, и потому надо было сразу браться за самый ручной и трудоёмкий способ). Итак, первый блин таков:

# ( for i in `seq 513` ; do echo $i >&2 ; openssl rand 2147483647 ; done ) | dd of=/dev/sd1d bs=128m 1 0+19227 records in 0+19227 records out 315015168 bytes transferred in 408.221 secs (771678 bytes/sec)
Он даже, кажется, работает, а по -SIGINFO, посылаемому dd, можно смотреть сколько записалось, только скорость... 2 недели для терабайтного диска – всё правильно? Проверяем скорость самого OpenSSL и скорость записи на диск:

# openssl rand 104857600 | dd of=/dev/null 204800+0 records in 204800+0 records out 104857600 bytes transferred in 17.487 secs (5996317 bytes/sec) # dd if=/dev/zero of=/dev/sd1d bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 72.045 secs (1455445 bytes/sec)
USB-стэк? Хотя... если писать в файл на файловой системе – всё нормально:

# dd if=/dev/zero of=/home/filetest bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.729 secs (28119495 bytes/sec)
Почему писать напрямую в device – намного медленее, чем на ФС? Синхронная запись? Или... здесь повлияло то, что объём был мал, и он влез в оперативную память? Оказалось, что дело совсем не в этом. Итак, было нарыто:

# nice -n 20 dd if=/dev/zero of=/dev/rsd1d bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 4.419 secs (23728807 bytes/sec)
Магия?

FILES /dev/sdup block mode SCSI disk unit u, partition p /dev/rsdup raw mode SCSI disk unit u, partition p
Почему "block mode" такой ежовый? Итак, теперь в raw mode:

# nice -n 20 sh -c '( for i in `seq 513` ; do echo $i >&2 ; openssl rand 2147483647 ; done ) | dd of=/dev/rsd1d bs=128m'

Без доброжелательности nice'а I/O будет тормозить ужасно. Оценочное время исполнения – 25 часов; не быстро, но уже приемлемо. И тут ВНЕЗАПНО:

# nice -n 20 sh -c '( for i in `seq 513` ; do echo $i >&2 ; openssl rand 2147483647 ; done ) | dd of=/dev/rsd1d bs=128m' 1 0+48900 records in 0+48900 records out 801177600 bytes transferred in 71.610 secs (11188068 bytes/sec) dd: /dev/rsd2d: Invalid argument 0+131072 records in 0+131071 records out 2147467264 bytes transferred in 180.807 secs (11877124 bytes/sec) 2

Умный openssl закрыл канал, и dd тут же вывалилось. Цикл не работает, и вот простейший пример для демонстрации (почему-то Linux'овый dd умнее и там этой проблемы нет):

# ( for i in `seq 10` ; do echo $i >&2 ; openssl rand 20 ; done ) | dd of=/dev/rsd1d 1 2 3 4 5 6 7 8 9 10 dd: /dev/rsd2d: Invalid argument 0+10 records in 0+0 records out 0 bytes transferred in 0.330 secs (0 bytes/sec)
Можно попробовать и так:

# ( for i in `seq 10` ; do echo $i >&2 ; openssl rand 20 ; done ) | cat | dd of=/dev/rsd1d
или вот так:

# ( for i in `seq 10` ; do echo $i >&2 ; openssl rand 20 ; done ) | tail -f | dd of=/dev/rsd1d
– результат тот же. Раз уж такие сложности, не вспомнить ли про рекомендованный "более медленный /dev/urandom"?

# nice -n 20 dd if=/dev/urandom of=/dev/rsd1d bs=1m 28+0 records in 27+0 records out 28311552 bytes transferred in 15.806 secs (1791190 bytes/sec)
nice почти не помогает. I/O вешается почти намертво, с компом работать невозможно, кое-как прерывается, особенно при bs=128m. Да-а, с такой скоростью долго прийдётся ждать вайпа. Не вариант. Может, хакнуть OpenSSL с его 2³¹-1-ограничением?

Есть ещё одна идея: сделать тупой арифметический цикл с оффсетами а-ля сишный for: берем кусок в гигабайт размером, пишем в него, затем переходим к следующему... например:

# cat script.sh #!/usr/pkg/bin/bash OUT_DEV=/dev/rsd1d OSSL_BLOCK=1073741824 # 1 Gb NBL=932 KKK=8 #1 Gb/128 Mb for ((i=0;i<$NBL;i++)) ; do OFFS=$(($i*$KKK)) #offset openssl rand $OSSL_BLOCK | dd of=$OUT_DEV bs=128m seek=$OFFS echo $i done
и запускаем:

nice -n 20 ./script.sh
Полёт пока нормальный – уже 49 гигов завайплено:

0+65536 records in 0+65536 records out 1073741824 bytes transferred in 107.064 secs (10028971 bytes/sec) 47 0+65536 records in 0+65536 records out 1073741824 bytes transferred in 98.375 secs (10914783 bytes/sec) 48 0+65536 records in 0+65536 records out 1073741824 bytes transferred in 100.632 secs (10669983 bytes/sec) 49
Решение проблемы – 2 головы и 4 часа времени, т.е. 8 человекочасов. Страшно представить, что будет, когда до LVM дойду. Вот така убунта^[link8].

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

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... чтоб его...

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

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

The Mersenne twister

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На несколько килобайт хватит, а дальше надо ждать и стучать по клавишам.

или используют /dev/urandom перед поднятием криптораздела или /dev/zero или хотя бы слабый генератор после его поднятия (из badblocks, shred, wipe — один проход заполнения без затирания)

Просто не хочу тут заниматься тупой рекламой – типа вот зайди на сайт.

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

Можно и по-вашему сделать:

$ echo 'content' > tfile
$ (openssl enc -aes-256-cbc -salt -in tfile | tail -c +9) > tfile.out
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
$ cat tfile.out |hexdump -Cv
00000000  91 f7 17 73 1b 2d 6d ce  90 1c 25 49 75 80 42 cf  |...s.-m...%Iu.B.|
00000010  36 0d 7d 57 1e 55 0d 58                           |6.}W.U.X|
00000018
$ (echo -n 'Salted__' && cat tfile.out ) \
  | openssl enc -d -aes-256-cbc -salt -out tfile.dec
enter aes-256-cbc decryption password:
$ cat tfile.dec 
content

Думаю, что лимитов нет.

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

Думаю, можно, поскольку соль используется. Во всяком случае, зашифрованные одинаковыми паролями одинаковые файлы дают в этом примере разные шифртексты. Правда, я не помню, как тут выводится ключ шифрования из пассфразы с учётом того, что pbkdf2, scrypt и т.п. KDF не используются, поэтому, как минимум, вопросы стойкости пассфразы — целиком и полностью ответственность юзера.

Всё такое нестандартное шифрование лучше дублировать конвенциональным, т.е., например, шифровать с помощью GnuPG файл, а потом, чтобы убрать сигнатуры, заворачивать его ещё в OpenSSL-слой. Нестандартные вещи могут иметь нетривиальные уязвимости, мало кем анализироваться на предмет безопасности... а здесь ещё и нетривиальные/недокументированные режимы использования софта. Всё это делается «на свой страх и риск». Если внутри конвенциональным образом шифрованный текст, максимум, что грозит в случае фейла — потеря отрицаемости (что случайные данные — шифртекст), а в ином случае это может привести и к взлому самих данных или частичной утечке информации о них.