Проверка корректности интеграции SJCL начинается с анализа того, каким образом библиотека включена в проект и какие именно компоненты криптографического стека используются. SJCL (Stanford Javascript Crypto Library) предоставляет набор примитивов: симметричное шифрование, хеш-функции, генерацию случайных чисел, режимы работы блочных шифров и утилиты кодирования. Ошибки на уровне интеграции почти всегда приводят к компрометации всей криптографической модели, независимо от корректности отдельных алгоритмов.
Первый слой аудита связан с тем, как библиотека попадает в приложение. SJCL может использоваться как:
sjcl.js)Критически важно исключить модифицированные или урезанные сборки без контроля списка включённых модулей. При аудите фиксируется:
Особое внимание уделяется параметрам сборки, так как отключение части энтропийных источников или PRNG-расширений снижает криптостойкость.
SJCL поддерживает несколько режимов работы AES, включая CBC и CCM. В аудите проверяется:
Классическая ошибка — использование AES-CBC без MAC, что приводит к отсутствию целостности данных.
Критический момент: IV должен быть уникальным для каждого сообщения. Повтор IV в CBC или CCM разрушает безопасность схемы.
Ключевая зона аудита — обработка криптографических ключей. В SJCL
ключи часто передаются как битовые массивы (sjcl.bitArray),
и любые преобразования должны быть строго детерминированными.
Проверяются следующие аспекты:
localStorage или
sessionStorage без шифрованияОтдельно анализируется, не происходит ли сериализация ключей в JSON без защиты.
SJCL использует собственный PRNG, основанный на ARC4 и энтропийном пуле. Аудит включает проверку:
sjcl.random.addEntropyТиповая уязвимость — запуск генерации ключей до накопления энтропии, что приводит к предсказуемым результатам PRNG.
Критически важно убедиться, что используется:
sjcl.random.isReady()или аналогичный механизм ожидания готовности генератора.
PRNG в SJCL должен быть проверен на:
Недопустимо фиксированное seed-значение, даже в тестовых окружениях, если оно может попасть в production-бандл.
В рамках SJCL обычно используются:
При аудите проверяется:
Пример проблемной конструкции:
var hash = sjcl.hash.sha256.hash(password + salt);Корректная схема должна использовать PBKDF2:
sjcl.misc.pbkdf2(password, salt, iterations, keySize);SJCL активно использует форматирование битовых массивов. Аудит включает:
sjcl.codechex/base64
преобразованияхОшибки сериализации часто приводят к невозможности повторного расшифрования данных или к уязвимостям при неявных преобразованиях типов.
Ошибки расшифрования не должны раскрывать различимые причины. Аудит проверяет:
Часто критические данные попадают в:
Аудит выявляет:
Даже временные debug-вставки рассматриваются как потенциальный риск, если они могут попасть в production-сборку.
JavaScript-среда накладывает ограничения, которые необходимо учитывать при аудите:
Особое внимание уделяется:
function encryptData(key, data) {
var iv = sjcl.random.randomWords(4, 0);
var cipher = new sjcl.cipher.aes(key);
return sjcl.mode.ccm.encrypt(cipher, data, iv);
}Анализ выявляет следующие точки проверки:
Аудит включает моделирование неправильных сценариев:
Система должна корректно обрабатывать все случаи без деградации до небезопасного состояния.
Версия библиотеки должна быть зафиксирована. Проверяются:
Даже незначительные изменения в реализации PRNG или mode cipher могут менять уровень безопасности всей системы.