Шифрование чанков
Cotton шифрует хранимые данные через потоковый AES-GCM конвейер: обёрнутые ключи на файл, теги аутентификации на чанк, структурированные nonce и аутентифицированные метаданные контейнера. Фокус не в экзотической крипте, а в консервативном формате хранения, который можно держать включённым всегда.
- Шифрование идёт в обычном пути хранения.
- Теги аутентификации помогают ловить подмену, пропуски блоков, дубликаты блоков и порчу.
- Серверный master key защищает зашифрованные данные хранилища и артефакты бэкапов.
Скучная крипта — это фича
AES-GCM — широко применяемый режим аутентифицированного шифрования. Cotton использует стандартную криптографию рантайма, а не изобретает свой шифр. Вся специфичная работа вокруг: обёртывание ключей, заголовки файлов и чанков, раскладка nonce, ограниченные буферы и тесты, которые фиксируют поведение контейнера.
- 32-байтные ключи и 16-байтные теги аутентификации соответствуют дизайну хранилища.
- 12-байтные nonce собираются из префикса файла и счётчика чанков.
- Золотые векторы и тесты на подмену не дают формату случайно поплыть.
Клиентски зашифрованные папки
Cotton поддерживает выбранные E2E-папки и файлы. Когда политика включена, новые загрузки шифруются в браузере на ключе хранилища до отправки на сервер; зашифрованные отображаемые метаданные позволяют вернуть имена и типы контента после разблокировки.
- Пароль шифрования отделён от пароля аккаунта и не отправляется на сервер.
- Зашифрованные файлы используют непрозрачные серверные имена и клиентские отображаемые метаданные.
- Текущий браузерный конвейер на Blob ограничен 512 MB на файл, пока его не заменит клиентское потоковое шифрование.
Граница доступа админа
Шифрование на уровне хранилища защищает каждый сохранённый чанк, а клиентски зашифрованные папки поднимают границу приватности для выбранного контента. Публичная формулировка остаётся честной: E2E относится к этим клиентски зашифрованным файлам, а не ко всем байтам всех фич магическим образом.
- Сохранённые чанки зашифрованы и контентно-адресуемы.
- Видимое дерево папок живёт в метаданных, а не в обычных пользовательских каталогах.
- Админская диагностика показывает риски развёртывания вместо того, чтобы прятать их.
Модель угроз: от чего защищает каждый слой
Cotton разделяет четыре разных риска: кражу диска или бэкапа, захват учётной записи, подмену защищённых метаданных БД и компрометацию работающего сервера. AES-GCM защищает сохранённые чанки, passkeys, TOTP и отзыв сессий уменьшают риск захвата аккаунта, подписи БД обнаруживают подмену защищённых строк, а клиентское E2E поднимает границу доверия для выбранных папок.
- Копия диска или бэкапа без master key не раскрывает содержимое зашифрованных чанков.
- Украденную активную сессию можно увидеть и отозвать, не завершая остальные сессии пользователя.
- Изменённая защищённая строка БД не принимается молча, если её подпись целостности больше не совпадает.
Где заканчивается граница доверия
Шифрование хранилища не скрывает обычные файлы от работающего приложения, которое уже разблокировано и обслуживает законный запрос пользователя. Администратор или атакующий, контролирующий процесс вместе с master key и базой данных, находится внутри серверной границы доверия. Только выбранные E2E-папки не отдают серверу открытое содержимое; после разблокировки скомпрометированный браузер или устройство пользователя всё равно остаётся риском.
- AES-GCM на сервере защищает данные в покое, но не заменяет клиентское E2E.
- E2E относится только к папкам и файлам, где эта политика явно включена.
- TLS, обновления, защита хоста, хранение master key, бэкапы и проверка восстановления остаются ответственностью оператора.
Безопасность аккаунта
Пользователи могут входить по паролю, TOTP, платформенным passkeys или внешним WebAuthn-ключам безопасности. Настройки профиля показывают активные сессии, чтобы подозрительное устройство можно было отозвать без выброса всех остальных.
- Passkeys и аппаратные ключи безопасности — полноценные учётные данные аккаунта.
- Настройка TOTP и сценарии восстановления находятся в безопасности профиля.
- Неудачные входы и события безопасности могут становиться уведомлениями.
Целостность базы данных
Защищённые строки БД несут подписи целостности, выведенные из материала master key. Чувствительные к безопасности чтения могут проверить подпись и поднять ошибку, а не слепо доверять изменённым метаданным.
- Пользователи, учётные данные, токены, настройки, узлы, манифесты и чанки покрываются дескрипторами целостности.
- Мостовой режим раскатки может подписывать старые строки и предупреждать админов, что раскатка ещё не завершена.
Админская проверка безопасности
Страница админской безопасности оценивает конкретные риски развёртывания: публичное создание аккаунтов, источник master key, покрытие админов 2FA, диагностику .NET, дампируемость Linux, seccomp, capability ptrace, записываемую корневую файловую систему, доступность Docker socket, сигналы host PID namespace, дампы памяти и изоляцию.
Нагрузка на хранилище и квоты
Хранилище на файловой системе проверяет свободное место перед новой физической записью чанков. Публичные/демо-инстансы могут применять квоты пользователей по умолчанию, чтобы онбординговый контент не превращался в неконтролируемую яму для диска.
Честная позиция по крипте
Модули шифрования покрыты тестами на золотые векторы, подмену, усечение, стабильность, pipe, отмену и производительность, но сайт не заявляет сторонний аудит, которого не было. Лучше честно назвать границы, чем надувать доверие. Правильное публичное заявление: потоковый AES-GCM по учебнику для слоя хранилища плюс клиентское шифрование для папок/файлов, где политика E2E явно включена.
Демо-аккаунты
Публичное демо не держится на одном общем аккаунте. Ссылка для входа генерирует учётные данные под браузер и может засеять контент по умолчанию в новый аккаунт тем же продуктовым механизмом, что используется для онбординга.
Текущие ограничения
Называем сразу. Клиентское E2E сейчас идёт через браузерный Blob-конвейер с лимитом 512 MB на файл, пока не появится потоковый конвейер. Опубликованные бенчмарки — это машинные базовые замеры, а не математика живой загрузки end-to-end; реальная пропускная способность зависит ещё от браузера, HTTP/TLS, базы, диска и параллелизма. А шифрование хранилища — это AES-GCM «по учебнику», но без стороннего аудита.
Поверхности безопасности, которые видно
История безопасности Cotton видна в механике продукта: серверное шифрование чанков, выбранные клиентски зашифрованные папки, passkeys, TOTP, отзыв сессий, подписи базы данных, квоты, проверки нагрузки на хранилище и админская диагностика имеют пользовательскую или операторскую поверхность.
- Сохранённые чанки используют потоковый AES-GCM в обычном пути.
- Клиентски зашифрованные папки не пускают секрет хранилища в серверный поток входа.
- Защищённые строки базы данных можно сверять с подписями целостности.
Безопасность в продуктовой тропе
Cotton говорит прямо: это безопасность внутри файлового облака, а не галочка, прикрученная к UI общих папок. Продукт показывает рискованные состояния, чтобы оператор мог починить их до инцидента.
Что не надо обещать
Cotton не продаётся как универсально end-to-end зашифрованный. Точная формулировка: потоковый AES-GCM на слое хранилища по умолчанию плюс клиентское шифрование для папок и файлов, где такая политика явно включена.