Обзор криптографии в Qt: QCryptographicHash, OpenSSL, QCA

Введение

Темы безопасности уже затрагивались в основном цикле статей (статья 215, десктопные приложения) и в IoT/gRPC-циклах (TLS, статьи 318, 329) — но точечно, в контексте конкретной задачи. В этой статье начинаем отдельный, систематический цикл про криптографию: какие инструменты доступны в экосистеме Qt/C++, и для каких задач каждый из них подходит.

Концепция

QCryptographicHash — встроенный в Qt класс, дающий хеширование (статья 372) без каких-либо дополнительных зависимостей, но не предоставляющий шифрование. Для шифрования (симметричного, асимметричного, статьи 373-374) и цифровых подписей (статья 375) стандартный подход — OpenSSL, индустриальный стандарт с C-API (libcrypto), доступный из C++ напрямую или через более удобные обёртки. QCA (Qt Cryptographic Architecture) — отдельный, не входящий в основной Qt модуль, дающий более Qt-идиоматичный интерфейс поверх различных криптографических библиотек-провайдеров (включая OpenSSL), но менее активно поддерживаемый, чем сам OpenSSL — выбор между прямым использованием OpenSSL и QCA в статье разбирается как практическое архитектурное решение.

Пример кода: Обзор криптографии в Qt

// QCryptographicHash — простейший случай, не требующий внешних зависимостей
#include <QCryptographicHash>

QByteArray computeSha256(const QByteArray &data)
{
    return QCryptographicHash::hash(data, QCryptographicHash::Sha256);
}

// OpenSSL EVP API — для случаев, где нужно шифрование, а не только хеширование
#include <openssl/evp.h>
#include <openssl/rand.h>

bool isOpenSslAvailable()
{
    // Простая проверка инициализации библиотеки — реальное использование разбирается в статьях 373-375
    return OpenSSL_version_num() > 0;
}

# CMakeLists.txt — подключение OpenSSL через CMake (предпочтительный способ для большинства проектов)
find_package(OpenSSL REQUIRED)
target_link_libraries(MyApp PRIVATE OpenSSL::Crypto OpenSSL::SSL)

Пояснения к коду

QCryptographicHash::hash() — статический метод, не требующий создания объекта для простого, разового хеширования всего массива данных целиком; для потокового хеширования больших объёмов данных (без загрузки всего файла в память сразу) существует обычный, не статический интерфейс с методом addData(), разбираемый в статье 372. Подключение OpenSSL через find_package(OpenSSL REQUIRED) и таргеты OpenSSL::Crypto/OpenSSL::SSL — современный, рекомендуемый способ интеграции в CMake-проект, продолжающий подход к управлению зависимостями из основного цикла статей про CMake (в отличие от устаревшего поиска через переменные OPENSSL_LIBRARIES/OPENSSL_INCLUDE_DIR напрямую).

Подводные камни

• Попытка реализовать криптографические алгоритмы самостоятельно, «с нуля», вместо использования проверенных, тщательно протестированных библиотек (OpenSSL и аналогичные) — это, возможно, самая фундаментальная и опасная ошибка во всей теме криптографии: даже корректная на первый взгляд реализация стандартного алгоритма (AES, RSA) почти наверняка будет содержать тонкие, незаметные при обычном тестировании уязвимости (атаки по времени выполнения, неправильная обработка edge-case значений), которые опытные криптографы устраняли в проверенных библиотеках годами; это правило — «не изобретайте свою криптографию» — будет повторяться во всех последующих статьях цикла как основной принцип.
• Путаница между хешированием и шифрованием как взаимозаменяемыми понятиями — хеширование (статья 372) — необратимая операция, не предназначенная для последующего восстановления исходных данных, тогда как шифрование (статьи 373-374) обратимо при наличии правильного ключа; использование хеша там, где нужно шифрование (или наоборот) — частая концептуальная ошибка, особенно среди разработчиков без специального опыта в криптографии.
• Использование устаревшей версии OpenSSL без актуальных исправлений безопасности — криптографические библиотеки регулярно получают патчи, устраняющие реально эксплуатируемые уязвимости (Heartbleed — известный исторический пример именно для OpenSSL), и использование значительно устаревшей, давно не обновлявшейся версии библиотеки представляет реальный риск безопасности, а не просто формальное несоответствие «лучшим практикам».
• Выбор QCA для нового проекта без проверки текущего состояния поддержки этого модуля — поскольку QCA менее активно поддерживается, чем сам OpenSSL или текущие основные модули Qt, для нового проекта стоит явно проверить актуальность последнего релиза и активность сообщества перед тем, как закладывать на него архитектурную зависимость, и для большинства новых проектов прямое использование OpenSSL через CMake — более предсказуемый, долгосрочно поддерживаемый выбор.