NutzПривет криптологам! У меня стоит задача написать алгоритм шифрования бинарных файлов. Файлы это различные документы типа .doc, .docx. xls и т.п. Проблема в том, что файлы большие, размером от 20 до 200 мегабайт, и их очень много. Дополнительная проблема в том, что файлы я перехватываю и шифрую "на лету", потом они улетают дальше в ERP систему, где сжимаются по алгоритму LZW. Сжатие отменить нельзя. Поэтому возник вопрос:

- Надо ли шифровать весь файл? Может стоит зашифровать только первые 10 кбайт, а остальные 199 мегабайт - фиг с ним. Если таблицы в начале документа покриптованы, то распаковать тот-же вордовский документ не получится. Вообще документы могут "прилетать" любых форматов и типов. Даже видео, mp3, дистрибутивы ПО и т.д. Весь файл я не хочу шифровать потому что это занимает много времени и ресурсов системы, а ведь потом еще и обязательное сжатие последует, если система будет пытаться сжимать огромные зашифрованные файлы она точно помрет в страшных муках или очередь из документов получится до Луны.
Ну вот такой вопрос, сколько надо сжимать первых килобайтов для надежной защиты?
Из этого мозгового штурма можно сделать вывод что ты не совсем понимаешь себе цену
решения. Криптография это тяжёлая артиллерия. Это самый последний рубеж защиты
информации. Когда все другие уже взяты. И если ты злоумышленнику оставляешь 199 Мб
живых данных то такому шифрованию - грош цена и оно ничено не шифрует а только
дискредитирует систему. Для людей которые целенаправленно охотятся за инфой
анализ хвоста файла в 199М не представляет особого труда. Их не остановит такой
пустяк как отстутствие заголовка. Если тебе лень и неохота этим заниматься то перенеси
шифрование в плосксть трафика (VPN) или хранения (filesystem encrypton) но только
не делай профанаций вроде "частичного шифрования".

NutzInkelyadЕсли бы это было так, то все бы так и шифровали - жали бы, и применяли "нормальную" криптографию к заголовку. Но никто почему-то так не делает.

Да что вы говорите! А разработчики архиваторов разве не так делают?
Как - то незаметно автор занял позицию эксперта. Это удивляет.

Блин. Ну о чём вы? Какая тормознутость? PGP это программный продукт-оболочка. Он поддерживает
штук 6 алгоритмов (IDEA, Blowfish...), и кучу вариантов разрядности ключа (от 128 бит до 4096).
Вы сами себе выбираете аспекты исходя из 1) требований к безопасности (это можно брать таблично
или шаблонно) исходя из смежных решений или советов экспертов, 2) требований к производительности
(сами регулируете силу шифрования исходя из того "сколько потянет" сервер сессий шифрования
одновременно или какой трафик даст или будет ли успевать отработать суточные отчёт или выборку
документов).

NutzmaytonКак - то незаметно автор занял позицию эксперта. Это удивляет.

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

Поскольку шифрование фрагмента файла можно вполне классифицировать
как повреждение или изменение то ПК теоретически позволяет спокойно
восстановить разрушенный фрагмент (заголовок). ПК усиленно применяется
в компат дисках чтобы защищать данные при чтении от единичных
сбойных ошибок (пыль и царапины на поверхности).

Вопрос применения ПК в архиваторах и прочем софте останется тебе
домашним заданием. Оценка безопасности твоего метода в разрезе
новых знаний тоже останется тебе заданием.

Читай, думай.

NutzДумаю и пока никто не убедил, что надо тратить ресурсы на шифрование всего файла архива.
Я придерживаюсь точки зрения что каждый грешник сам себе устилает
дорогу в ад. Конешно же никто не схватит тебя за руку и твой софт
будет работать. Просто подумай о том что любой LZW поток имеет
определённые зависимости и энтропии и оставляя заинтересованным
лицам возможность видеть этот трафик или перехватывать его ты даёшь
им слишком много информации об открытом тексте. А зная открытый
текст можно делать атаки на ключ. Об этом писал Брюс Шнайер.
Вобщем если есть ПРОБЛЕМА производительности то я-бы подключил
app-серверы шифрования в изолированом сегменте сети, и (или)
понизил разрядность ключа и (или) ослабил сам метод. Но оставлять
явные "дырки" в файле - это эпик фейл. Тебя может быть не поломают
по аналогии с тем как "не ловят" неуловимого Джо.