流式哈希防篡改需边接收边更新哈希，流结束时对固定摘要签名，而非直接加密原始流；验证端须同步重算哈希并比对签名解出的摘要，二者一致才可信。

对流（streaming）场景下做哈希签名防篡改，关键在于**不等数据全部到达再计算，而是边接收、边更新哈希，最后对最终哈希值签名**。它和传统“先读全文件再签名”的方式不同，适合大文件上传、实时视频帧处理、日志流推送等无法缓存全部内容的场景。

为什么不能直接对原始流签名？

非对称加密（如RSA）要求输入长度固定且有限——而流数据是持续、不定长的。直接用私钥加密整个流既不可行，也违背流式设计初衷。所以必须分两步：先用流式哈希累积摘要，再对这个确定的摘要签名。

核心步骤：流式哈希 + 末段签名

• 接收端边读边哈希：使用支持增量更新的哈希对象（如Python的hashlib.sha256()的update()方法），每收到一块数据（例如8KB chunk），就调用update(chunk)，内部自动维护当前哈希状态。
• 流结束时获取最终摘要：当流关闭或标记为EOF，调用digest()或hexdigest()拿到最终SHA-256值（32字节二进制或64字符十六进制字符串）。
• 仅对该摘要签名：用服务端私钥对这个固定长度的摘要进行RSA-2048签名，生成二进制签名（通常再Base64编码便于传输）。
• 一并发送三要素：原始流数据（可分块传输）、最终哈希值（明文，用于快速比对）、数字签名（用于身份与完整性双重验证）。

验证端也要流式重算哈希

接收方不能跳过哈希重算——哪怕你信任发送方发来的哈希值，也必须自己边收流边哈希，否则无法发现“流被中间人截断或注入”的情况。验证逻辑是：

• 收到数据流，同步执行与发送端完全一致的流式哈希（相同算法、相同分块逻辑）；
• 流结束后，得到本地哈希值；
• 用公钥解密收到的签名，还原出发送方的哈希值；
• 两个哈希值逐字节比对，一致才允许后续处理（如存盘、推理、转发）。

实际注意事项

• 分块边界要明确：避免因TCP粘包或分片导致不同设备对“同一块”的切分不一致，建议在流协议层定义帧头（含长度字段）或使用定长buffer读取。
• 不要省略哈希比对环节：仅验证签名有效 ≠ 数据没被篡改。攻击者可能替换整条流+伪造签名，但只要他不知道私钥，就无法让签名匹配你重算的哈希——所以必须两者都验。
• 时间戳或序列号可选增强：若需防重放（比如同一视频流被重复提交），可在签名前把时间戳或单调递增序号拼入哈希输入，即sha256(chunk1 + chunk2 + ... + timestamp)。