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 у PrivateNote. Ключ розшифрування розміщується у фрагменті URL, частині після #, наприклад https://privatenote.ai/note/abc123#…. Фрагмент обробляється на боці клієнта і не входить до запиту HTTPS (RFC 3986, §3.5; стандарт URL). Воркер отримує ідентифікатор нотатки і повертає шифротекст тим самим з’єднанням 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, фрагмент, про обробку фрагмента на боці клієнта