Совместимость форматов данных в SJCL определяется тем, как библиотека сериализует результаты криптографических операций и какие метаданные сохраняются вместе с зашифрованным текстом. В отличие от низкоуровневых криптографических API, SJCL делает упор на переносимость результата: зашифрованный объект должен быть декодируемым в разных окружениях и версиях библиотеки без ручного разбора внутренних структур.
Результат работы sjcl.encrypt представляет собой
JSON-строку, содержащую набор полей, описывающих параметры шифрования и
сам шифротекст:
iv — вектор инициализацииsalt — соль для KDF (если используется парольное
шифрование)ct — ciphertext (зашифрованные данные)v — версия формата SJCLiter — количество итераций KDFks — размер ключаts — размер тега аутентификацииmode — режим шифрования (например,
ccm)adata — дополнительные аутентифицированные данные (если
указаны)cipher — используемый алгоритм (например,
aes)Ключевым элементом совместимости является поле v. Оно
позволяет библиотеке понимать, как интерпретировать структуру JSON и
какие правила применялись при генерации данных.
SJCL проектировалась с учётом того, что криптографические данные должны оставаться читаемыми при обновлении библиотеки. Поэтому формат сериализации закрепляется через версию, которая влияет на:
На практике изменения между версиями затрагивают не столько структуру JSON, сколько внутреннюю семантику параметров.
Например, более старые версии могли не учитывать некоторые поля или
использовать фиксированные значения параметров KDF, тогда как новые
версии делают их явными (iter, ks).
Наиболее частые источники несовместимости связаны не с самим JSON, а с криптографическими настройками:
Поля iter и ks определяют процесс получения
ключа из пароля. Если:
iterksто данные, зашифрованные в одной версии, могут не быть воспроизведены в другой при неверных параметрах по умолчанию.
Поле mode определяет режим шифрования. Если старое
окружение не поддерживает режим, используемый в новом, дешифрование
становится невозможным, даже если структура JSON корректна.
SJCL использует внутренний формат bitArray для
представления бинарных данных. Он сериализуется в Base64-подобное
представление внутри ct, iv,
salt.
Изменения в реализации:
могут привести к несовпадению расшифровки при использовании разных версий библиотеки.
v в определении совместимостиПоле v в структуре JSON — это основной механизм
определения формата:
Типичный процесс дешифрования начинается с проверки версии:
SJCL часто используется как в браузере, так и в Node.js-окружении. При этом различия могут возникать не только из-за версии библиотеки, но и из-за:
Особенно критично это для:
ivsaltctПоскольку эти поля должны быть идентичны побайтно для корректного восстановления данных.
sjcl.decryptФункция sjcl.decrypt построена так, чтобы максимально
долго поддерживать старые форматы. При этом она:
Однако полная совместимость гарантируется только при сохранении:
cipher)mode)ks, iter)Формат SJCL изначально проектировался как расширяемый JSON-контейнер. Это позволило:
Типичная стратегия расширения:
При переносе зашифрованных данных между версиями SJCL важно учитывать:
v при архивировании данныхЕсли данные были зашифрованы старой версией, но расшифровываются новой, чаще всего достаточно передать оригинальный JSON без изменений.
При использовании модифицированных сборок SJCL совместимость может нарушаться в следующих случаях:
В таких случаях поле v не гарантирует корректную
интерпретацию, так как логика внутри версии может отличаться.
SJCL при декодировании придерживается принципа устойчивости:
ct, iv, salt)Это позволяет сохранять частичную совместимость даже при изменении структуры данных между релизами.