В нашем продукте есть ситуация, когда в течение длительного времени некоторые данные сохранялись в базе данных приложения в виде строки SQL (выбор сервера MS SQL или Sybase SQL в любом месте), которая была зашифрована с помощью функции Windows API CryptEncrypt. (прямой и дешифруемый)
Проблема заключается в том, что CryptEncrypt может выдавать значения NULL в выводе, что означает, что при сохранении в базе данных манипуляции со строками в какой-то момент усекают CipherText.
В идеале мы хотели бы использовать алгоритм, который будет производить CipherText, который не содержит NULL, поскольку это приведет к наименьшему количеству изменений в существующих базах данных (изменение столбца со строки на двоичный и кода для работы с двоичным кодом вместо строк) и просто расшифровывать существующие данные и повторно шифровать с новым алгоритмом во время обновления базы данных.
Алгоритм не обязательно должен быть максимально безопасным, так как база данных уже находится в достаточно безопасной среде (не в открытой сети / между сетями), но должна быть лучше, чем ROT13 (которую я почти могу расшифровать в своей голове Теперь!)
редактировать: кстати, есть какая-то конкретная причина для изменения зашифрованного текста на зашифрованный текст? шифртекст кажется более широко используемым ...
Любой полуприличный алгоритм в конечном итоге с большой вероятностью генерирует значение NULL где-нибудь в результирующем зашифрованном тексте.
Почему бы не сделать что-то вроде base-64 для кодирования полученного двоичного двоичного объекта перед сохранением в БД? ( пример реализации в C ++ ).
Это интересный маршрут OJ. Мы смотрим на выполнимость необратимого метода (по-прежнему следя за тем, чтобы мы не извлекали данные явно для расшифровки), например, просто сохраняем хэш для сравнения при отправке
Хранить хеш - хорошая идея. Тем не менее, пожалуйста, обязательно прочитайте Джеффа « Вы, вероятно, храните пароли неправильно» .
Похоже, что разработчик, обрабатывающий это, собирается обернуть существующее шифрование с помощью yEnc, чтобы сохранить целостность таблицы, так как данные должны быть извлекаемыми, и это избавит от всего этого беспорядочного бреда с бесконечно-маловероятным. укоренившиеся установки. Ура ребята