Como a criptografia de PDF realmente funciona — e seus limites
Spec: ISO 32000-2, §7.6ISO 32000-2 §7.6
Visão geral
Seção intitulada “Visão geral”A criptografia de PDF embaralha as palavras e imagens dentro de um documento, de modo que só alguém com a senha certa pode lê-las. É criptografia genuína, e é boa no único trabalho que tem. Ela também é amplamente mal compreendida, porque o mesmo recurso carrega um segundo mecanismo — os flags de permissão — que parece uma tranca e não é.
Esta página separa os dois. Ela explica o que o AES-256 de fato protege, para que servem realmente as duas senhas, e onde fica a fronteira honesta.
Por que isso importa
Seção intitulada “Por que isso importa”As pessoas recorrem à criptografia quando um documento é sensível: um contrato, um contracheque, uma carta médica. A expectativa é razoável — mantenha isto privado e impeça que as pessoas o imprimam ou copiem. O PDF entrega a primeira metade desse desejo de forma convincente e a segunda metade apenas na base da confiança.
Confundir os dois é onde o custo recai. Uma equipe marca um arquivo como “não copiar”, confia que a plataforma faz cumprir isso, e o entrega. Meses depois alguém copia o texto em trinta segundos com um leitor diferente, e a suposição que nunca se sustentou silenciosamente se transforma em um vazamento. A criptografia nunca foi quebrada. Ela simplesmente foi solicitada a fazer algo que ela não faz.
A versão resumida
Seção intitulada “A versão resumida”- A criptografia protege a confidencialidade. Com AES-256, o conteúdo de string e de stream de um PDF é cifrado de verdade. Sem a chave, ele é ilegível.
- A senha de usuário abre o documento. Forneça-a e você pode ver o conteúdo. Sem ela, não há nada para ler.
- A senha de proprietário governa as permissões. Ela é a chave de “direitos plenos”. Os flags de permissão que ela protege — imprimir, copiar, modificar — são registrados dentro do documento criptografado.
- Os flags de permissão dependem da cooperação do leitor. Eles são um pedido a um leitor bem-comportado, não uma imposição. Um leitor que os ignora pode imprimir, copiar ou editar mesmo assim.
- A estrutura permanece visível. A criptografia esconde o conteúdo, não o esqueleto do documento — a contagem de páginas e o layout dos objetos não são o segredo.
Como o NextPDF aborda isso
Seção intitulada “Como o NextPDF aborda isso”A criptografia de PDF é definida por Spec: ISO 32000-2, §7.6ISO 32000-2 §7.6. O modelo é preciso: um security handler deriva uma chave de criptografia do arquivo a partir de uma senha, as strings e streams do documento são criptografadas com essa chave, e um encryption dictionary — referenciado a partir do trailer do arquivo — registra qual cifra foi usada, qual é o tamanho da chave, e quais permissões o autor declarou.
A cifra moderna e recomendada é o AES com uma chave de 256 bits. Quando você criptografa um PDF dessa forma, a carga legível — o texto que você extrairia, os bytes da imagem, os dados da fonte — é transformada em cifrado. A forma externa do documento permanece legível por design: um leitor tem de encontrar o encryption dictionary e descobrir o tamanho da chave antes de poder lhe pedir uma senha. É por isso que a criptografia é mais bem entendida como confidencialidade de conteúdo, não opacidade do arquivo inteiro.
As duas senhas ficam em camadas diferentes, e a distinção é a parte que mais vale a pena acertar.
- Uma senha é fornecidaOu a senha de usuário (abrir) ou a senha de proprietário (direitos plenos).
- O security handler deriva a chaveA ISO 32000-2 §7.6.4 transforma a senha na chave de criptografia do arquivo.
- O conteúdo é descriptografadoO AES-256 transforma as strings e streams criptografadas de volta em bytes legíveis.
- As permissões são consultadasA chave de proprietário concede todos os direitos; a chave de usuário é limitada pelos flags de permissão declarados — se o leitor escolher honrá-los.
A senha de usuário é a senha de abertura. Ela responde a uma pergunta: você pode ver o conteúdo, afinal? Sem senha de usuário, não há documento legível — essa parte é imposta criptograficamente, porque sem a chave derivada não há nada para descriptografar.
A senha de proprietário é a senha de permissões. Um arquivo pode ser aberto por qualquer pessoa (sem senha de usuário) e ainda assim declarar uma senha de proprietário que protege as ações de “direitos plenos” — imprimir em alta resolução, copiar texto, modificar o arquivo. De forma crucial, os bits de permissão que a senha de proprietário protege são protegidos quanto à integridade pelo standard security handler: adulterá-los é detectado e rejeitado por um leitor em conformidade, porque o handler vincula as permissões declaradas às chaves de criptografia. Os bits não são literalmente bytes ilegíveis ou ineditáveis — um atacante pode alterá-los — mas uma cópia alterada não vai validar, então um leitor em conformidade a trata como corrompida. Eles são à prova de adulteração de forma evidente. Eles simplesmente não são autoimpositivos.
Exemplo prático
Seção intitulada “Exemplo prático”As configurações de criptografia são simples de expressar. O que importa é ler o resultado com honestidade: isto configura uma intenção, e a parcela de permissão dessa intenção é consultiva.
<?php
declare(strict_types=1);
use NextPDF\Core\Document;use NextPDF\Security\Encryption\EncryptionMode;use NextPDF\Security\Encryption\Permission;
$document = Document::createStandalone();$document->setTitle('Confidential Offer');$document->addPage();
// Confidentiality is real: AES-256 means the content is unreadable// without the user password. This half is cryptographically enforced.$document->encrypt( userPassword: 'open-sesame', ownerPassword: 'full-rights-key', mode: EncryptionMode::Aes256, // Permissions are a declared request to a cooperating reader, // recorded inside the encrypted document — not a hard lock. permissions: Permission::Print->value | Permission::CopyContent->value,);
$document->save('offer.pdf');A senha de usuário e a de proprietário são chaves diferentes com trabalhos
diferentes. O argumento permissions declara o que um leitor bem-comportado
deveria permitir. São metadados honestos, protegidos quanto à integridade pelo
security handler de modo que a adulteração seja detectável — e esse é o teto do
que uma biblioteca produtora pode prometer.
Equívoco comum
Seção intitulada “Equívoco comum”A armadilha é ler “permissões” como “imposição”. É intuitivo: o flag diz impressão não permitida, então com certeza a impressão está bloqueada. Mas nada no PDF pode esticar a mão e desativar o botão de imprimir de um leitor. O inteiro de permissão é registrado para um leitor cooperante honrar. Um leitor que escolhe não cooperar — e vários não cooperam — está livre para imprimir, copiar e editar.
O NextPDF é deliberado quanto a isto. O caminho de criptografia do core trata os flags de permissão como intenção declarada e nunca finge impô-los. Se você precisa que ações sejam genuinamente impedidas, esse controle tem de viver fora do arquivo — em quem você dá o documento, ou em um sistema de controle de acesso ao redor dele.
Limites e fronteiras
Seção intitulada “Limites e fronteiras”Seja preciso sobre o que cada metade garante. A criptografia (a camada de senha de usuário) é um controle de confidencialidade real: forte se a senha for forte, e tão boa quanto o segredo que você escolher. As permissões (a camada de senha de proprietário) são metadados à prova de adulteração de forma evidente, não controle de acesso.
| O que você pode esperar | O que a criptografia de fato entrega |
|---|---|
| Ninguém consegue ler o conteúdo sem a senha | Verdadeiro. Com AES-256 e uma senha de usuário forte, as strings e streams são ilegíveis sem a chave. Genuinamente imposto. |
| Ninguém consegue reescrever “não copiar” para “cópia permitida” | À prova de adulteração de forma evidente, não impossível. Os flags de permissão são protegidos quanto à integridade pelo standard security handler: um forasteiro pode editar os bytes, mas a cópia alterada não vai validar, então um leitor em conformidade detecta e rejeita a mudança. |
| O leitor será impedido de copiar ou imprimir | Não garantido por nenhum produtor de PDF. Um leitor não cooperante pode ignorar os flags. Isto é uma propriedade do formato, não uma limitação do NextPDF. |
Duas fronteiras adicionais valem ser declaradas com todas as letras. Primeira, a
criptografia protege o conteúdo, não a estrutura do documento: o layout dos
objetos e a contagem de páginas permanecem visíveis, o que é normal e necessário
para um leitor localizar o encryption dictionary. Segunda, um PDF criptografado
não pode também reivindicar conformidade de arquivamento PDF/A — esse perfil
proíbe a entrada Encrypt, então você escolhe um ou o outro. A
página de solução de problemas sobre criptografia e permissões
cobre as exceções específicas e a recusa do PDF/A em detalhe.
Documentos relacionados
Seção intitulada “Documentos relacionados”- O panorama dos padrões — onde a ISO 32000-2 e suas cláusulas de criptografia se situam entre os padrões de PDF.
- Criptografia e flags de permissão — as entradas práticas: falhas de descriptografia, e a fronteira de permissão em código.
- O que um PDF realmente é — o modelo de objetos que a criptografia protege, e a estrutura que ela deixa visível.
- Como as assinaturas ficam em um PDF — a outra metade da confiança no documento: a criptografia esconde, as assinaturas provam.
Glossário
Seção intitulada “Glossário”- AES-256 — o Advanced Encryption Standard com uma chave de 256 bits, a cifra moderna recomendada para a criptografia de conteúdo de PDF.
- Senha de usuário (senha de abertura) — o segredo exigido para abrir e ler um documento criptografado. Sem ela, o conteúdo não pode ser descriptografado.
- Senha de proprietário (senha de permissões) — o segredo de “direitos plenos” que governa os flags de permissão. Um documento pode ter uma sem exigir uma senha de usuário para abrir.
- Flags de permissão — a intenção declarada de imprimir/copiar/modificar armazenada no encryption dictionary. Protegidos quanto à integridade de modo que a adulteração seja detectável, mas honrados apenas por um leitor cooperante.
- Security handler — o componente que deriva a chave de criptografia do arquivo a partir de uma senha, definido pelo standard security handler na ISO 32000-2.
- Dependente da cooperação do leitor — um controle que depende de o software consumidor escolher obedecê-lo, em vez de ser imposto pelo arquivo em si.