Как поменять ключ aes-256 после шифрования?

Вам не нужно повторно шифровать все данные пользователя, когда они меняют свой пароль.

Сгенерировать секретный ключ для шифрования данных пользователя; назовите это «ключом шифрования содержимого». Получите ключ из пароля пользователя; назовите это «ключом шифрования». Зашифруйте «ключ шифрования содержимого» с помощью «ключа шифрования». Сохраните зашифрованный ключ вместе с солью и количеством итераций, используемых для получения ключа.

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

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

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

Эта концепция соответствует проекту шифрования S / MIME на основе пароля.

Во-первых, обычно не следует использовать пароль в качестве ключа AES. Может быть, что-то вроде криптографического хеша (не MD5) пароля + соль (в этом случае вы бы сохранили соль, но не хеш).

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

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

Как это работает?

• Вы шифруете данные D для пользователя U с помощью случайно сгенерированного ключа K _{U, D}.
• Вы шифруете ключ K _{U, D} отдельным ключом K1 _{U, K}, сгенерированным из случайной соли, S1 _U (который вы сохраняете запись) и пароль пользователя P1 _U (который вы можете или не можете отслеживать). Зашифрованный ключ - E1 _U.
• Вы храните S1 _U и K1 _{U, K} наготове, когда пользователь захочет получить доступ к своим данным.
• Когда пользователь U хочет получить доступ к своим данным, он предоставляет вам свой пароль, P1 _U, и вы просматриваете S1 _U и регенерируете K1 _{U, K из этих данных и используйте это для дешифрования E1 U, давая вам еще раз K U, D, с помощью которых вы расшифруете их фактические данные.}
• Вы гарантируете, что сможете определить правильный пароль, чтобы не извергать бинарную чушь, если пользователи вводят неправильный пароль.

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

На уровне косвенного обращения вы по-прежнему запрашиваете у пользователя их старый пароль (P1 _U) и новый пароль (P2 _U) и проверяете их, но вам нужно только расшифровать E1 _U, а затем повторно зашифровать его новым ключом K2 _{U, K}, сгенерированным из новой соли S2 _U и нового пароля P2 _U. Вам вообще не нужно трогать зашифрованные данные.

При уровне косвенного обращения система S может также хранить вторую зашифрованную копию ключа данных K _{U, D}, зашифрованную системным паролем. Если становится необходимым или желательным изменить ключ, используемый для шифрования данных, система может использовать для этого свою зашифрованную копию ключа. Он может вести запись о том, какой ключ последний раз был записан пользователем в свой ключ, поэтому, когда пользователь вернется, чтобы просмотреть данные, он может изменить сохраненный ключ K2 _{U, D}, потому что в это время у него есть их пароль (в остальное время его нет).

Это небольшая вариация некоторых идей в "Криптографии в База данных: последний рубеж защиты »Кевина Кенана. Ключи Kn _{U, K} являются примерами KEK, ключа шифрования ключа. Вы также можете прочитать в книге о ключевых семействах, которые помогут в управлении зашифрованными данными.

Это глупо.

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