2015-08-04 9 views
1

Мне нужно создать собственный формат файла (байт) для Android-приложения. Основными задачами форматов являются сохранение зашифрованного файла AES (байтовые данные) и некоторые метаданные, необходимые для его расшифровки (например, IV, Salt и несколько параметров приложения).Правильная обработка собственного формата файла в Java

У меня есть несколько вопросов о том, как разработать и осуществить это:

  1. Каковы обязательные поля в файле?

Текущая идея состоит в том, чтобы начать с 4 байтов магического номера, а затем номер версии формата. Затем следуют IV и Соль. Затем я бы включил контрольную сумму первых 4kb исходных (незашифрованных) данных, поэтому я могу быстро расшифровать только первые 4kb и проверить, был ли предоставленный ключ правильным. Затем контрольная сумма всех исходных (незашифрованных) данных, чтобы я мог также проверить весь файл. Это он для заголовка. (Нужна ли длина ((un) зашифрованных) данных? Смещение к данным? Контрольная сумма для всего файла (заголовок + тело)?)

Для тела (которое теперь зашифровано) я хотел бы добавить оригинальное имя файла и расширение (сколько байтов должно использоваться для этого?). Тогда исходный файл.

  1. Каков наилучший способ для чтения/записи таких байт-файлов на Java?

Два основных метода, которые я нашел: ByteArrayOutputStreams и RandomAccessFiles. С первым вариантом я пропускаю опцию поиска, например, как можно писать в определенной позиции (т. Е. Для контрольной суммы)? Второй, похоже, работает хорошо, но, возможно, есть более доступные решения.

+0

[консенсус] (http://crypto.stackexchange.com/q/202/13022) заключается в том, что вы должны использовать encrypt-then-MAC, а не MAC-then-encrypt (это то, что вы предлагаете) , Это означает, что вы запускаете полученный шифротекст AES с помощью сильного алгоритма MAC, такого как HMAC-SHA256.Остается вопрос, как получить ключ, который будет использоваться для алгоритма MAC. –

ответ

0

Для моей базы данных H2 я реализовал абстракцию файловой системы с несколькими реализациями файловой системы, включая encrypted file. Существует много других реализаций файловой системы, например, обертка кэш-памяти и т. Д.

Я бы использовал XTS (XEX-based tweaked-codebook mode with ciphertext stealing), это то, что я реализовал. Он позволяет читать и записывать произвольный доступ и не намного медленнее, чем чистый AES.

Заголовок, который вы предлагаете, звучит хорошо для меня: магическое число, а затем номер версии формата. Я сочетал магическое число и номер версии (другая версия приводит к другому магическому числу). С XTS IV не требуется. Соль, я бы использовал много, например, 8 байт. Я также сохранил хеш-итерации для хеширования пароля, для этого я использовал PBKDF2. Я думаю, что использование чего-то типа PBKDF2 важно.

Я сделал заголовок длиной 4096 байт, чтобы соответствовать размеру блоков обычных файловых систем. Это должно повысить производительность, если вы читаете и записываете с фиксированным размером блока. Я не использовал контрольную сумму, так как мой базовый (незашифрованный) файл имеет контрольную сумму. Я думаю, что это достаточно хорошо, и, возможно, немного безопаснее, чем хранить незашифрованную контрольную сумму незашифрованных данных, но я не уверен.

Что касается API, то с использованием ByteBuffer или byte[] оба хороши. С ByteBuffer поддержка файлов с отображением памяти проще.

 Смежные вопросы

  • Нет связанных вопросов^_^