длина исходного и зашифрованного текста в различных алгоритмах

[Dart_Sitius]

никак не пойму и не могу найти информацию о соотношении длин при шифровании текста. если на вход подается строка длины n, то можно ли определить длину зашифрованной строки? Интересуют разные алгоритмы шифрования, но в первую очередь AES, RSA, DES, RC4

[amk]

Блочные алгоритмы (DES, AES, RSA) дополняют сообщение до длины, кратной размеру блока. Потоковый (RC4) использует блоки в один байт, поэтому не удлиняет сообщение.
Если я ещё не забыл, DES работает с блоками длины 64. Какую длину имеет блок AES не знаю. RSA может работать с блоками разной длины, какие есть реализации тоже не знаю.

Вообще, потоковые алгоритмы тоже могут использовать более длинные блоки, тогда тоже произойдёт удлинение. Но у них блоки всегда короткие.

Теоретически можно дополнить сообщение так, чтобы можно было просто обрезать зашифрованное сообщение, но на практике подбор такого продолжения - задача, сравнимая по сложности с криптоанализом.

Кроме того в зашифрованное сообщение может добавляться какая-то служебная информация.

[ter_nk_]

У DES ключ 56, у Triple DES в три раза больше, а собственно что получим в плане избыточности?

[Akina]

Цитата ter_nk_ @ 07.02.16, 05:41

У DES ключ 56, у Triple DES в три раза больше

Это никак не влияет на размер шифрованного сообщения - если, конечно, при шифровании этими алгоритмами не будут выбраны разные по размеру блоки шифрования.

Цитата ter_nk_ @ 07.02.16, 05:41

что получим в плане избыточности?

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

Сообщение отредактировано: Akina - 08.02.16, 08:27

[ter_nk_]

Ясно, т.е. на пакет 64, я получу обработанный такой же. Т.е. при увеличении ключа, меняется его обработка (время увеличивается), а на выходе тоже самое по длине.

[Akina]

Угу. Разве что для пакета в 1 байт, как и для пакета в 64 байта, ты получишь выходной пакет 64 байта. А для пакета в 65..128 байтов на выходе будет уже 128-байтная информация, и так далее. Увеличение же сверх - это добавочные сведения для, скажем, защиты от минорных разрушений... или последствия неудачной архивации... или следствие добавления имитовставки... и т.д., и т.п.

Сообщение отредактировано: Akina - 08.02.16, 10:46

[Dart_Sitius]

в http://phpseclib.sourceforge.net/ это не совсем так.

$cipher = new Crypt_AES();
$cipher->setKey("aasdasd");
$cipher->setIV(crypt_random_string($cipher->getBlockLength() >> 3));    
echo strlen($cipher->encrypt(str_pad("", 16, "a")))."\n";
echo strlen($cipher->encrypt(str_pad("", 31, "a")))."\n";
echo strlen($cipher->encrypt(str_pad("", 32, "a")))."\n";

выведет 32, 32, 48
т.е строку длиной в 16 он превращает в 32, и в итоге всегда зашифрованный текст длиннее исходного.
не могу понять, как мне в этом случае зашифровать длинный файл. по идее хотел по кусочкам..

Сообщение отредактировано: Dart_Sitius - 10.02.16, 19:54

[amk]

Цитата Dart_Sitius @ 10.02.16, 19:53

т.е строку длиной в 16 он превращает в 32

А ты уверен, что он шифрует именно 16 байт, а не 17? Попробуй проверить ещё строчку

echo strlen($cipher->encrypt(str_pad("", 15, "a")))."\n";

[Dart_Sitius]

выводит 16.
echo strlen($cipher->encrypt(str_pad("", 31, "a")))."\n";
аналогично как тут 32

[amk]

Получается, что к твоей строке перед шифрованием добавляется ещё один байт, который и портит длину.
У меня из-за строки в 31 символ и возникло подозрение.

А у самого str_pad("", 15, "a") какая длина?

[Akina]

Цитата amk @ 10.02.16, 21:21

перед шифрованием добавляется ещё один байт

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

[Dart_Sitius]

amk, 15.
В общем, решил делать через временный файл. в цикле: считываю 16 исходных байт, пишу во временный файл 32 зашифрованных. заменяю исходный файл временным. при расшифровке считываю 32 исходных байт, пишу во временный 16

[Akina]

