What does client-side encrypted PDF sharing actually mean?

It means the server storing your shared file literally cannot decrypt it. The encryption key is generated in the sender's browser, never uploaded, and only the recipient's browser can reconstruct it — either from the URL fragment or from a passphrase the sender shares out-of-band. The server only ever holds ciphertext.

What encryption does PDF Pro use for client-side encrypted sharing?

AES-256-GCM symmetric encryption with a 96-bit random initialization vector per file. For passphrase mode, keys are derived via PBKDF2-SHA256 with 310,000 iterations over a 128-bit random salt.

What is the difference between fragment mode and passphrase mode?

Fragment mode puts the 256-bit key in the URL hash (after #), which browsers never send to the server. Anyone with the full link can decrypt. Passphrase mode derives the key from a passphrase the sender picks — the ciphertext stays unreadable without it. Passphrase mode is safer if the link leaks; fragment mode is easier for low-friction sharing.

Is a URL fragment really safe as an encryption key carrier?

Compliant browsers never transmit the fragment portion of a URL (after #) to the server. It stays client-side. That's what makes the share link itself the decryption credential — the key rides with the recipient, not with the upload.

Can PDF Pro or a court read files stored via client-side encrypted sharing?

No. The server stores AES-256-GCM ciphertext plus an initialization vector (plus a salt in passphrase mode). Without the key — which we never received — that data is cryptographically indistinguishable from random bytes. We can only disclose ciphertext, which is what we have.

What happens if I lose the link or forget the passphrase?

The file is permanently unrecoverable. This is by design — client-side encryption means no recovery path, because a recovery path would require us to hold the key.

Is client-side encrypted PDF sharing free?

Yes. The free tier supports AES-256-GCM encryption and 24-hour link expiry with no signup required. The free-tier file cap is approximately 25 MB per transfer; Pro extends the expiry window and raises file limits.

Does the recipient need an account?

No. The recipient clicks the link, their browser decrypts locally via the Web Crypto API, and they download the file — no signup, no install.

Шифрование на стороне клиента · Обмен PDF

Обмен PDF с шифрованием на стороне клиента — объяснение по существу.

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

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

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

Что здесь означает «нулевое знание»

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

memory

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

Не на сервере, не в воркере, который вы не контролируете, — у вас во вкладке, через window.crypto.subtle. Поддаётся проверке в DevTools.

cloud_off

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

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

vpn_key

Ключ движется вместе с получателем

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

block

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

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

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

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

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

// 256-bit AES key, generated locally key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // fresh 96-bit IV per file iv = crypto.getRandomValues(new Uint8Array(12)) // encrypt locally; GCM gives us an auth tag for integrity ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // upload ciphertext + iv (and salt, if passphrase mode) id = await PUT("/api/transfer", ct, {iv, expiry})

2 — Форма ссылки для обмена

// fragment mode: key lives after # link_f = `https://pdfpro.tools/s/<ID>#<KEY>` // passphrase mode: no key in the link; recipient must know the passphrase link_p = `https://pdfpro.tools/s/<ID>`

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

ciphertext = ??? // random-looking, unreadable iv = 12-byte nonce salt = 16-byte random (passphrase mode only) expiry = 24h free / 30d Pro

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

// browsers never transmit the URL fragment to the server rawKey = /* from location.hash OR */ PBKDF2(passphrase, salt, 310_000, "SHA-256") ct = await GET("/api/transfer/" + id) pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // browser serves pdf to Downloads

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

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

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

Ключ перемещается в хеше URL (`#`)

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

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

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

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

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

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

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

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

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

storage

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

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

gavel

Повестка приносит шифротекст

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

group

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

Сотрудник-злоумышленник даже с полными учётными данными к базе всё равно не сможет прочитать файлы. Гарантия обеспечивается математикой, а не контролем доступа.

timer

Истечение срока усиливает гарантию

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

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

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

Шифрование на стороне клиента и другие «безопасные» варианты

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

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

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

Обмен на доверии против нулевого знания живая гонка

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

cloud_upload

Обмен на доверии

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

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

Копии открытого текста на сервере

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

Да

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

Да

shield_lock

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

Обмен с нулевым знанием

Зашифровать PDF в браузереE2E
Сервер хранит только шифротекстНулевое знание
Получатель расшифровывает локальноГотово

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 плюс вектор инициализации (плюс соль в режиме парольной фразы). Без ключа — которого мы никогда не получали — эти данные криптографически неотличимы от случайных байтов. Мы можем выдать только шифротекст, что у нас и есть.

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

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

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

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

Нужна ли получателю учётная запись?

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

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

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

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