LINUX.ORG.RU

вопрос по криптографии, хельп....


0

0

Подскажите, Уважаемые All, где можно найти информацию о том, на сколько увеличивается размер закриптованных данных в сравнении с теми же исходными незакриптованными.
Непосредственно интересует: DES, 3DES & BlowFish.

Кинте ссылочкой, плиз, или хоть так скажите... очень надо )))

anonymous

не увеличивается.

можно в google поискать "des algorithm" и "blowfish algorithm" и почитать их описания. ;)

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

> не увеличивается.

Это не совсем так... Указанные автором алгоритмы являются блочными, поэтому последний блок исходного сообщения будет дополнен до целого блока. В то же время потоковые алгоритмы (RSA, RC4, crypt) никогда не изменяют длину исходного сообщения.
Тем не менее на практике увеличением размера зашифрованного файла можно пренебречь - типичный размер блока в блочный алгоритмах (DES, Blowfish) - это 64 бита. То есть 8 байт. Поскольку на диске файлу в любом случае отводится (как правило) целое число блоков, то дополнение исходного текста до размера кратного 8-ми байтам _как правило_ не изменяет размер дискового пространства, которое ОС отводит этому файлу.
Однако если Вы скажете своему преподователю, что этот размер _всегда_ совпадает с исходным, то он на законном основании может влепить Вам двойку.
Потому что существуют как минимум два исключения: это файловые системы поддерживающие сжатие файлов "на лету" (chattr +c <имяфайла>).
Если у Вас есть Linux КПК, то все файлы во внутреннем флеше хрянятся именно в сжатом состоянии (обычно они используют jffs2).
А как легко догадаться, основной отличительной особенностью данных позволяющей зафиксировать передачу шифртекста является именно тот факт, что они несжимаемы.
Вторая причина заключается в том, что сами по себе алгоритмы шифрования не позволяют восстановить точную длину исходного текста. Поэтому перед шифрованием к тексту может добавляться его длина (чаще всего 4-ре байта). Без этого окажется невозможно узнать сколько именно нулевых байт в последнем блоке являются частью исходного сообщения.
Само собой, это необходимо только в случае шифрования двыоичных (как противоположность текстовым) файлов. Например, программ. Однако, в реальной жизни, практически все зашифрованные данные являются именно двоичными. Потому что текстовые данные перед шифрование сжимают, чтобюы увеличить энтропию и повысить криптографическую стойкость шифртекста.
При этом возможна ситуация, когда сжатый текст сожержит, к примеру, 1021 байт и после дополнения его размером (4-ре байта) получившийся тест будет иметь длину 1025 байт, который будет дополнен до размера кратного 8-ми - 1030 байт и, если Ваiа ext3 имеет размер кластера в 1024 байта, то шифрованный файл займет два кластера против 1-го для исходного файла.
(реально многие реализации хранят не размер самого файла в байтах, а единственный байт, к котором записано количество байт в последнем блоке текста).
Вывод: разница в размерах есть, но носит чисто академический характер.

anonymous
()
Ответ на: комментарий от anonymous

P.S. Я так понял, что у автору нужен был ответ для коллоквиума, поэтому так подробно постарался объяснить.

P.P.S. Приношу извинения за опечатки (вроде "преподОвателю" вместо "преподавателю").

anonymous
()
Ответ на: комментарий от anonymous

еще одна опечатка: 1024+8=1032, а не 1030

anonymous
()
Ответ на: комментарий от anonymous

Есть еще какой-то режим блочного шифрования, когда размер шифртекста байи-в-байт совпадает с размером plaintext. Предназначен специально для замещения записей в памяти или в базах данных. Как называется - не помню :-) А обычно Длина ciphertext = длина plaintext + 1 блок вектора инициализации + 1 блок дополнения + до нескольких блок для проверки ошибок + блок с хэшированным паролем для проверки корректности расшифрования + еще куча блоков со служебной инфой и т.д.

Но в целом размер действительно незначительно больше.

А еще при шифровании раздела на диске много областей могут иметь свой вектор инициализации, тогда размер еще на пару процентов больше.

В каждом конкретном случае все может быть по-разному.

anonymous
()
Ответ на: комментарий от anonymous

Ну хорошо, убедил. Тогда не забудь еще 64 бита для инициализационного вектора в случае CBC. ;)

ivlad ★★★★★
()
Ответ на: комментарий от anonymous

Огромное спасибо за ответ - буду дальше разбираться )))

но, собственно, вопрос не для коллоквиума, а, как раз, для практического использования.

Ну и сама проблема:
Для корпоративной сети используется VPN с шифрованием трафика с помощью 3DES (аппаратные роутеры) и BlowFish (Linux-box'ы). Случилось так, что понадобилось еще и с клиентами обмениваться зашифрованной информацией через интернет, для чего была самонаписана программка под винду с использованием библиотеки FathCrypt, которая использует AES. Так вот в хелпе к этой библиотеке написано "... Encrypted strings are bigger then decrypted ones approximately two times plus 16 characters..." вот такая хрень...

итак, вопросы:
1. Зачем писать алгоритмы, которые увеличивают данные более чем в два раза? или я чего-то не понимаю?
2. А по поводу того, как обстоят дела с 3DES и BlowFish - не становятся ли они узким местом для канала?

Спасибо за внимание )))

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.