Клиент-стороннее · Распространение PDF

Клиент-сторонее зашифрованное распространение PDF, объяснённое корректно.

Q: URL-фрагмент действительно безопасен как носитель ключа шифрования?

Совместимые браузеры никогда не передают часть URL после # на сервер. Она остаётся на стороне клиента. Именно это делает саму ссылку учётной записью для расшифровки — ключ путешествует с получателем, а не с загрузкой.

Термин «сквозное шифрование» используют расплывчато. Здесь — реальный криптографический механизм за клиент-сторонней зашифрованной ссылкой PDF: AES-256-GCM, обработка ключа, режимы фрагмента и парольной фразы и что сервер буквально не может. Замечание: «Zero-Knowledge» на этой странице означает, что у сервера нет информации, которая позволила бы расшифровать ваш файл, — а не формальные доказательства с нулевым разглашением (ZKP); продукт ZKP не использует.

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310 000 linkФрагмент или парольная фраза memoryWeb Crypto API

sendОтправить зашифрованную ссылку Как это работает

Что здесь означает «Zero-Knowledge»

Сразу проясним: эта система не использует доказательства с нулевым разглашением (ZKP). На этой странице «Zero-Knowledge» означает более слабое, но практически полезное свойство: у сервера, хранящего ваш файл, нет ни криптографического, ни операционного знания, которое позволило бы расшифровать файл. Ключ никогда не попадает на сервер — а значит, сервер не сможет его раскрыть ни при каких обстоятельствах. Механизм — это обычное клиент-сторонее шифрование плюс ключ, который путешествует только в URL-фрагменте (или выводится из парольной фразы, которую сервер не видит).

memory

Шифрование происходит в вашем браузере

Не на сервере, не в воркере, который вы не контролируете — у вас во вкладке, через window.crypto.subtle. Это можно проверить в DevTools.

cloud_off

Загружается только шифротекст

Тело загрузки — это шифротекст AES-256-GCM. Сам PDF, имя файла и метаданные никогда не доходят до сервера в читаемом виде.

vpn_key

Ключ через URL-фрагмент путешествует с получателем

Либо в URL-фрагменте (никогда не отправляется на серверы), либо выводится из парольной фразы, которую выбирает отправитель. В обоих случаях мы его не видим.

block

Нет восстановления = нет бэкдора

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

Как строится клиент-сторонняя зашифрованная ссылка PDF

Прохождение того, что делают браузер отправителя, сервер и браузер получателя — с реальными вызовами Web Crypto.

1 — Браузер отправителя

// 256-битный AES-ключ, сгенерирован локально key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // свежий 96-битный IV на каждый файл iv = crypto.getRandomValues(new Uint8Array(12)) // шифруем локально; GCM даёт authentication tag для целостности ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // загружаем шифротекст + iv (и соль, если режим парольной фразы) id = await PUT("/api/transfer", ct, {iv, expiry})

2 — Форма ссылки

// режим фрагмента: ключ живёт после # link_f = `https://pdfpro.tools/s/<ID>#<KEY>` // режим парольной фразы: ключа в ссылке нет; получатель должен знать парольную фразу link_p = `https://pdfpro.tools/s/<ID>`

3 — Сервер хранит непрозрачные байты

ciphertext = ??? // случайно выглядящие, нечитаемые iv = 12-байтовый nonce salt = 16-байтовая случайная (только в режиме парольной фразы) expiry = 24ч free / 30д Pro

4 — Браузер получателя

// браузеры никогда не передают URL-фрагмент на сервер rawKey = /* из location.hash ИЛИ */ PBKDF2(passphrase, salt, 310_000, "SHA-256") ct = await GET("/api/transfer/" + id) pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // браузер сохраняет pdf в Загрузки

Режим фрагмента vs режим парольной фразы

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

Режим фрагмента

Ключ через URL-фрагмент (`#`)

Самый простой сценарий: скопировал ссылку, отправил получателю в чат, готово. Часть URL после # ни один совместимый браузер не отправляет ни на один веб-сервер — именно это удерживает ключ в тайне.

Один шаг для получателя — клик по ссылке.
Низкое трение, подходит для распространения с низкой и средней чувствительностью.
Риск: если ссылка утечёт в скриншоте или синхронизации браузера, файл утечёт вместе с ней.
Используйте при доверии к каналу (защищённый мессенджер, внутренний чат).

Режим парольной фразы

Ключ выводится из парольной фразы (PBKDF2)

Отправитель выбирает парольную фразу. Браузер выводит 256-битный ключ через PBKDF2-SHA256 с 310 000 итераций над случайной 128-битной солью. Соль хранится на сервере; парольная фраза передаётся получателю по отдельному каналу (телефон, Signal, лично).

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

Свойство	Режим фрагмента	Режим парольной фразы
Носитель ключа	URL-фрагмент (`#`)	Парольная фраза + соль
Сервер вообще видит ключ	Нет	Нет
Сервер хранит	Шифротекст + IV	Шифротекст + IV + соль
Трение для получателя	Клик по ссылке	Клик по ссылке + ввод фразы
Утечка через скриншот	Да (ссылка = ключ)	Нет (ссылка одна бесполезна)
Устойчивость к перебору	256-битный случайный	Зависит от парольной фразы
Лучше для	Распространения по доверенным каналам с низким трением	Более чувствительного распространения

Почему серверный шифротекст всё ещё защищает вас

Часто спрашивают: «Если он у вас на сервере, в чём приватность?» Ответ: шифротекст — это не файл. Без ключа это просто случайно выглядящие байты. Что это значит на практике.

storage

Утечка из БД = утечка шифротекста

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

gavel

Повестка получит шифротекст

