使用ECDSA P-384签名验签时，公钥是否需嵌入待签名消息？

不需要强制把公钥嵌入待签名的JSON，两种传输方式各有适用场景，核心差异体现在验签流程、消息保护范围和效率上，具体分析如下：

1. 分开传输公钥、JSON消息、签名 #

• 流程优势：接收方拿到公钥后，直接就能对原始JSON字符串做验签，完全不用先解析JSON——如果验签失败，甚至可以跳过解析步骤，避免无效的资源消耗，解决你担心的流程冗余问题。
• 注意事项：要保证公钥、消息、签名三者的对应关系不混乱，比如可以约定固定的传输格式：HTTP请求里把JSON消息放body，公钥和签名放在请求头；或者封装成一个外层结构（但外层结构绝对不能加入签名范围）。
• 适用场景：双方已经通过可信渠道提前交换过公钥（比如预存在系统配置里），或者能通过可信身份体系获取公钥（比如数字证书）的情况，这种场景下分开传效率更高。

2. 公钥嵌入待签名的JSON #

• 流程特点：必须先解析JSON取出公钥才能验签，但这么做的核心价值是公钥本身也被纳入签名保护范围——如果传输过程中公钥被篡改，验签会直接失败，能确保你用的公钥就是签名者绑定的原始公钥。
• 缺点：正如你提到的，流程确实冗余，尤其是JSON体积较大时，解析成本会更高；另外，P-384的公钥转成Base64后大概128字符左右，会增加消息的传输体积。
• 适用场景：没有提前交换公钥的一次性交互场景，比如陌生节点之间的临时通信，接收方完全不知道签名者身份，需要通过消息内的公钥来验证身份，同时确保公钥未被篡改。

核心差异对比 #

• 验签时机：分开传输可先验签再解析，嵌入则必须先解析再验签
• 保护范围：嵌入时公钥属于签名保护内容，能防篡改；分开传输的公钥不在签名范围内，需要额外信任其传输渠道
• 效率：分开传输的验签流程更高效，大体积消息场景下优势更明显

总结下来：如果有可信的公钥分发渠道，优先选分开传输；如果是无预存公钥的陌生交互，再考虑将公钥嵌入JSON并纳入签名范围。

内容的提问来源于stack exchange，提问作者sudoExclamationExclamation