01 · Модель
Три режима — три разные границы доверия
HTTPS защищает сетевое соединение, но после завершения передачи сам по себе ничего не говорит о формате объекта в хранилище. Серверное шифрование S3 защищает носители провайдера, однако расшифрование выполняется инфраструктурой хранилища. Клиентское шифрование меняет границу: объект преобразуется на телефоне, и в S3 отправляется шифротекст.
02 · Контейнер
Структура CRUENC01
Контейнер начинается с фиксированного 48‑байтного заголовка. Далее идут записи зашифрованных чанков. Для каждого чанка сохраняется полный 16‑байтный тег GCM; тег позволяет не только расшифровать данные, но и проверить, что шифротекст и связанные с ним параметры не были изменены.
Размер контейнера: 48 байт + размер исходного файла + 16 байт × количество чанков.
03 · Ключевой материал
Один объект — один случайный ключ
Для каждого оригинала и каждой миниатюры создаётся независимый 32‑байтный DEK (Data Encryption Key). DEK не записывается в контейнер: он оборачивается версионным мастер‑ключом аккаунта и хранится отдельно. Компрометация одного ключа объекта не должна автоматически раскрывать остальные объекты.
Ключ, которым шифруется ровно один объект: оригинал либо миниатюра.
64‑битный случайный префикс контейнера и 32‑битный номер чанка. Пара «ключ + nonce» не должна повторяться.
Зашифрованное представление ключа объекта. Оно существует вне CRUENC01 и связано с версией мастер‑ключа.
Если устройство гипотетически проверяет 1018 ключей каждую секунду, среднее ожидание составляет около 1,8 × 1051 лет — примерно 1,3 × 1041 текущих возрастов Вселенной.
Почему повтор nonce критичен: GCM требует уникальный nonce для каждого сообщения под одним ключом. Повтор может разрушить конфиденциальность и достоверность данных, поэтому после неудачного повторного шифрования пара DEK/nonce не используется заново.
04 · Аутентификация
Подмена не должна выглядеть как успешное восстановление
AES‑GCM аутентифицирует не только содержимое чанка. В AAD (данные, которые не шифруются, но входят в проверку) включены 48‑байтный заголовок, номер чанка, длина его открытого содержимого и признак последнего блока.
Reader работает строго: неизвестная версия, неизвестный алгоритм, неверные размеры, лишние флаги или ошибка тега завершают восстановление ошибкой. Режима «попробовать вернуть хоть что‑нибудь» для непроверенного открытого текста нет.
05 · Большие файлы
Почему файл делится на чанки
Чанкирование не ослабляет алгоритм: каждый блок получает собственные nonce и tag. Оно позволяет обрабатывать большие видео без загрузки всего объекта в оперативную память, повторять локальные этапы и в дальнейшем читать нужные диапазоны.
При диапазонном чтении приложение запрашивает полные криптографические записи, проверяет соответствующие GCM‑теги и только затем отдаёт нужный фрагмент. Непроверенные байты не должны попадать в декодер изображения или видео.
06 · Границы
Что эта схема не обещает
Надёжная криптография не превращает приложение в магически неуязвимую систему. Она не защищает открытый файл на уже разблокированном заражённом телефоне, не исправляет слабый пароль и не отменяет необходимость защищать механизм восстановления ключей.
RusClouder не называет текущую архитектуру «zero knowledge»: восстановление архива на новом устройстве поддерживается через защищённый серверный контур. Это осознанный компромисс между восстановлением после потери телефона и моделью, где утраченный пользовательский секрет невозможно заменить.
07 · Основание
Стандарты и реализация
AES определён стандартом NIST FIPS 197, а режим GCM — NIST SP 800‑38D. В приложении используется поддерживаемая криптографическая библиотека с нативным ускорением; собственный код реализует формат контейнера, построение AAD, nonce и сопоставление диапазонов, но не сам алгоритм AES.