发生在服务器 A 和服务器 B 上的加密和签名过程保护表单数据免受不必要的窃听和恶意（或意外）更改，从它们在服务器 A 上加密/签名的那一刻起，到它们在其上解密/验证的那一刻服务器 B。这包括 A 或 B 上的任何类型的存储，以及 A 和 B 之间使用的任何传输介质。但请注意以下几点：

• 加密和签名没有说明客户端提交的数据；正如@mikeazo 在评论中建议的那样，提交过程也最好受到保护。

• 多亏了签名，B 可以确定它收到的任何消息都是“真实的”（实际上就像 A 签名时一样）。但是，B 不知道他是否收到了所有消息；签名没有说明 B 从未见过的消息，因为攻击者在传递给 B 之前拦截了它们。

• 签名仅涵盖已签名的内容，而不包括可能与之关联的任何元数据。例如，只有当该用户的名称是表单数据的一部分时，才能验证表单数据是否与给定用户相关。否则，攻击者可以自由地在 A 的数据库中交换加密表格。同样，攻击者在 A 和 B 之间进行黑客攻击可以重播旧的加密消息，因此 B 不能确定他获得了给定用户的“最新”表单数据，除非该表单数据包含某种时间戳或序列号。

• 安全性仅与所涉及的私钥的保密性有关。相信获得 A 数据库访问权限的攻击者将无法访问 A 的私钥需要一点信心。

所以，当你的加密+签名系统确实提供了一些有用的保障，他们可能无法覆盖所有该设想攻击者可能会尝试。我邀请您在某处正式写下您授予所谓的攻击者的权力范围（这就是“攻击模型”）。

除此之外，使用 GnuPG 是一个非常好的主意，因为使用自制实现，或者更糟糕的是，自制协议将是一个非常糟糕的主意。