Безопасно ли шифровать строку, используя ту же строку, что и ключ?

Question

Существуют ли какие-либо недостатки безопасности при шифровании данного ключа с помощью самого себя с использованием AES в режиме CBC и использованием IV (конечно)?

Принципы соблюдены: ключ является секретным, а ключ IVpublic (поскольку это не влияет на безопасность шифрования).

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

Мое мнение не видит никаких проблем, но я пытаюсь убедиться.

Спасибо.

РЕДАКТИРОВАТЬ - подробности задания, я надеюсь, что яЯ смогу их четко передать, но для меня это еще не очень понятно:

1. Моя система использует шифрование для хранения определенных значений в таблицах MySQL.Шифрование выполняется на PHP-коде (а не на встроенном AES MySQL).Очевидно, мне нужен секретный ключ, который должен быть настроен системным администратором, просто ОДИН РАЗ, при настройке системы.Это очень важно, потому что изменение ключа после того, как любые зашифрованные данные были сохранены как таковые, сделает эти данные недоступными для расшифровки.

2. Администратор может установить секретный ключ, просто отредактировав файл сценария PHPчерез FTP (или как угодно).Но это не то, что я хочу.

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

Если у вас есть какие-либо идеи относительно вышеизложенного, это будет высоко оценено.

Спасибо.

Answer 1

Вопрос в том, какой смысл?Если вы хотите расшифровать строку, вы должны знать строку уже;если вы этого не знаете, вы не сможете расшифровать его.Это возможно, но бессмысленно ИМХО.

Answer 2

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

Answer 3

Как вы упомянули в своем комментарии в ответе Джеспера, «сила находится в ключе шифрования» и в алгоритме шифрования.Если оба сильны, это должно быть безопасно.Насколько я знаю, техническая слабая связь сильного шифрования и ключа находится в реализации, если таковая имеется.

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

Редактировать Это не совсем ответ на вопрос в заголовке поста, но я полагаю, что это актуально для вашего обновленного поста:

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

Должна быть небольшая разница в безопасности, независимо от того, храните ли вы зашифрованный мастер-ключ сам или храните криптографический хешотмычка.Если предположить, что и криптографический хэш, и AES в режиме CBC одинаково безопасны, сила заключается в силе мастер-ключа.

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

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

Надеюсь, я правильно понял ваш пост какхорошо.

Отказ от ответственности: я не эксперт по безопасности, ни в сфере безопасности.

Answer 4

Первое: не совсем эксперт по безопасности.

Итак, чтобы получить это на данный момент, вы хотите сохранить секретное значение и иметь возможность получить только секретное значение, но сообщая ему секретное значение?:)

Но я могу видеть, куда вы хотите пойти с этим, для системы паролей (возможно), вы можете просто проверить их вместе.

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

Так что я бы по крайней мере рекомендовал ключ, который представляет собой составную частьпароль + record_hash + shared_hash

ОБНОВЛЕНИЕ: я вижу, что хакер будет иметь доступ к коду, затем попытайтесь сохранить shared_hash в месте, к которому он не может получить доступ.