OneTimeSecret и PrivateNote: почему важно, где происходит шифрование

Два способа построить одну и ту же ссылку

При шифровании на стороне сервера отправитель передаёт секрет сервису по TLS. Сервис получает открытый текст, шифрует его и хранит шифротекст. Затем он может хранить данные, доставлять их, ограничивать срок и удалять. Сервер приложения входит в процесс шифрования, потому что открытый текст попадает в сервис до того, как становится шифротекстом.

При шифровании на стороне клиента устройство отправителя шифрует первым. Сервис получает и хранит шифротекст. Эта загрузка идёт по TLS. Сервис не получает ключ, нужный для расшифровки обычных данных. Устройство получателя расшифровывает локально. Сервис по-прежнему может хранить, доставлять, ограничивать срок и удалять данные, не имея доступа к их открытому тексту.

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

OneTimeSecret: шифрование на стороне сервера

В обычном порядке OneTimeSecret отправитель передаёт секрет по TLS. Приложение получает открытый текст, шифрует его на сервере и хранит зашифрованные данные.

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

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

Вредоносный или скомпрометированный процесс приложения в этот момент мог бы получить доступ к секрету до шифрования для хранения. Шифрование на стороне клиента убирает именно эту зависимость: секрет шифруется до того, как доходит до сервиса.

Парольная фраза OneTimeSecret не меняет границу шифрования

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

Получение использует ту же серверную границу. Получатель передаёт парольную фразу в OneTimeSecret по TLS. Сервис проверяет её и выполняет расшифровку на сервере, прежде чем вернуть открытый текст.

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

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

Свой сервер может сделать такое доверие разумным

OneTimeSecret — открытый исходный код. Организация может запустить собственный экземпляр внутри корпоративного периметра безопасности, а не отправлять секреты публичному сервису.

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

PrivateNote шифрует до загрузки

Обычная заметка PrivateNote шифруется до загрузки. Браузер отправителя или локальный процесс CLI, расширения Chrome, расширения редактора или MCP создаёт случайный ключ и шифрует данные с помощью AES-256-GCM. Загружается только шифротекст. TLS переносит этот шифротекст из браузера в Cloudflare worker PrivateNote. Ключ расшифровки помещается во фрагмент URL, часть после #, например https://privatenote.ai/note/abc123#…. Фрагмент обрабатывается на стороне клиента и не входит в запрос HTTPS (RFC 3986, §3.5; стандарт URL). Worker получает идентификатор заметки и возвращает шифротекст по тому же соединению TLS. Браузер сохраняет фрагмент и расшифровывает локально.

Парольная фраза защищает ключ, если канал ссылки скомпрометирован

Парольная фраза в PrivateNote делает другую работу, чем парольная фраза в OneTimeSecret. Заметка уже является шифротекстом до того, как покидает устройство. Если вы добавляете парольную фразу, браузер выводит из неё оборачивающий ключ с помощью Argon2id и этим ключом шифрует ключ заметки. Во фрагменте URL тогда лежит обёрнутый ключ. Получателю нужны ссылка и парольная фраза. Браузер разворачивает ключ локально и только затем расшифровывает заметку.

PrivateNote не получает парольную фразу. Запрос создания несёт шифротекст, соль и параметры, которые нужны браузеру получателя, чтобы попробовать парольную фразу локально. Нет серверного хеша, задача которого — проверить парольную фразу. Неверная парольная фраза приводит к ошибке расшифровки на устройстве.

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

Обработка ключей PrivateNote описана на странице Как это работает: ключ содержимого оборачивается с помощью Argon2id, и обёрнутый ключ путешествует в ссылке.

Оставшееся допущение доверия к веб-клиенту

Шифрование на стороне клиента в браузере — это не веб-приложение без доверия. Криптография может выполняться локально, пока JavaScript, который её реализует, доставляет сайт. Браузер доверяет коду, который получает на эту сессию.

Тот, кто может изменить этот JavaScript — через приложение, CDN или конвейер развёртывания, — может изменить клиент и перехватить ключи в будущей сессии браузера. Это другой сбой, чем кража базы данных. Компрометация хранилища раскрывает шифротекст. Вредоносная доставка кода атакует конечную точку, пока ключ действительно присутствует.

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

Установленное ПО сужает эту зависимость от только что скачанной страницы. CLI, расширение редактора или нативное приложение выполняют код, который вы установили. Эти клиенты всё ещё зависят от операционной системы, подписи, зависимостей и канала обновлений. Инструменты для разработчиков используют то же разделение, что и браузер: шифровать локально, загружать шифротекст, оставлять ключ во фрагменте.

Срок жизни и конфиденциальность

Одноразовая ссылка отвечает на два разных вопроса. Как долго должны существовать зашифрованные данные? И кто может их расшифровать, пока они существуют? Уничтожение после получения или по сроку сокращает окно. Оно не решает, кто мог прочитать данные в этом окне. Срок и конфиденциальность поддерживают друг друга. Одно не заменяет другое.

Различие острее всего, когда данные — это полномочие: ключи API, учётные данные базы, облачные токены, коды восстановления, пароли инфраструктуры. Сервис передачи секретов существует, потому что отправитель хочет доверить эти сведения меньшему числу систем. Если посреднику нужно лишь перенести непрозрачный зашифрованный объект, применить срок и удалить его, сервер может сделать эту работу, не получая секрет и ключ, который его открывает.

Где проходит граница

Слово «зашифровано» не говорит, где проходит граница доверия. Стандарт, которым стоит пользоваться, — минимальная граница доверия: принцип наименьших привилегий в отношении того, кто обязан видеть открытый текст. В современной криптографической инженерии цель не только в том, чтобы доверять поведению сервера, но и в том, чтобы уменьшить саму математическую необходимость такого доверия.

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

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

OneTimeSecret шифрует ваш секрет. Клиент, который пользуется сервисом PrivateNote, шифрует его до того, как сервис его получает. Это различие не зависит от предположения, что кто-то из провайдеров злонамерен. Оно сводит вопрос к архитектуре: скольким системам нужен доступ к открытому тексту, чтобы сервис работал?

Частые вопросы

Первоисточники

Сведения об архитектуре OneTimeSecret сверены с его публичной документацией 23 сентября 2026 года. Реализация продуктов и документация могут измениться.

• Документация OneTimeSecret
• OneTimeSecret о безопасности и парольных фразах
• Исходный код OneTimeSecret
• Как работает шифрование PrivateNote
• PrivateNote для разработчиков, включая CLI
• RFC 3986, раздел 3.5, который отделяет фрагмент от URI до разыменования
• Стандарт URL, фрагмент, об обработке фрагмента на стороне клиента