我正在寻求实现一些有效（即具有良好性能）逻辑，在我们的Web应用程序中进行有效负载签名。目标是让HTML5客户端保证收到的有效负载的内容确实是我们后端生成的内容。
我们不希望使用共享salt进行有效负载哈希生成，因为用户可以轻松打开HTML5源并找到盐短语。
我们现在已经实施了RSA签名，我们的后端使用其私钥添加了有效负载签名，我们的HTML5客户端使用其在公钥中烘焙来验证它。然而，签名生成过程需要250ms（对于相对较小的有效载荷）并且由于签名请求的性质，这个时间量是不可接受的。
唯一的另一个想法是每次客户端使用后端初始化其会话时在运行时生成共享密钥。然而，秘密不能以明文形式发送，因此我们似乎必须实现Diffie-Hellman交换机制，如果可能的话我们要避免这种机制，或者使用现有库自动化。
请记住，由于我们销售产品的性质，需要在应用层进行保密和加密。我们不打算加密流量，这是我们的客户可能会或可能不会实现的（因为它是一个Intranet应用程序）。但是，我们必须避免将与我们的许可检查机制等相关的内容暴露给他们。后端不是基于云的，不受我们控制，而是安装在客户的机器上。
前端是Javascript，后端是Java。
请注意，Diffie-Hellman交换机制不受MITM攻击保护，因此不加密流量意味着您需要对来自服务器的DH数据进行身份验证。这就是使用基于DH的密码套件的Web服务器使用其服务器证书的私钥对通过网络发送的DH元素进行签名的原因，以便客户端检查这些元素是否真的来自他想要连接的服务器。这些要素是公开的，但需要签署。
您所谓的“带有共享盐的有效负载哈希生成”是一个密钥哈希消息身份验证代码，因此它基于共享密钥，正如您所注意到的那样，并且由于您不想使用此机制，这意味着您不会相信客户。因此，您必须使用不对称加密来签署您的有效负载。
使用非对称算法对服务器有效负载进行签名意味着您首先需要让服务器与客户端共享公钥。由于您不在客户端和服务器之间加密数据，因此需要在客户端源代码中部署服务器公钥。
您谈论签名生成过程，但客户端的签名检查过程在您的情况下也非常重要，因为用户必须等待结果的总时间是添加签名时间和检查时间签名（此外，如果要动态生成要签名的数据，则通常可以在服务器上预期签名，但无法预期验证）。因此，您需要一种快速检查客户端签名的方法。首先，签署哈希，而不是整个有效负载。然后在客户端选择开发环境中可用的最快的不对称签名算法。请注意，检查RSA签名比检查DSA或ECDSA签名更快，因为相应的密钥长度对应于相同的安全级别。所以你应该留在RSA。
所有这一切直到这一行可能对你没有多大帮助！现在有一种方法可以使用RSA来签名和验证签名来提高性能，这种方式与SSL / TLS在从同一服务器下载多个页面或其他对象时提高浏览器性能相同：使用会话缓存。您与特定用户共享特定会话的共同秘密。永远不要将此共同秘密用于其他会话。当用户第一次连接时，仅使用RSA一次，以交换短暂的共享密钥或交换DH材料以创建此共享密钥。然后，每次服务器需要对对象进行签名时，它都会创建一个带有此特定秘密的密钥哈希消息身份验证代码。因此，如果用户发现了秘密，例如使用他的浏览器的调试模式，这不是问题：这个秘密只是为了帮助他知道来自服务器的东西没有被改变。因此，用户无法使用此秘密来更改服务器与其他用户之间的数据交换。
我们最终在客户端和服务器端使用TweetNaCl。该库提供了一种简单快捷的方式来进行类似DH的共享秘密交换，而无需通过自定义实现。凭借短暂的共享秘密，我们可以轻松生成哈希值，而不是签名，因为我们的有效载荷从250毫秒降至10微秒。 RSA签署初始DH交换也很重要，也是我们使用RSA的唯一地方。
请阅读@AlexandreFenyo答案，了解如何处理此类案件的正确理论。