PDF 保护有两种类型：基于密码的加密和用户界面限制。您正在描述第二种保护类型，即缺少复制和粘贴、打印等权限。如果对 PDF 文件设置了用户界面限制，查看器仍需要解密内容才能将其显示在您的屏幕上，因此您不会处于缺少解密密钥的“基于密码的加密”场景中。文档，但在“DRM”场景中，您相信能够解密文件的应用程序（基于主密钥等静态知识）只执行作者希望他们执行的操作。

没有什么能阻止计算机专家对合法应用程序如何解密数据（不需要密码）进行逆向工程，并自行执行解密。在对文档进行解密之后，可以“调整”权限以例如包括打印许可或解密应用程序可以自己做一些事情（例如复制所有位图图像）。

Adobe 试图阻止允许您通过 PDF 规范上的许可规避使用限制的“流氓应用程序”：对于不遵守使用限制的应用程序，他们撤销了使用该规范中（声称的）知识产权的许可。AFAIK 一些开源工具已经或曾经有一个构建开关，用于确定是否应该遵守使用限制。这对于销售“PDF deprotector”软件的人来说是一个完美的起点。

在上述情况下，“用户密码”是空字符串。如果打开受保护的 PDF 文件，PDF 阅读器需要尝试输入空用户密码。只有当密码有效性检查失败时，用户才会要求输入密码。begueradj 在他的回答中描述了密钥派生，如您所见，“DRM 权限”（/P 条目）输入密钥派生，因此如果您只是在受保护的 PDF 文件中“修复权限”，符合标准的阅读器将派生错误的密钥，无法打开文档。另一方面，如果 PDF 文件完全受密码保护（甚至不被打开），则用户密码不再为空，并且这种类型的 PDF 保护相当安全。

Adobe 的 PDF 锁定功能遵循隐匿性安全规则。如果第三方软件能够解锁 PDF 文件，那是因为如果文件被加密，那么它必然包含解密所需的信息。

PDF文件的加密密钥生成如下：

   1. Pad the user password out to 32 bytes, using a hardcoded
       32-byte string:
           28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
           2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
       If the user password is null, just use the entire padding
       string.  (I.e., concatenate the user password and the padding
       string and take the first 32 bytes.)

    2. Append the hashed owner password (the /O entry above).

    3. Append the permissions (the /P entry), treated as a four-byte
       integer, LSB first.

    4. Append the file identifier (the /ID entry from the trailer
       dictionary).  This is an arbitrary string of bytes; Adobe
       recommends that it be generated by MD5 hashing various pieces
       of information about the document.

    5. MD5 hash this string; the first 5 bytes of output are the
       encryption key.  (This is a 40-bit key, presumably to meet US
       export regulations.)

该算法将用户密码和其他几个数据作为输入。在这些数据中，您可以找到：

        /Size 95         % number of objects in the file
        /Root 93 0 R     % the page tree is object ID (93,0)
        /Encrypt 94 0 R  % the encryption dict is object ID (94,0)
        /ID [<1cf5...>]  % an arbitrary file identifier    

        /Filter /Standard   % use the standard security handler
        /V 1                % algorithm 1
        /R 2                % revision 2
        /U (xxx...xxx)      % hashed user password (32 bytes)
        /O (xxx...xxx)      % hashed owner password (32 bytes)
        /P 65472            % flags specifying the allowed operations

软件将此算法用作解密过程：

    1. Take the 5-byte file key (from above).

    2. Append the 3 low-order bytes (LSB first) of the object number
       for the stream/string object being decrypted.

    3. Append the 2 low-order bytes (LSB first) of the generation
       number.

    4. MD5 hash that 10-byte string.

    5. Use the first 10 bytes of the output as an RC4 key to decrypt
       the stream or string.  (This apparently still meets the US
       export regulations because it's a 40-bit key with an additional
       40-bit "salt".)

当然，这是加密/解密的一般方案，但各种 Adob​​e PDF 版本之间或多或少存在差异。

进一步阅读

使用密码对 PDF 文件进行密码保护的主要问题是，您将安全性建立在密码之上，密码是人类用户在某个地方在他的脑海中想出的一些数据，并且自大到认为“猜不透”。事实证明，大多数密码都是可以猜到的。通过使密码到密钥的转换变得昂贵（这称为密码哈希）可以在一定程度上改善这种情况，但弱密码仍然很弱。

第二个问题是PDF 加密的格式不是一种，而是几种。PDF 加密在自定义方案方面有着悠久的历史，其中第一个方案在美国对加密感知软件有强大、严格的出口规则时生根发芽；简而言之，为了让软件可以在没有任何管理麻烦的情况下导出，加密货币必须是可笑的弱。因此，@begueradj 在他的回答中描述了加密格式：密码被散列，只有结果的前 40 位被保存为整个文件的“主密钥”。一个 40 位的密钥非常适合用当今的计算机进行详尽的搜索，这使得整个加密成为一个笑话。现在是可以制作高度加密的 PDF 文件，现代版本的 Adob​​e Reader 可以处理（我个人编写了一些代码来制作只能使用智能卡解密的 PDF 文件），但您必须明确地执行此操作。

使情况复杂化的是 PDF 的内部结构。PDF 是一组“对象”，其中一些是其他对象的流或原始数据。整个想法是文档应该适合各种访问，例如跳转到文档中的任何页面（可能在整个下载之前），或者提取目录。由于加密是在每个流的基础上应用的，通常的结论是可以在不破坏加密的情况下获得很多文档结构（例如页数，每段的长度，图片的数量，大小和位置...... ）。这是否是一个严重的问题取决于上下文，特别是为什么你想加密。这里真正的问题是，关于加密什么和不加密什么的决定是由一些通用软件做出的，根据定义，这些软件无法了解上下文。

在实践中，对 PDF 文件进行密码保护的目的不是为了让窃听者真正难以理解；以明确和不可避免的方式记录文件内容是敏感的，文件应小心处理。它相当于红色的“绝密”邮票。