Производительность

Результаты бенчмарков с cargo bench (Criterion, 10 выборок на измерение). Вывод ключа исключён — числа отражают только чистую криптографическую пропускную способность.

Оборудование:

• ЦП: AMD Ryzen 5 5600X (6c/12t @ 3.7 ГГц базовая)
• ОЗУ: 2x 8 ГиБ DDR4-2666 (двухканальный, 16 ГиБ всего)
• ОС: Linux

Примечание о вводе-выводе: Criterion записывает временные файлы в /tmp, который в этой системе является tmpfs (на базе ОЗУ). При использовании O_DIRECT ядро не может выполнять настоящий асинхронный DMA на tmpfs, поэтому эти числа отражают пропускную способность шифрования + накладные расходы io_uring без преимущества DMA bypass. На реальном Gen4 NVMe-диске O_DIRECT устраняет двойную буферизацию кэша страниц и включает прямой DMA в выровненные пулы буферов, что должно дать значительно более высокую пропускную способность.

Развёртка размера чанка (AES-256-GCM, файл 64 МиБ):

Характеристики производительности

Движок использует ring (оптимизированные на ассемблере AES-NI / NEON / ARMv8-CE) для криптографических операций и трёхбуферный конвейер io_uring для ввода-вывода. Три предварительно выделенных пула буферов циклически проходят через конвейер: пока завершаются записи пула A в ядре, пул B шифруется Rayon на ЦП, а операции чтения пула C отправляются в ядро. Это перекрывает задержку ввода-вывода с криптографическими вычислениями.

Почему AES-256-GCM быстрее ChaCha20-Poly1305 на маленьких файлах: Бэкенд AES-GCM в ring использует аппаратные инструкции AES-NI + CLMUL, доступные на x86-64, что даёт аппаратное преимущество перед ChaCha20 (который является программным шифром). При больших размерах оба шифра сходятся к ~1.0 ГиБ/с, что указывает на то, что узкое место смещается с пропускной способности шифрования на накладные расходы отправки ввода-вывода.

Почему пиковая пропускная способность приходится на 1–16 МиБ, а не на 256 МиБ: Маленькие файлы (1–16 МиБ) имеют мало чанков, поэтому параллелизм Rayon эффективен, и рабочий набор помещается в кэш. При 64–256 МиБ конвейер io_uring полностью активен (в работе находятся три набора), но накладные расходы на отправку SQE и завершение CQE растут с количеством чанков. Конструкция с тройным буфером обеспечивает перекрытие ввода-вывода и криптографии, частично скрывая эту стоимость.

Почему ~1.0 ГиБ/с, а не 10+ ГиБ/с: Современный AES-NI может выдавать 2–4 ГиБ/с на ядро. С 12 потоками сырая пропускная способность шифрования могла бы превысить 10 ГиБ/с. Разрыв объясняют три фактора:

1. Накладные расходы на SQE io_uring: Каждый чанк требует один SQE на чтение и один SQE на запись. Для 256 чанков в файле размером 256 МиБ это 512 отправленных SQE и 512 обработанных CQE. Хотя io_uring избегает затрат на переключение контекста на системный вызов, характерных для pread/pwrite, он всё же имеет накладные расходы на кольцевой буфер и барьеры памяти для каждого SQE.
2. Глубина конвейера: При PIPELINE_DEPTH=3 в любой момент времени через конвейер проходят только три набора. Для настоящего установившегося перекрытия требуется как минимум три набора; файлы, умещающиеся в один или два набора, не получают выгоды от конвейеризации.
3. Влияние иерархии кэша: 5600X имеет 512 КиБ L2 на ядро и 32 МиБ общего L3. Чанк по умолчанию 4 МиБ превышает L2, а набор из ~21 чанка (активный рабочий набор 84 МиБ) значительно превышает L3. Чанки меньшего размера (64–256 КиБ) показывают лучшую пропускную способность в развёртке, потому что большая часть рабочего набора остаётся в кэше.

Жизненный цикл буфера и безопасность: Пулы буферов выделяются один раз через std::alloc::alloc_zeroed с Layout::from_size_align(size, 4096) до создания кольца io_uring и повторно используются во всех итерациях конвейера без перевыделения. Каждый зашифрованный чанк дополняется нулями для выравнивания на сектор перед записью O_DIRECT. Кольцо явно удаляется перед пулами буферов, что гарантирует, что ядро никогда не ссылается на освобождённую память (никаких UAF).

Установка

Бинарный файл будет находиться по пути target/release/concryptor.

Использование

Шифрование

Замечание по безопасности: --password / -p передаёт пароль как аргумент командной строки, который виден в выводе ps и истории оболочки. Для интерактивного использования опустите его, чтобы получить защищённый скрытый запрос. Для скриптов предпочтительно очищать историю после использования или использовать обёртку, читающую из файлового дескриптора.

Шифрование каталога

Шифрование каталога создаёт временный tar-архив (.concryptor-*.tar, права 0600, имя от CSPRNG), шифрует его, затем автоматически удаляет временный файл. Имена файлов, структура каталогов, права доступа и временные метки находятся внутри зашифрованного полезного груза.

Расшифровка

Расшифровка и извлечение каталога

Без --extract расшифровка архива каталога создаёт промежуточный .tar-файл, который можно изучить или извлечь вручную.

Справка

Формат файла

Все значения в little-endian. Заголовок занимает полный сектор 4 КиБ; каждый слот зашифрованного чанка дополняется до следующей границы 4 КиБ. Это гарантирует, что каждое смещение и размер ввода-вывода выровнены по секторам для O_DIRECT.

