Какая процедура более безопасна для шифрования с использованием пароля и семени

Question

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

Ниже приведен обзор структуры формата:

------------------------------------------
| File signature || fixed    | plain     |
|----------------||----------|-----------|
| Algorithm info || fixed    | plain     |
|----------------||----------|-----------|
| Seed           || fixed    | encrypted |
|----------------||----------|-----------|
| Data           || variable | encrypted |
|----------------||----------|-----------|
| CRC            || fixed    | encrypted |
------------------------------------------

Изначально я собираюсь использовать SHA-256 для хэш-функции и AES-256 для алгоритма шифрования, но позже он будет настраиваться, как предполагает формат.

Предлагаемая процедура создания зашифрованного контейнера:

1. Хэш (Пароль) => Ключ доступа
2. Создать случайное семя
3. Key-Pass XOR Seed => Сеялки с ключом
4. Зашифруйте семя с помощью Key-Pass и сохраните зашифрованное семя
5. Шифрование данных с помощью ключа и сохранение зашифрованных данных
6. Шифрование CRC с помощью Key-Seded и сохранение зашифрованного CRC

Вопросы

A. Получу ли я что-нибудь от хранения зашифрованных семян и CRC? Будет ли это менее безопасно, если я буду хранить их без шифрования?

B. Более или менее или нет различий в безопасности использования [Hash (Password + Seed)] для генерации ключа, а не использования [Hash (Password) XOR Seed] для окончательного ключа?

C. Заключительный вопрос из двух вопросов выше. Будет ли лучше или хуже использовать альтернативную процедуру создания зашифрованного контейнера:

1. Хеш (Пароль + Семя) => Ключ
2. Хранить незашифрованное семя
3. Шифрование данных с помощью ключа и сохранение зашифрованных данных
4. Хранить незашифрованный CRC (или зашифрованный)

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

Answer 1

Создание ваших собственных криптографических форматов файлов всегда сложно (и рискованно).

Генерация ключей Вместо того, чтобы использовать собственную процедуру генерации ключей, используйте PBKDF2 (PKCS # 5 v2.0, RFC 2898 ) для генерации ваших ключей.Это потребует от вас хранить соль (то, что вы называете семенем) в незашифрованном формате.

CRC Storage Если вы уже на уровне использования криптографии, неиспользуйте CRC для проверки целостности.Вы уже планируете использовать SHA256 в другом месте, также используйте его для проверки целостности.(Я рекомендую хешировать незашифрованные данные и хранить хеш-код незашифрованным, хотя вы можете зашифровать его, если хотите.)

Answer 2

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

Никогда не сохраняйте CRC в незашифрованном виде, поскольку CRC предоставляет информацию о данных в зашифрованном контейнере.Так же, как с хешем, как предложил Eacwacer.Вам лучше использовать MAC (также сгенерированный, например, с помощью генератора ключей).

Поскольку вы спрашивали конкретные ответы, я отвечу на ваши вопросы ниже:

A: лучше хранить егоЗашифрованный B: H (пароль | семя) более безопасен. C: трудно сказать, XOR неверен и обычный CRC тоже, но я бы все равно выбрал второй

А для незапрошенного:

D: довольно, пожалуйста, с сахаром сверху, используйте вместо этого хорошо известный алгоритм шифрования на основе пароля и используйте криптографически безопасный способ проверки целостности