IPFS: шифрование до добавления
Если материалы должны быть закрыты до выдачи права, шифрование выполняется до распространения. IPFS затем хранит зашифрованные байты как обычное содержимое. В уроке определим контейнер, параметры и границу выдачи ключа, не предлагая собственную криптографическую схему для реальных данных.
Мы не генерируем ключ, не шифруем файл и не загружаем контейнер. Приведённые операции являются моделью и исходниками для будущего самостоятельного этапа. Для окончательного проекта потребуется закреплённый формат и совместимый инструмент.
Порядок операций
Сначала готовятся точные открытые байты выпуска или отдельного файла. Затем выбранная проверенная схема создаёт зашифрованный контейнер с необходимыми параметрами. Только этот контейнер добавляется в content-addressed-хранилище. Получатель сначала получает и проверяет контейнер, затем расшифровывает по разрешённому маршруту.
открытые байты → шифрование → контейнер → CID
↓
получатель + разрешённый ключ → расшифрованный файлCID относится к зашифрованному объекту. Он не равен отпечатку открытого текста и не даёт ключ расшифрования. При новом безопасном случайном параметре один и тот же текст может получить другой контейнер и другой CID.
Аутентифицированное шифрование
Для современного прикладного контейнера обычно рассматривают схему, которая также обнаруживает нарушение целостности зашифрованных данных и связанного контекста. AES-GCM в Web Crypto — один из поддерживаемых механизмов, но его применение требует соблюдения правил ключа и nonce.
Особенно важно не повторять nonce с тем же ключом в недопустимом режиме. Стремление получить одинаковый CID для одинакового секретного текста не оправдывает такого повтора. Воспроизводимость открытого выпуска и безопасное шифрование имеют разные требования.
Формат должен хранить алгоритм, версию, необходимые открытые параметры и способ интерпретации. Сам секрет в публичный контейнер не включается. Нельзя использовать пароль пользователя непосредственно как AES-ключ без определённой процедуры получения ключевого материала и оценки выбранной схемы.
Связанный контекст
Контейнер полезно привязать к назначению, например к идентификатору схемы и выпуска, через предусмотренный механизм authenticated data или иной согласованный формат. Это помогает отличить байты одного назначения от другого. Точная конструкция должна быть документирована и поддержана обеими сторонами.
Но аутентифицированный контекст не устанавливает автора самостоятельно. Если атакующий способен создать свой контейнер и свой ключ, внутренняя проверка будет успешной для его пары. Доверенное объявление и право выдачи по-прежнему нужны.
Библиотечный CourseCatalog может объявлять отпечаток публичного манифеста, который описывает зашифрованный объект без личных данных. Если манифест содержит секреты, его также нужно защищать отдельно. Одна универсальная схема для всех полей не возникает автоматически.
Выдача ключа
Сервер определяет право читателя по собственному счёту и сессии. Затем предоставляет ключ или защищённый способ его получения по выбранному протоколу. Он не публикует ключ в контракте, открытом HTML или общем URL рядом с CID.
Если все читатели получают один ключ, каждый из них способен передать его дальше. Это может быть допустимо для определённой модели продукта, но не обеспечивает индивидуального отзыва уже выданного секрета. Для разных пользователей возможны отдельные обёртки ключа, однако после расшифрования они всё равно способны копировать открытый текст.
Подключение кошелька или владение токеном может быть одним основанием права. Оно не превращает публичный контент в скрытый. Проверка владения относится к выдаче, а криптография — к чтению контейнера. Эти этапы нужно показать пользователю отдельно.
Память и размер
Небольшой манифест удобно обработать целиком, но большой архив может требовать потоковый формат с отдельными требованиями аутентификации частей и завершения. Нельзя наивно разбить файл на куски и повторить один nonce, называя это безопасным streaming AES-GCM.
В первом учебном проекте ограничим размер контейнера и выберем поддерживаемую библиотеку вместо собственного протокола. В досье записываются лимит, формат и ожидаемый способ отказа при повреждении. Публичный CID не снимает ограничений памяти браузера.
После расшифрования проверяется ожидаемый формат файла и допустимость отображения. Защищённый контейнер может содержать активный вредоносный HTML, если издатель ошибся или ключевой канал подменён. Политика исполнения сохраняется даже после успешного криптографического шага.
Отзыв и новая редакция
При компрометации ключа можно подготовить новый контейнер и ограничить будущую выдачу. Старый контейнер остаётся читаемым теми, кто располагает старым ключом. Нельзя обещать, что смена ключа удаляет скачанные открытые файлы.
Поэтому бизнес-правило выражается точно: сервер может перестать выдавать новый доступ и обновлённые ключи. Физическое копирование уже известного содержания находится за его границей. Читатель должен понимать эту модель до оплаты, а редакция — до выбора архитектуры.
Новая редакция и повтор параметров
Допустим, библиотека исправляет урок и готовит второй зашифрованный контейнер. Удобство хранения не оправдывает повтор nonce с тем же ключом там, где схема запрещает такой повтор. Контейнер может получить другие байты и CID даже при одинаковом открытом тексте; это нормальное следствие безопасной подготовки, а не неисправность адресации. Требование неизменного публичного выпуска нельзя механически переносить на детерминированное шифрование секретных материалов.
Версия формата определяет, какие параметры открыты, как они кодируются и какой контекст аутентифицируется. Если контекст включает идентичность курса и редакции, получатель использует именно предусмотренные байты этого контекста. Их случайное пересоздание из другой строки или другой сериализации может привести к отказу. Поэтому формат контейнера и способ объявления должны быть согласованы так же точно, как ранее формат публичного манифеста. Здесь мы не создаём собственную реализацию AES-GCM и не объявляем её криптографически проверенной.
При получении повреждённого контейнера аутентификация должна завершиться отказом; частичный текст не объявляется доверенным учебным материалом. Если выбранный потоковый инструмент разрешает выдавать части до окончательной проверки, его гарантия требует отдельного анализа. Нельзя незаметно превращать условно обработанные части в успешно расшифрованный полный архив. Для первого проекта проще выбрать ограниченный по размеру поддерживаемый формат с ясным завершением.
Смена ключа защищает последующую выдачу по новой политике, но не делает старый контейнер нечитаемым для владельца старого ключа. Новые индивидуальные обёртки ключа также не отменяют уже известный открытый текст. В досье библиотеки записываем предмет ротации, новую редакцию, способ выдачи и границу отзыва. Это позволяет объяснить практический эффект смены ключа без обещания удалённо забрать материалы у читателя.
Подготовленный результат
В досье готовы алгоритмическая роль, форматные требования, источник ключа и критерии повреждения. Фактическая совместимость и криптографическое исполнение пока отсутствуют. Мы не выдаём ожидаемый отказ неверного ключа за полученный эксперимент.
Поддерживаемые операции описаны в Web Crypto encrypt, а публичность IPFS — в Privacy and encryption. После урока шифрование является отдельным слоем до адресации, а доступ к ключу — самостоятельным серверным договором библиотеки.