Суд может обязать нас выдать то, что есть. У нас есть шифротекст. Решение суда не может задним числом создать ключ, которого мы никогда не хранили.

group

Инсайдерский доступ нейтрализован

Недобросовестный сотрудник с полными правами на БД всё равно не прочитает файлы. Гарантия обеспечивается математикой, а не управлением доступом.

timer

Срок жизни усиливает гарантию

Шифротекст удаляется по истечении (24 ч на free, до 30 д на Pro). После этого нет даже шифротекста — единственная копия файла существует там, где её расшифровали.

warningЧестные ограничения

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

Клиент-сторонее шифрование vs другие «безопасные» варианты

Чёткое сравнение типичных способов передачи PDF. Большинство «безопасных» опций — это шифрование в транспорте: данные защищены в пути, но принимающий сервер всё равно держит открытый текст и ключ.

Вариант	TLS в транспорте	Сервер может прочитать файл	Срок жизни	Аккаунт получателя
Email-вложение	Обычно да	Да — на каждом узле	Навсегда	Не требуется
Обычная облачная ссылка	Да	Да	Опционально	Иногда
PDF с паролем	Да	Да (если файл у хоста)	Никогда	Не требуется
PDF Pro (режим фрагмента)	Да	Нет	24ч / 30д	Не требуется
PDF Pro (режим парольной фразы)	Да	Нет	24ч / 30д	Не требуется

Связанное чтение

Распространение с требованием доверия vs Zero-Knowledge живая гонка

Одна цель — поделиться PDF. Смотрите, как две модели доверия приходят к финишу бок о бок.

cloud_upload

Распространение с требованием доверия

Сервер держит открытый текст

Загрузка PDF на сервер
Сервер держит открытый текстОткрытый текст
Сервер обещает удалитьДоверие
Риск утечки на их сторонеРиск
Получатель скачивает открытый текстОткрыт

Серверных копий открытого текста

Сервер может читать

Да

Ключи на сервере

Да

shield_lock

Этот инструмент

Zero-Knowledge распространение

Зашифровать PDF в браузереE2E
Сервер держит только шифротекстZero-Knowledge
Получатель расшифровывает локальноГотово

check_circle

Уже передано — и сервер не может это прочитать.

Никакого открытого текста на сервере. Никакого хранения ключа. Устойчиво к утечкам по дизайну.

Серверных копий открытого текста

Сервер может читать

Нет

Ключи на сервере

Нет

Анимация запускается один раз — нажмите «Повторить», чтобы посмотреть снова.

Часто задаваемые вопросы

Что в действительности означает клиент-сторонее зашифрованное распространение PDF?

Это значит, что сервер, хранящий ваш файл, буквально не может его расшифровать. Ключ шифрования генерируется в браузере отправителя, никогда не загружается, а собрать его может только браузер получателя — либо из URL-фрагмента, либо из парольной фразы, переданной отдельно. Гарантия обеспечивается криптографией, а не политикой управления доступом, которую мы могли бы поменять. Замечание: это отличается от формальных доказательств с нулевым разглашением (ZKP), которые продукт не использует.

Какое шифрование PDF Pro использует для клиент-стороннего распространения?

Симметричное шифрование AES-256-GCM с 96-битным случайным вектором инициализации на каждый файл. Для режима парольной фразы ключи выводятся через PBKDF2-SHA256 с 310 000 итераций над 128-битной случайной солью. Вся криптография работает через встроенный Web Crypto API браузера.

В чём разница между режимом фрагмента и режимом парольной фразы?

Режим фрагмента помещает 256-битный ключ в URL-фрагмент (после #), который браузеры никогда не отправляют ни на один сервер. Любой с полной ссылкой может расшифровать. Режим парольной фразы выводит ключ из парольной фразы, выбранной отправителем; без неё шифротекст остаётся нечитаемым. Режим парольной фразы безопаснее при утечке ссылки; режим фрагмента проще для распространения с низким трением. См. сравнительную таблицу выше.

URL-фрагмент действительно безопасен как носитель ключа шифрования?

Совместимые браузеры никогда не передают часть URL после # на сервер. Она остаётся на стороне клиента и видна только JavaScript, работающему во вкладке получателя. Именно это делает саму ссылку учётной записью для расшифровки — ключ путешествует с получателем, а не с загрузкой. Это можно проверить во вкладке Network: URL запроса обрезан на ? или #.

Может ли PDF Pro или суд прочитать файлы, сохранённые через клиент-сторонее зашифрованное распространение?

Нет. Сервер хранит шифротекст AES-256-GCM плюс вектор инициализации (плюс соль в режиме парольной фразы). Без ключа — а мы его никогда не получали — эти данные криптографически неотличимы от случайных байт. Мы можем раскрыть только шифротекст, и это всё, что у нас есть.

Что произойдёт, если я потеряю ссылку или забуду парольную фразу?

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

Бесплатно ли клиент-сторонее зашифрованное распространение PDF?

Да. Бесплатный тариф поддерживает шифрование AES-256-GCM и срок ссылки 24 часа без регистрации. Лимит размера на бесплатном тарифе — около 25 МБ за передачу; Pro продлевает срок до 30 дней и повышает лимиты по размеру файла.

Нужен ли получателю аккаунт?

Нет. Получатель кликает по ссылке, его браузер расшифровывает локально через Web Crypto API, и он скачивает файл — без регистрации, без установки, без портальной стены между ним и файлом.

Отправьте одну зашифрованную сквозным шифрованием ссылку. Дайте ей истечь по расписанию.

Шифрование AES-256-GCM в вашем браузере. Без регистрации, без серверного открытого текста, без бэкдора восстановления.

sendСоздать зашифрованную ссылку