Как работает cryptEE и почему он устроен именно так

1. Базовый E2EE-поток

1. Файл шифруется в браузере алгоритмом `AES-256-GCM`.
2. Ключ шифрования генерируется локально и не отправляется на сервер.
3. В ссылку попадает только `id`, а ключ передаётся через URL fragment (`#k=...`), который не уходит в HTTP-запросы.
4. Сервер хранит только шифртекст и технические метаданные, нужные для выдачи и политик доступа.

2. Что делает сервис отличающимся

Мы добавили три функции, которые переводят продукт из категории «обычный файлообменник» в категорию «управляемая защищённая передача данных».

• M-of-N unlock: файл откроется только после заданного числа подтверждений.
• Ratcheting links: после успешного скачивания ссылка ротируется на новый `id`.
• Verifiable deletion log: удаление фиксируется в подписанном журнале с hash-chain.

3. M-of-N unlock (многостороннее раскрытие)

При загрузке можно задать политику, например `2 из 3`. Сервис сгенерирует токены подтверждения для участников. Пока порог не достигнут, скачивание заблокировано.

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

4. Ratcheting links (ротация ссылок)

Если включён ratchet-режим, после каждого успешного скачивания сервер выдаёт новый идентификатор ссылки и деактивирует старый.

Практический эффект: утёкшая старая ссылка быстро становится бесполезной. Получатель работает только с «текущим поколением» ссылки.

5. Verifiable deletion log (проверяемый лог удаления)

Любое важное событие удаления (ручное удаление, истечение TTL, исчерпание лимита, ротация ratchet) записывается в журнал.

Каждая запись:

• имеет hash (`eventHash`) от канонизированного payload,
• ссылается на предыдущий hash (`prevHash`), формируя цепочку,
• подписывается ключом `Ed25519`.

Это даёт возможность внешней проверки: событие не подменено, порядок событий не нарушен.

6. Что сервер знает и чего не знает

• Сервер знает: `id`, политики (TTL, лимиты), технические метаданные, шифртекст.
• Сервер не знает: ключ расшифровки (в обычном режиме), содержимое файла в открытом виде.

7. Почему это важно для практики

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

Идея в том, что безопасность здесь не «галочка», а часть бизнес-логики: кто, когда и на каких условиях получает доступ.

8. Ограничения и честные границы модели

• Если устройство пользователя скомпрометировано, E2EE не защищает от локальной кражи.
• Слабые пароли в password-режиме уязвимы для перебора.
• Метаданные (время, размеры, факт обращения) частично видимы серверу для работы политик.