Подходящая альтернатива CryptEncrypt

В нашем продукте есть ситуация, когда в течение длительного времени некоторые данные сохранялись в базе данных приложения в виде строки SQL (выбор сервера MS SQL или Sybase SQL в любом месте), которая была зашифрована с помощью функции Windows API CryptEncrypt. (прямой и дешифруемый)

Проблема заключается в том, что CryptEncrypt может выдавать значения NULL в выводе, что означает, что при сохранении в базе данных манипуляции со строками в какой-то момент усекают CipherText.

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

Алгоритм не обязательно должен быть максимально безопасным, так как база данных уже находится в достаточно безопасной среде (не в открытой сети / между сетями), но должна быть лучше, чем ROT13 (которую я почти могу расшифровать в своей голове Теперь!)

редактировать: кстати, есть какая-то конкретная причина для изменения зашифрованного текста на зашифрованный текст? шифртекст кажется более широко используемым ...

20.08.2008 09:37:02
4 ОТВЕТА
РЕШЕНИЕ

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

Почему бы не сделать что-то вроде base-64 для кодирования полученного двоичного двоичного объекта перед сохранением в БД? ( пример реализации в C ++ ).

3
20.08.2008 09:49:56

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

0
20.08.2008 10:06:03

Хранить хеш - хорошая идея. Тем не менее, пожалуйста, обязательно прочитайте Джеффа « Вы, вероятно, храните пароли неправильно» .

1
20.08.2008 10:41:15

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

0
20.08.2008 11:16:49