Правильное / безопасное шифрование данных с использованием AES и пароля - PullRequest
0 голосов
/ 23 февраля 2012

Прямо сейчас, это то, что я делаю: 1. SHA-1 пароль типа «pass123», используйте первые 32 символа шестнадцатеричного декодирования для ключа 2. Зашифруйте с помощью AES-256 только с параметрами по умолчанию ^ Это достаточно безопасно?

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

Итак, теперь, когда я пытаюсь сделать это более правильно, пожалуйста, следуйте тому, что я имею в виду:

  1. Вводится пароль, такой как «pass123», а данные то, что я хочу зашифровать, например, «Банковский счет 038414838 и пин-код 5931»

  2. Используйте PBKDF2 для получения ключа из пароля. Параметры: 1000 итераций длина 256 бит Соль - это меня смущает, потому что я не знаю, где взять соль, я просто ее придумаю? Например, во всех моих шифрах всегда будет использоваться соль "F" (так как очевидно, что соли - это 8 битов, то есть всего один символ)

  3. Теперь я беру этот ключ и хеширую его ?? Должен ли я использовать что-то вроде SHA-256? Это безопасно? А что такое HMAC? Должен ли я использовать это? Примечание. Нужно ли выполнять оба шага 2 и 3 или все в порядке?

  4. Хорошо, теперь у меня есть 256-битный ключ для шифрования. Поэтому я выполняю шифрование с использованием AES, но здесь есть еще одна запутанная часть (параметры). Я не совсем уверен, какие разные "режимы" использовать, по-видимому, есть как CBC и EBC и куча других Я также не уверен насчет «вектора инициализации», я просто придумываю его и всегда использую его? А как насчет других опций, что такое PKCS7Padding?

1 Ответ

1 голос
/ 23 февраля 2012

Для ваших начальных очков:

  1. Использование шестнадцатеричных значений четко делит размер ключа пополам. По сути, вы используете AES-128 с точки зрения безопасности. Не то чтобы это плохо, но вы также можете использовать AES-128 и использовать 16 байтов.
  2. SHA-1 относительно безопасен для получения ключа, но его не следует использовать напрямую из-за существования / создания радужных таблиц. Для этого вам нужна функция типа PBKDF2, которая использует счетчик итераций и соль.

Что касается решения:

  1. Вы не должны шифровать PIN-коды, если этого можно избежать. Пожалуйста, убедитесь, что ваши пароли достаточно безопасны, разрешите парольные фразы.
  2. Создайте случайное число для каждого пароля и сохраните соль (16 байт) с выводом PBKDF2. Соль не должна быть секретной, хотя вы можете включить системный секрет, чтобы добавить дополнительную безопасность. Соль и пароль хэшируются, поэтому они могут иметь любую длину для совместимости с PBKDF2.
  3. Нет, вы просто сохраняете секрет, сгенерированный PBKDF2, позволяя PBKDF2 генерировать больше данных при необходимости.
  4. Никогда не используйте ECB (не EBC). Используйте CBC как минимум. Обратите внимание, что шифрование CBC не обеспечивает проверку целостности (кто-то может изменить текст шифра, а вы никогда не узнаете его) или аутентичность. Для этого вы можете добавить дополнительный MAC, HMAC или использовать режим шифрования, такой как GCM. PKCS7Padding (идентичный PKCS5Padding в большинстве случаев) - это простой метод добавления поддельных данных для получения N * [блочных размеров] байтов, необходимых для блочного шифрования.

Не забудьте добавить (случайный) IV к вашему зашифрованному тексту на случай, если вы снова используете свои ключи шифрования. IV похож на соль, но должен быть точно [размер блока] байтов (16 для AES).

...