Как реализовать защиту паролем для отдельных файлов?

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

У меня есть стратегия, которая кажется работоспособной и кажется логичной на основе того, что я знаю (чего, вероятно, достаточно, чтобы быть опасным), но я понятия не имею, действительно ли это хороший дизайн или нет. Так скажи мне: это безумие? Есть ли лучший/лучший способ сделать это?

Шаг 1: Пользователь вводит текстовый пароль, например. "MyDifficultPassword"
Шаг 2: Приложение хэширует пароль пользователя и использует это значение в качестве симметричного ключа для шифрования/дешифрования файла данных. например "MyDifficultPassword" → "HashedUserPwdAndKey".
Шаг 3: Приложение хэширует хешированное значение с шага 2 и сохраняет новое значение в заголовке файла данных (т.е. незашифрованную часть файла данных) и использует это значение для проверки пароля пользователя. например "HashedUserPwdAndKey" → "HashedValueForAuthentication"

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

Итак, этот дизайн разумно безопасен или безнадежно наивен или где-то посередине? Спасибо!

РЕДАКТ: уточнение и последующий вопрос: соль.
Я думал, что соль должна храниться в секрете, чтобы быть полезной, но ваши ответы и ссылки подразумевают, что это не так. Например, эта спецификация, связанная с erickson (ниже), говорит:

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

Означает ли это, что я могу сохранить значение соли в том же месте/файле, что и хешированный ключ, и все же быть более безопасным, чем если бы я вообще не использовал соль во время хэширования? Как это работает?

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

Ответ 1

Генерация ключей

Я бы рекомендовал использовать распознанный алгоритм, такой как PBKDF2, определенный в PKCS # 5 версии 2.0, чтобы сгенерировать ключ из вашего пароля. Он похож на алгоритм, который вы начертите, но способен генерировать более длинные симметричные ключи для использования с AES. Вы должны иметь возможность находить библиотеку с открытым исходным кодом, которая реализует генераторы ключей PBE для разных алгоритмов.

Формат файла

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

Проверка пароля

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

В качестве альтернативы вы можете вычислить MAC-адрес в контенте. Хеш-столкновение с паролем, скорее всего, будет полезно для злоумышленника; столкновение хэшей по контенту, вероятно, будет бесполезным. Но это могло бы позволить законному получателю знать, что для дешифрования использовался неверный пароль.

Криптографическая соль

Salt помогает помешать предварительно вычисленным атакам по словарю.

Предположим, что у злоумышленника есть список вероятных паролей. Он может хэшировать каждый и сравнивать его с хэшем пароля своей жертвы и видеть, совпадает ли он. Если список большой, это может занять много времени. Он не хочет тратить много времени на свою следующую цель, поэтому он записывает результат в "словарь", где хеш указывает на его соответствующий вход. Если список паролей очень длинный, он может использовать методы, такие как Rainbow Table, чтобы сохранить некоторое пространство.

Однако предположим, что его следующая цель засовывает свой пароль. Даже если злоумышленник знает, что такое соль, его предварительно вычисленный стол бесполезен: соль изменяет хэш, возникающий в результате каждого пароля. Он должен повторно использовать все пароли в своем списке, прикрепляя соль цели к входу. Для каждой различной соли требуется другой словарь, и если будет использоваться достаточное количество солей, у злоумышленника не будет места для хранения словарей для всех. Торговое пространство для экономии времени больше не является вариантом; атакующий должен вернуться к хэшированию каждого пароля в своем списке для каждой цели, которую он хочет атаковать.

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

Ответ 2

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

Конечно, чтение Брюс Шнайер Прикладная криптография никогда не ошибается.

Ответ 3

Если вы используете сильный алгоритм хеширования (SHA-2) и сильный алгоритм шифрования (AES), с этим подходом вы справитесь.

Ответ 4

Почему бы не использовать библиотеку сжатия, которая поддерживает файлы, защищенные паролем? Я использовал защищенный паролем zip файл, содержащий XML-контент в прошлом:}

Ответ 5

Действительно ли нужно сохранить хешированный пароль в файл. Не можете ли вы просто использовать пароль (или хешировать пароль) с некоторой солью, а затем зашифровать файл с ним. При расшифровке просто попробуйте расшифровать файл паролем + соль. Если пользователь вводит неверный пароль, файл с расшифровкой неверен.

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