Режим GCM: устройство и параметры

Общая модель работы GCM

Режим GCM (Galois/Counter Mode) объединяет потоковое шифрование в режиме счётчика (CTR) и аутентификацию данных через универсальную хеш-функцию GHASH. В контексте криптобиблиотеки SJCL (Stanford JavaScript Crypto Library) этот режим используется для симметричного шифрования с одновременной защитой целостности и подлинности данных.

GCM работает с двумя основными компонентами:

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

Ключевая особенность режима заключается в том, что шифрование и проверка целостности выполняются в рамках одного прохода по данным, без необходимости отдельного MAC-алгоритма.

Архитектура реализации в SJCL

В SJCL реализация GCM находится в пространстве:

sjcl.mode.gcm

Основные функции:

  • encrypt(key, data, iv, adata, tlen)
  • decrypt(key, data, iv, adata, tlen)

Работа происходит на уровне bitArray, внутреннего формата представления данных в SJCL.

Ключевые зависимости:

  • AES-блок шифрования (sjcl.cipher.aes)
  • арифметика в поле GF(2¹²⁸)
  • операции над bitArray

Основные параметры GCM

Режим GCM в SJCL опирается на набор строго определённых параметров, каждый из которых влияет на безопасность и корректность результата.

Ключ (key)

Ключ передаётся как объект AES:

var aes = new sjcl.cipher.aes(keyBits);

Характеристики:

  • длина: 128, 192 или 256 бит
  • представление: sjcl.bitArray
  • используется как вход в AES-раундовую функцию
IV / Nonce

Инициализационный вектор (IV) играет критическую роль:

  • обычно 96 бит (12 байт) — оптимальный размер для GCM
  • может быть длиннее, но тогда проходит через GHASH для приведения к стандарту
  • должен быть уникальным для каждого шифрования с одним ключом

В SJCL:

iv: sjcl.random.randomWords(4, 0)

Важно: повтор IV с тем же ключом полностью компрометирует безопасность режима.

Данные (data)

Входные данные:

  • представляются как sjcl.bitArray
  • шифруются в CTR-режиме
  • одновременно участвуют в вычислении GHASH
Дополнительные аутентифицированные данные (AAD / adata)

AAD не шифруется, но включается в аутентификационный тег.

Используется для:

  • заголовков протоколов
  • метаданных
  • идентификаторов сессий

В SJCL:

adata: sjcl.codec.utf8String.toBits("header")

GHASH учитывает AAD до начала обработки ciphertext.

Длина тега (tlen)

Параметр определяет размер аутентификационного тега:

  • 32, 64, 96, 104, 112, 120 или 128 бит
  • стандартное значение — 128 бит

Пример:

tlen: 128

Снижение длины тега уменьшает криптостойкость аутентификации.

Процесс шифрования в SJCL GCM

Алгоритм включает несколько стадий.

1. Генерация начального блока CTR

Из IV формируется начальный counter block:

  • для 96-битного IV:

    J0 = IV || 0x00000001

  • для других размеров IV: используется GHASH над IV

2. Шифрование данных

Каждый блок plaintext:

C_i = P_i ⊕ E_K(CTR_i)

CTR инкрементируется на каждом шаге.

3. Вычисление GHASH

GHASH строится как полиномиальная функция в поле GF(2¹²⁸):

X_i = (X_{i-1} ⊕ block_i) · H

Где:

  • H = E_K(0¹²⁸)

  • block_i включает:

    • ciphertext
    • AAD
    • длины данных
4. Формирование тега

Финальный тег:

T = MSB_tlen( E_K(J0) ⊕ GHASH )

Внутренние структуры SJCL

SJCL использует несколько специфичных представлений:

bitArray

Основная структура данных:

  • массив 32-битных слов
  • последние биты кодируют длину
Операции XOR и сдвиги

Используются для:

  • CTR-инкремента
  • GHASH вычислений
  • объединения блоков AAD и ciphertext

Особенности реализации SJCL GCM

Отсутствие аппаратной оптимизации

В отличие от нативных реализаций:

  • все операции выполняются в JavaScript
  • GHASH реализован через битовые операции
  • производительность ниже криптобиблиотек на WebCrypto API
Обработка IV нестандартной длины

Если IV ≠ 96 бит:

  • выполняется GHASH от IV
  • добавляется длина IV в битах
  • результат становится J0
Совмещение шифрования и аутентификации

SJCL строго разделяет:

  • поток CTR для конфиденциальности
  • GHASH для целостности

но выполняет их синхронно в одном проходе данных.

Типовые ошибки использования GCM в SJCL

Повтор IV

Использование одного IV дважды с тем же ключом приводит к:

  • раскрытию XOR между сообщениями
  • восстановлению plaintext
Игнорирование AAD

Если AAD используется на одной стороне и не используется на другой:

  • проверка тега всегда проваливается
Неправильная длина тега

Сокращение tlen без согласования:

  • вызывает несовместимость декодирования
  • снижает криптостойкость
Ошибки работы с bitArray

Частые проблемы:

  • неправильное кодирование UTF-8
  • потеря длины битового массива
  • смешение байтовых и битовых представлений

Пример использования SJCL GCM

var key = sjcl.codec.hex.toBits("00112233445566778899aabbccddeeff");
var aes = new sjcl.cipher.aes(key);

var iv = sjcl.random.randomWords(4, 0);
var data = sjcl.codec.utf8String.toBits("secret message");
var adata = sjcl.codec.utf8String.toBits("header");

var encrypted = sjcl.mode.gcm.encrypt(aes, data, iv, adata, 128);

Дешифрование и проверка тега

При расшифровании выполняется:

  • повторное вычисление GHASH
  • сравнение тега
  • расшифровка CTR только при успешной проверке

Любое расхождение тега приводит к немедленному отказу обработки данных.

Криптографические свойства режима

GCM в SJCL обеспечивает:

  • конфиденциальность через AES-CTR
  • аутентичность через GHASH
  • защиту от подмены данных
  • детерминированную проверку целостности

Критическим условием безопасности остаётся уникальность IV и корректная синхронизация параметров между сторонами обмена.

Оглавление