Константы и типы ошибок

Библиотека Iron реализует механизм «sealing» — криптографическое упаковывание данных с последующей аутентификацией и шифрованием. Внутри используется набор параметров, которые задают поведение алгоритмов шифрования и проверки целостности.

Базовые параметры алгоритмов

В Iron ключевыми являются настройки, которые часто рассматриваются как константы уровня конфигурации:

  • encryption — алгоритм симметричного шифрования данных По умолчанию используется aes-256-cbc, обеспечивающий баланс между производительностью и криптостойкостью.

  • integrity — алгоритм вычисления HMAC Часто применяется sha256, который отвечает за проверку целостности и подлинности данных.

  • minPasswordlength — минимальная длина пароля Обычно задана значением 32, что связано с требованиями криптографической стойкости ключевого материала.

  • ttl (time to live) — время жизни защищённого объекта Определяет срок действия sealed-данных. По умолчанию может быть не задан, что означает отсутствие автоматического истечения.

  • timestampSkewSec — допустимое отклонение времени Используется при проверке временных меток для компенсации рассинхронизации часов между системами.

  • localtimeOffsetMsec — локальная поправка времени Позволяет учитывать смещение локального времени относительно серверного.

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

Константность как архитектурный принцип

Iron не стремится к большому числу жёстко зашитых констант. Вместо этого используется подход конфигурационной предсказуемости: значения по умолчанию определены библиотекой, но могут быть переопределены пользователем.

Такой подход снижает связанность кода и позволяет адаптировать библиотеку под разные требования безопасности:

  • усиление алгоритмов шифрования при повышенных требованиях
  • настройка TTL для токенов и сессионных данных
  • управление допустимой погрешностью времени в распределённых системах

Типы ошибок Iron

Модель обработки ошибок в Iron построена вокруг набора специализированных классов, отражающих конкретные этапы процесса seal и unseal.

Все ошибки наследуются от базового типа Error, но разделяются по причинам возникновения.

Ошибки формата и структуры данных

Bad Format Error

Возникает при попытке распарсить строку, не соответствующую внутреннему формату sealed-данных.

Причины:

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

Ошибки криптографической проверки

Bad HMAC Error

Возникает при несоответствии контрольной суммы.

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

Характерные сценарии:

  • подмена токена
  • использование неправильного password
  • повреждение данных при передаче

Decryption Error

Возникает при невозможности расшифровать payload.

Причины:

  • неверный ключ шифрования
  • повреждённый ciphertext
  • несовместимость алгоритмов шифрования

Ошибки аутентификации

Invalid Password Error

Возникает при использовании некорректного пароля, который не может быть использован для расшифровки или проверки целостности.

В контексте Iron пароль является основным источником ключевого материала, поэтому ошибка указывает на полное несоответствие криптографического контекста.


Ошибки временных ограничений

Expiration Error

Возникает при истечении срока действия данных (TTL).

Проверка выполняется на этапе unseal и учитывает:

  • timestamp внутри sealed-структуры
  • значение ttl
  • допустимое смещение времени (timestampSkewSec)

Ошибки процесса sealing/unsealing

Seal Error

Обобщённая ошибка, возникающая при невозможности корректно выполнить операцию упаковки данных.

Может быть связана с:

  • неверными параметрами конфигурации
  • недостаточной длиной ключа
  • внутренними сбоями криптографических операций

Unsealing Error

Возникает при невозможности извлечь исходные данные из sealed-строки.

Является контейнерной ошибкой, которая может оборачивать другие типы:

  • Bad Hmac Error
  • Decryption Error
  • Expiration Error

Структура и иерархия ошибок

Ошибки Iron не являются случайным набором классов. Их структура отражает этапы жизненного цикла данных:

  1. Парсинг

    • Bad Format Error
  2. Проверка целостности

    • Bad Hmac Error
  3. Расшифровка

    • Decryption Error
  4. Валидация доступа

    • Invalid Password Error
    • Expiration Error
  5. Обобщённый уровень

    • Seal Error
    • Unsealing Error

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


Особенности обработки ошибок в Iron

Механизм ошибок спроектирован так, чтобы минимизировать утечку чувствительной информации:

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

Это делает библиотеку безопасной для использования в серверных приложениях, где токены и сессионные данные проходят через публичные интерфейсы.


Практическое поведение ошибок в рантайме

При вызове Iron.unseal() ошибка всегда возвращается в синхронной форме как исключение.

Типичный порядок обработки:

  • проверка формата строки
  • проверка HMAC
  • расшифровка payload
  • проверка TTL
  • возврат результата или выброс исключения

Любой сбой на любом этапе приводит к прерыванию цепочки обработки.


Связь ошибок с криптографической моделью

Ошибки Iron напрямую отражают этапы симметричного шифрования:

  • целостность → HMAC
  • конфиденциальность → AES-шифрование
  • валидность времени → timestamp + TTL

Таким образом, каждая ошибка соответствует конкретному уровню криптографической защиты, а не абстрактному программному сбою.