Сведения о вопросе

Fhohir

10:34, 19th August, 2020

Теги

c++   encryption   winapi    

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

Просмотров: 441   Ответов: 4

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

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

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

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

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



  Сведения об ответе

repe

17:40, 4th August, 2020

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

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


  Сведения об ответе

dumai

23:17, 23rd August, 2020

Хранение hash-хорошая идея. Однако, пожалуйста, обязательно прочитайте Джеффа, вы, вероятно, храните пароли неправильно .


  Сведения об ответе

qwerty101

03:11, 26th August, 2020

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


  Сведения об ответе

9090

17:25, 2nd August, 2020

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться