CottonEnd-to-end шифрование
End-to-end шифрование

Выбранные папки, которые сервер не читает.

Каждый чанк на диске уже зашифрован в покое. End-to-end идёт дальше: включаете политику для папки, и браузер шифрует до загрузки, так что даже админ сервера видит шифртекст и непрозрачные имена.

Клиентское шифрованиеЗашифрованные папкиБраузерное хранилищеЗашифрованные метаданные

Политика папки

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

  • Флаг политики живёт в метаданных узла.
  • Загрузки блокируются с понятной ошибкой заблокированного хранилища, когда требуется шифрование.
  • Существующие незашифрованные файлы можно зашифровать позже из действий папки.

Хранилище и восстановление

Клиентское шифрование разблокируется через пароль шифрования или фразу восстановления из 24 слов. Пароль отделён от пароля аккаунта и не отправляется на сервер, поэтому сервер не сможет сбросить доступ к зашифрованным файлам, если оба пути восстановления потеряны.

Непрозрачная серверная полезная нагрузка

Зашифрованные загрузки используют блоб контейнера Cotton со сгенерированным непрозрачным серверным именем файла. Видимое имя файла и тип контента хранятся как зашифрованные отображаемые метаданные, чтобы UI восстановил настоящее имя после разблокировки без обычных серверных метаданных.

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

Текущий лимит размера

Текущий браузерный путь E2E основан на Blob и ограничен 512 MB на зашифрованный файл. Лимит намеренно видимый: он не даёт вкладке браузера превратить клиентское шифрование в проблему с памятью до замены на потоковый конвейер.

Как это наслаивается на шифрование хранилища

После того как браузер зашифровал E2E-файл, Cotton всё равно хранит этот шифртекст через обычный контентно-адресуемый, сжатый, зашифрованный конвейер хранения. Два слоя решают разные задачи: E2E скрывает выбранный контент от серверной обработки открытого текста, шифрование хранилища защищает сохранённые чанки и артефакты бэкапов.

Что остаётся честным

E2E надо подавать как выбранные клиентски зашифрованные папки/файлы, а не общее заявление, будто каждая фича зашифрована только в браузере. Шары, превью, поведение поиска и видимость метаданных нужно документировать фича за фичей по мере расширения поверхности E2E.

Пруф клиентского шифрования

Поверхность E2E имеет реальные движущиеся части: метаданные политики папки, разблокировку браузерного хранилища, зашифрованные отображаемые метаданные, непрозрачные серверные имена файлов, браузерную расшифровку при скачивании и видимый лимит 512 MB для текущего пути на Blob.

Полезный E2E без театра

Cotton даёт пользователям сфокусированное место для файлов, которые должны быть зашифрованы ещё до того, как сервер вообще коснётся открытого текста, и не притворяется, что каждая продуктовая фича уже имеет ту же семантику E2E.

Где граница сегодня

Клиентское шифрование сейчас подходит для выбранных папок и ограниченных размеров файлов. Потерянные учётные данные хранилища могут сделать зашифрованный контент невосстановимым, а превью, шары и поиск требуют явного поведения E2E, а не расплывчатых обещаний.

Вопросы

Прямые ответы

Сервер знает настоящее имя файла для E2E-файлов?

Путь загрузки хранит непрозрачное сгенерированное серверное имя и зашифрованные отображаемые метаданные для видимого имени/типа контента. Клиент показывает настоящие значения после разблокировки хранилища.

Почему лимит 512 MB?

Текущая браузерная реализация E2E использует конвейер шифрования/расшифровки на Blob. Лимит защищает от нагрузки на память браузера до клиентского потокового шифрования.

Сервер восстановит E2E-файл, если я потеряю ключ хранилища?

Не стоит на это рассчитывать. Клиентское шифрование полезно именно потому, что сервер не держит путь к открытому тексту; потеря материала хранилища может сделать зашифрованный контент невосстановимым.