концепция симметричного шифрования AES

Question

У меня есть проект для сайта, работающего на Django.Одной из функций этого является сохранение пользователя / пароля для стороннего веб-сайта.Таким образом, это должно быть симметричное шифрование, поскольку оно должно использовать эти учетные данные в автоматизированном процессе.Я знаю, что хранить учетные данные не очень хорошая идея, но для этого случая другого варианта нет.Моя идея до сих пор состоит в том, чтобы создать приложение Django, которое будет сохранять и использовать эти пароли, и больше ничего не делать.При этом у меня может быть 2 «веб-сервера», которые не будут получать никаких запросов извне, а будут получать задания только через Redis или что-то еще.Поэтому я могу в некоторой степени изолировать их (они являются единственными серверами, которые будут иметь доступ к этой дополнительной базе данных, они не будут обрабатывать любые веб-запросы и т. Д.) Первый вопрос: звучит ли этот план убедительно или есть серьезный недостаток?

Второй вопрос касается самого шифрования: AES требует ключ шифрования для всей своей работы, хорошо, его нужно каким-то образом «защитить».Но меня больше интересует IV.Каждый пользователь может иметь один или несколько наборов учетных данных, сохраненных в дополнительной базе данных.Было бы хорошей идеей использовать какой-то хэш сортировки над идентификатором пользователя или что-то подобное для генерации пользовательского IV для каждого пользователя?Большую часть времени я вижу, что IV генерируется случайным образом.Но тогда мне придется также хранить их где-то в дополнение к ключу.Для меня это становится немного запутанным здесь.Мне нужен ключ и IV, чтобы расшифровать, но я бы «сохранил» их таким же образом.Так что, если кто-то будет скомпрометирован, вряд ли это будет IV?Будет ли тогда иметь значение, если я сгенерирую IV на лету по известной процедуре?Проблема в том, что каждый может знать IV, если знает свой идентификатор пользователя, так как код будет с открытым исходным кодом ....

В конце концов, мне нужно несколько указаний, как обращаться с ключом и лучшим уникальным IVна пользователя.Большое спасибо за чтение до сих пор: -)

Answer 1

Этот план звучит твердо или в нем есть существенный недостаток?

Необходимость сохранения учетных данных является недостатком в дизайне, по крайней мере, мы все понимаем, что вы знаете об этом,

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

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

Да, в этом вся проблема.

для создания пользовательского IV для каждого пользователя?

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

Будет ли тогда какая-то разница, если я сгенерирую IV на лету по известной процедуре?

IV не обязательно должен быть секретным.

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