Структура зашифрованного JSON-объекта

При использовании sjcl.encrypt() библиотека возвращает строку, содержащую сериализованный JSON-объект. Этот объект представляет собой полностью самодостаточное описание зашифрованных данных и всех параметров, необходимых для их расшифровки.

Структура сформирована таким образом, чтобы любой клиент, обладающий корректным паролем или ключом, мог восстановить исходный текст без внешних зависимостей и дополнительных метаданных.

Базовый вид зашифрованного объекта

После выполнения шифрования результат имеет следующую логическую структуру:

{
  "iv": "...",
  "v": 1,
  "iter": 10000,
  "ks": 128,
  "ts": 64,
  "mode": "ccm",
  "adata": "",
  "cipher": "aes",
  "salt": "...",
  "ct": "..."
}

Каждое поле играет строго определённую роль в процессе восстановления данных и обеспечения криптографической устойчивости.

Поле ct — зашифрованный текст

ct (ciphertext) — основное содержимое объекта.

  • Представляет собой зашифрованные данные
  • Кодируется в Base64
  • Не содержит никакой информации о структуре исходного текста
  • Может быть произвольной длины

Именно это поле является результатом применения симметричного шифрования к исходной строке.

Поле iv — вектор инициализации

iv (initialization vector) используется для обеспечения уникальности шифрования даже при одинаковом ключе и одинаковых данных.

Особенности:

  • Кодируется в Base64
  • Генерируется случайным образом при каждом шифровании
  • Используется алгоритмами режима шифрования (например, CCM)
  • Не должен повторяться при одном и том же ключе

Отсутствие уникального IV приводит к криптографической уязвимости, позволяющей анализировать повторяющиеся блоки данных.

Поле salt — криптографическая соль

salt применяется на этапе преобразования пароля в ключ.

Функции соли:

  • Делает невозможным использование радужных таблиц
  • Обеспечивает уникальность ключа даже при одинаковых паролях
  • Используется в PBKDF2 (внутренний KDF SJCL)

Соль:

  • Всегда случайная
  • Хранится вместе с зашифрованными данными
  • Не является секретной

Поле iter — количество итераций PBKDF2

iter определяет, сколько раз выполняется функция деривации ключа.

  • Увеличивает стойкость к brute-force атакам
  • Прямо влияет на производительность
  • Обычно значения находятся в диапазоне от 1000 до 100000+

Пример влияния:

  • больше итераций → выше безопасность
  • больше итераций → медленнее шифрование и расшифрование

Поле ks — размер ключа

ks (key size) указывает размер производного ключа в битах.

Типичные значения:

  • 128
  • 192
  • 256

В SJCL чаще всего используется 128 или 256 бит в зависимости от конфигурации AES.

Поле ts — размер тега аутентификации

ts (tag size) отвечает за длину MAC (Message Authentication Code).

Назначение:

  • Проверка целостности данных
  • Защита от модификации ciphertext

Типичные значения:

  • 64
  • 96
  • 128

Чем больше значение, тем выше устойчивость к подделке данных.

Поле mode — режим работы блочного шифра

mode определяет режим работы AES.

В SJCL часто используется:

  • "ccm" — Counter with CBC-MAC

Особенности CCM:

  • обеспечивает конфиденциальность и аутентификацию
  • объединяет шифрование и контроль целостности
  • широко используется в прикладной криптографии

Поле cipher — используемый алгоритм

cipher указывает алгоритм симметричного шифрования.

В SJCL стандартное значение:

  • "aes"

Это означает использование AES (Advanced Encryption Standard), обычно с ключами 128/192/256 бит.

Поле adata — дополнительные аутентифицированные данные

adata (additional authenticated data) — необязательное поле.

Особенности:

  • не шифруется
  • участвует в проверке целостности
  • изменение приводит к ошибке расшифровки

Применяется для:

  • заголовков сообщений
  • метаданных
  • контрольных строк

Если не используется, поле обычно пустое:

"adata": ""

Поле v — версия формата SJCL

v указывает версию формата сериализации.

  • используется для обратной совместимости
  • позволяет библиотеке корректно интерпретировать структуру объекта

Пример:

"v": 1

Внутреннее представление и сериализация

SJCL не возвращает объект напрямую — результат всегда сериализуется в строку JSON.

Пример:

var encrypted = sjcl.encrypt("password", "секретный текст");

Результат:

"{"iv":"...","v":1,"iter":10000,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"...","ct":"..."}"

При необходимости строка может быть преобразована обратно в объект:

var obj = JSON.parse(encrypted);

Связь структуры с процессом шифрования

Каждое поле напрямую отражает этап криптографического пайплайна:

  1. salt + password → key (PBKDF2)
  2. iv → начальное состояние шифрования
  3. cipher + mode → алгоритм AES-CCM
  4. ct → результат шифрования
  5. ts → контроль целостности
  6. adata → дополнительная аутентификация

Особенности хранения и передачи

Структура SJCL-объекта спроектирована так, чтобы:

  • быть самодостаточной
  • не требовать внешних параметров
  • безопасно передаваться через JSON API
  • храниться в базах данных как строка

Часто объект передаётся:

  • через REST API
  • в localStorage / sessionStorage
  • в cookies (с ограничениями)
  • через WebSocket

Типичные ошибки при работе со структурой

Изменение ciphertext

Любая модификация ct приводит к ошибке:

  • нарушается MAC
  • расшифровка становится невозможной

Потеря salt или iv

Без этих полей:

  • невозможно восстановить ключ
  • расшифровка полностью невозможна

Изменение iter или ks

Нарушает процесс деривации ключа:

  • приводит к неверному ключу
  • расшифровка завершается ошибкой

Итоговая логическая модель объекта

С точки зрения криптосистемы SJCL объект можно представить как:

  • Конфигурация шифрования: cipher, mode, ks, iter, ts
  • Криптографические параметры: iv, salt
  • Аутентификация: adata
  • Результат: ct
  • Служебные данные: v

Эта структура обеспечивает полную воспроизводимость процесса расшифрования при наличии корректного пароля и исходных параметров.

Оглавление