Для чанков по 4 МиБ: каждый дисковой слот занимает ceil((4194304 + 16) / 4096) * 4096 = 4198400 байт (4080 байт заполнения на чанк). 4032 зарезервированных байта в заголовке доступны для будущих функций (слоты асимметричных ключей, метаданные и т.д.).

Соль и базовый одноразовый номер генерируются заново из rand::rng() (использующего CSPRNG ОС) при каждом шифровании. Повторное использование пароля для разных файлов безопасно, потому что разные соли дают разные ключи Argon2id, а разные базовые одноразовые номера дают разные одноразовые номера для чанков.

Проектирование безопасности

• Вывод одноразового номера: chunk_nonce = base_nonce XOR chunk_index (стиль TLS 1.3). Перестановка чанков вызывает ошибку расшифровки, потому что одноразовый номер на позиции N не совпадает с одноразовым номером, использованным для шифрования чанка, изначально находившегося на позиции M. Примечание: основанный на XOR вывод одноразовых номеров имеет теоретическую уязвимость, когда один и тот же ключ используется в нескольких потоках (разные базовые одноразовые номера могут давать пересекающиеся пространства одноразовых номеров). Это не относится к Concryptor, потому что каждое шифрование генерирует новую 128-битную случайную соль, создавая уникальный ключ Argon2id для каждого файла. Уникальность одноразовых номеров важна только при одном и том же ключе, а вероятность повторного использования ключа составляет ~2^-128 для каждой пары файлов.
• Аутентифицированный AAD заголовка: Каждый вызов AEAD для чанка использует AAD = full_aligned_header (4096) || chunk_index (8 LE) || is_final (1) (всего 4105 байт). Весь 4-КиБ сектор заголовка (основные поля, параметры KDF и зарезервированное заполнение) привязывается к тегу аутентификации каждого чанка. Изменение любого байта заголовка (тип шифра, размер чанка, исходный размер, соль, одноразовый номер, параметры KDF или зарезервированное заполнение) делает все чанки недействительными. Это предотвращает атаки усечения, когда злоумышленник изменяет original_size и удаляет последние чанки, а также предотвращает скрытую запись данных в область зарезервированного заполнения. Устаревшие файлы v3 расшифровываются с AAD длиной 52 байта для обратной совместимости; понижение версии с v4 до v3 невозможно, потому что сам байт версии находится внутри аутентифицированного AAD.
• Индикатор финального чанка в стиле STREAM: Последний байт AAD равен 0x01 для финального чанка и 0x00 для всех остальных. Это предотвращает две атаки:
  • Усечение: Удаление финального чанка и продвижение нефинального чанка на конец не удаётся, потому что нефинальный чанк был зашифрован с is_final = 0x00, а расшифровка ожидает 0x01.
  • Расширение: Добавление поддельных чанков не удаётся, потому что злоумышленник не может создать корректный тег для is_final = 0x01 без ключа.
• Свежая случайность для каждого файла: 16-байтовая соль и 12-байтовый базовый одноразовый номер берутся из CSPRNG ОС (rand::rng()) для каждого шифрования. Два шифрования одного и того же файла с одним и тем же паролем дают полностью разные шифротексты. Повторное использование одноразового номера (катастрофическое для AES-GCM) исключено конструкцией.
• Вывод ключа: Argon2id с настраиваемой стоимостью памяти (по умолчанию 256 МиБ, настраивается через --memory), 3 временные итерации, параллелизм 4. Значение по умолчанию 256 МиБ в 4 раза превышает минимальный стандарт OWASP и является дорогим для атакующих с GPU/FPGA/ASIC. Параметры KDF хранятся в заголовке файла (байты 52–63), что делает файлы самодокументируемыми — расшифровка всегда использует корректные параметры независимо от текущих значений по умолчанию. Если байты 52–63 все нулевые (устаревшие файлы до параметров KDF), применяются старые значения по умолчанию 64 МиБ / 3 / 4.
• Обнуление: Ключи шифрования обнуляются сразу после создания шифра. Пароли обнуляются после использования.

Тестирование

Набор тестов покрывает:

• Проверка сериализации/десериализации заголовка
• Детерминированность и чувствительность вывода ключа
• Уникальность одноразовых номеров и свойства идентичности
• Шифрование/расшифровка для обоих шифров на файлах разных размеров (пустой, 1 байт, граничные случаи, несколько чанков)
• Отклонение неверного пароля
• Обнаружение подделки (перевёрнутый шифротекст, повреждённые теги, повреждённая соль, усечённые файлы)
• Обнаружение атаки переупорядочивания чанков
• Обнаружение несоответствия типа шифра
• Обнаружение атаки усечения (изменённый original_size + удалённые чанки)
• Обнаружение манипуляции полями заголовка (изменённый chunk_size)
• Обнаружение подделки зарезервированных байтов заголовка (изменённая область заполнения)
• Проверка недетерминированного шифрования
• Стресс-тест с 256 маленькими чанками
• Циклы упаковки/распаковки архива каталога (оба шифра)
• Циклы для пустого каталога, глубоко вложенного каталога, множества файлов и бинарного содержимого
• Сохранение символических ссылок для корректных внутренних ссылок
• Отклонение символических ссылок, выходящих за корень извлечения (абсолютные и относительные обходы)
• Автоматическая очистка временного файла при Drop
• Отклонение неверного пароля для зашифрованных архивов

Зависимости

Установка

Лицензия

Этот проект лицензирован под GNU Affero General Public License v3.0.