Цитата Dart_Sitius @ 11.02.16, 06:33

в цикле: считываю 16 исходных байт, пишу во временный файл 32 зашифрованных. заменяю исходный файл временным. при расшифровке считываю 32 исходных байт, пишу во временный 16

Гарантированное увеличение объёма вдвое. Смысл? считывайте по 15 байт, и после шифрования записывайте 16 - увеличение будет всего 7%.

[Dart_Sitius]

Цитата Akina @ 11.02.16, 07:27

Гарантированное увеличение объёма вдвое. Смысл? считывайте по 15 байт, и после шифрования записывайте 16 - увеличение будет всего 7%.

как писать в тот же файл 16 байт вместо 15ти не теряя тот 16ый, который мы еще не считали?

Сообщение отредактировано: Dart_Sitius - 11.02.16, 08:00

[Akina]

Цитата Dart_Sitius @ 11.02.16, 07:59

как писать в тот же файл

Цитата Dart_Sitius @ 11.02.16, 06:33

решил делать через временный файл

Ну ты уж определись, что ли...

[Dart_Sitius]

Цитата Akina @ 11.02.16, 08:06

Ну ты уж определись, что ли...

ааа, в этом смысле)) понял, спасибо

Добавлено 11.02.16, 08:35
хмммм, а насколько это криптографически надежно? шифровать файл по частям..
вот было у меня 31 символов 'a'. если их просто зашифровать, получим 32 непонятных байта. а если разбить по 15, то получим 48 байт, при этом первые 16 и вторые 16 одинаковые (т.к и входные строки были одинаковые по 15 'a'), а вот третьи 16 уже другие (т.к там всего один символ 'a').
это не уменьшает криптостойкость?

[Akina]

Цитата Dart_Sitius @ 11.02.16, 08:19

насколько это криптографически надежно? шифровать файл по частям..

Это ОЧЕНЬ плохо.
Одно дело, когда на анализ для взлома поступает один файл на мегабайт. И совсем другое, когда 100к файлов по 16 байт, пусть и сшитые в один мегабайтный файл.
Я вообще не понимаю, нафига тебе потребовалось бить исходные данные на блоки.

[Dart_Sitius]

Цитата Akina @ 11.02.16, 10:18

Это ОЧЕНЬ плохо.
Одно дело, когда на анализ для взлома поступает один файл на мегабайт. И совсем другое, когда 100к файлов по 16 байт, пусть и сшитые в один мегабайтный файл.
Я вообще не понимаю, нафига тебе потребовалось бить исходные данные на блоки.

ну насчет 100к файлов по 16 байт - я буду дробить не на 16, а на (16*10*1024 - 1) блоки или и того больше.
а бить исходные данные на блоки - потому что нужно зашифровать например 8гб файл, я его не могу одной строкой запихать в функцию encrypt

[Akina]

Цитата Dart_Sitius @ 11.02.16, 10:23

нужно зашифровать например 8гб файл, я его не могу одной строкой запихать в функцию encrypt

А сколько она допускает максимально?

[Dart_Sitius]

Цитата Akina @ 11.02.16, 10:38

А сколько она допускает максимально?

не знаю, дело в оперативке. но в принципе я понял, думаю, что размера куска даже в 160кб должно хватить

Сообщение отредактировано: Dart_Sitius - 11.02.16, 10:59

[Akina]

Цитата Dart_Sitius @ 11.02.16, 10:53

дело в оперативке. но в принципе я понял, думаю, что размера куска даже в 160кб должно хватить

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

[leo]

Da rt_Sitius
Почитай справочку по phpseclib - disablePadding() и enableContinuousBuffer().
1) По умолчанию в encrypt используется padding по стандарту PKCS#7, согласно которому в случае, если длина строки кратна размеру блока, то добавляется еще один целый блок выравнивания. Поэтому нужно выключить выравнивание вызовом $cipher->disablePadding() либо вообще для всех блоков и выравнить последний блок самому, либо включить выравнивание только для последнего блока.
2) По умолчанию каждый вызов encrypt начинает шифрование с начального состояния. Для возможности непрерывного шифрования блоков одного большого файла нужно предварительно вызвать $cipher->enableContinuousBuffer(). В этом случае при последующих вызовах состояние encrypt будет сохраняться и последовательные блоки будут шифроваться как одно целое.