dd, cat & openssl: размер блока и размер буфера

Здесь говорится, что при использовании dd через dm-crypt для перезаписывания блочного устройства должен использоваться только размер блока dd по умолчанию, поскольку размер блока dm-crypt одинаковый (512 байт), и увеличение размера блока dd может запретить запись окончательных блоков.

Это также относится к openssl (в Linux)?

Здесь Жиль говорит, что размер буфера по умолчанию для openssl составляет 8 КБ. Размер буфера совпадает с размером блока в этом контексте?

Учитывая, что размер блока dd умолчанию равен 512, если бы я хотел использовать размер блока 1M в dd , мне также нужно было бы установить -bufsize на тот же номер для openssl ? Is -bufsize в байтах?

Точно так же нецелесообразно использовать cat через openssl , учитывая, что размер блока по умолчанию (и не настраиваемый) по умолчанию составляет 128 КБ?

TLDR это не имеет значения (если бы я догадался)

Во-первых, openssl commandline делает около 50 различных вещей; только два из них принимают объемные входные данные: enc для шифрования или дешифрования «файла» или кодирования / декодирования base64 в качестве особого случая, который на самом деле не является шифрованием, а dgst – хешем и необязательно подписывает или проверяет «файл». Из тех только enc производит вывод, который может быть полезен, чтобы «перезаписать» что-то, поэтому я предполагаю, что вы имеете в виду это; rand также может производить массовый выход, но не привязан к какому-либо входу.

Во-вторых, проблема в связанном с вами вопросе заключается в задержке из-за ожидания блока данных шифрования или блока кодирования (base64) по сети . Если вы беспокоитесь только о получении правильного результата, задержка не имеет значения, и если источник не является удаленным, он все равно не будет отложен.

openssl enc использует блочный шифр и режим , в частности CBC, который по умолчанию используется по умолчанию, использует PKCS # 5 padding (так называемый; официально это PKCS # 7 на основе PKCS # 5, но многие люди, включая OpenSSL, просто говорят PKCS # 5) , Это позволяет шифровать и дешифровать любое количество байтов данных, которое соответствует входному и выходному «файлу», поддерживаемому ОС и файловой системой. Зашифрованный файл (с добавлением дополнений) всегда является точным кратным размеру используемого шифрования. Для шифрования на основе пароля с солью, а также по умолчанию, шифротекст до 32 байтов длиннее обычного текста, поэтому при шифровании вам может потребоваться это сделать. Если вы укажете -nopad (для блочного шифрования / режима), отключение отключено, а открытый текст должен быть точным кратным блоку шифрования. Если это не так, возникает ошибка, и вывод является неполным – хотя обычно непустым, что может смутить незаинтересованных людей или скриптов / etc в мышлении, это действительно, когда это не так.

Если вы используете шифр потока (в настоящее время только RC4) или режим потока блочного шифрования (CFB OFB CTR), никакие дополнения не нужны или не используются, а открытым текстом может быть любое количество байтов (которые вписываются в файлы). Для PBE с солью зашифрованный текст все еще длиннее на 16 байтов. (Предупреждение: некоторые версии ошибочно перечисляют режимы CCM и GCM, поддерживаемые в enc , они фактически не работают, если вы пытаетесь их использовать.)

-bufsize – это (только) размер, используемый для чтения и записи данных. Он не должен быть связан с блоком шифрования, если он есть, хотя по умолчанию он имеет среднюю мощность 2, а блокировки всех поддерживаемых блочных шифров – это малая мощность 2, поэтому они делятся равномерно. Шифрованная логика обрабатывает большие данные как поток, разбитый на куски любого размера или размера; имеет значение только общая длина. Но менее эффективно обрабатывать множество мелких фрагментов, поскольку он больше обращается к библиотеке C и (часто) ОС.

cat поданный на вход openssl enc отлично, хотя, если он читает только один «файл», нет никакой пользы от того, что этот файл (перенаправленный) stdin для openssl или аргумент -in . Точно так же нет никакого вреда и пользы при использовании dd если он просто копирует данные; если вы используете какую-либо другую функциональность dd например, преобразование записей EBCDIC и / или фиксированной длины (типичное для данных мейнфрейма IBM), очевидно, что это необходимо. И если вам нужна статистика о 1234+0 records in т. Д., Вам нужно dd или подобное.