Cosign API 文档讨论了将哈希签名作为流缓冲区的替代方案。我将如何获取哈希然后使用 SAPI 对其进行签名？
对于业务应用程序而言，签名哈希是否足够安全？这是一种常见的做法吗？我问是因为发送哈希可能比发送大型文档进行签名更有效。
从我得到的答案中，我现在了解到客户端 SAPI 实际上会为我处理散列，并且只发送要签名的散列。尽管 SAPI Web 服务更通用（可以从任何平台访问），但它确实需要通过网络发送整个文档或在调用服务之前计算哈希值。
现在，如果我使用客户端 SAPI，是否足以部署 DLL/程序集，还是我还需要安装 CoSign 客户端？
根据您要签名的文档类型，计算哈希值可能不是一件容易的事。例如，Adobe PDF 格式支持在文档本身中嵌入数字签名，但为了正确执行此操作，必须根据 Adobe PDF 标准以特定方式计算散列值。
对于不支持数字签名标准的文档类型，获取整个文件的哈希值更容易，并且可以使用任何外部加密库或工具来完成。
问题是，为什么要将散列计算过程与签名操作分开，而 SAPI（CoSign 签名 API）负责根据标准计算散列，对其进行数字签名并将其嵌入回文档中？
SAPI 将始终在客户端计算机上计算文件/文档的哈希值，然后将该哈希值（并且只有哈希值）发送到 CoSign 服务器进行签名（是的，对哈希值进行签名确实是一种常见做法）。这也适用于支持嵌入签名的文档（例如 PDF、XML、DOCX、XLSX 等）。
话虽如此，如果您仍然对仅使用 SAPI 签署文档哈希感兴趣，您可以通过调用BufferSignEx函数并将AR_SAPI_SIG_HASH_ONLY常量插入到Flags参数中来实现。
回复：对于业务应用程序，签名哈希是否足够安全？
是的，所有标准数字签名都对哈希值进行签名。由于良好的散列（例如SHA-2）表示文档的内容，并且对文档的任何更改都会更改 SHA-2 值，因此散列是签名的，而不是文档。
回复：这是一种常见的做法吗？
是的，这是为 PDF、Word、Excel、XML 和其他任何东西创建标准数字签名的标准方法。
SAPI Windows 库为您处理散列问题。如果您使用 SAPI Web 服务对 PDF、Word 或 Excel 进行签名，则需要发送整个文档以进行签名，或者您需要在客户端处理散列。对于大多数文档类型而言，正确计算哈希是一项重要任务，因为必须以标准方式计算哈希，并且必须使用源文件中的正确数据对象。
一切都需要准确，因为信赖方（接收数字文档的人）将使用与您不同的软件来验证文档。您的散列软件的输出需要与他们的散列软件完全匹配。否则签名将无法验证。