低内存嵌入式系统固件更新时，能否通过分块方式计算SHA-256哈希以实现实时验证？

好问题！这其实戳中了SHA-256这类密码学哈希函数的核心设计逻辑——它们本身就是为流式/分块计算而设计的，但并不是通过你设想的“把每个分块的独立哈希再组合”的方式，而是通过维护一个轻量的中间状态来逐步更新。

先澄清一个误区：为什么不能用分块独立哈希组合出整体哈希？ #

你提到的hash1（part1的独立哈希）、hash2（part2的独立哈希）这种方式，本质上是每个分块都从SHA-256的初始状态开始计算，得到的是各自独立的哈希值。但完整数据的哈希是基于前一个分块处理后的状态来计算下一个分块，这两种计算路径完全不同，所以不存在任何数学运算能把hash1、hash2、hash3直接组合成整体的hash——这是由SHA-256的迭代压缩机制决定的，也是它能保证抗碰撞性等安全特性的关键之一。

正确的实时计算方式：流式更新中间哈希状态 #

SHA-256的工作流程天生支持分块处理，你完全可以在接收数据的同时逐步计算哈希，不需要存储整个二进制文件，内存占用极低：

1. 初始化状态：先设置SHA-256的初始向量（IV），这是一组固定的8个32位值（总共32字节，非常小），作为初始的哈希状态。
2. 分块处理数据：
   • 用一个小型缓冲区（最多64字节，因为SHA-256处理的是512位/64字节的数据块）缓存接收到的字节。
   • 每当缓冲区凑满64字节，就调用SHA-256的压缩函数，用当前的哈希状态和这个64字节块计算出一个新的哈希状态，然后清空缓冲区继续接收数据。
3. 处理最后一块：当所有数据接收完成后，对缓冲区中剩余的字节进行SHA-256要求的填充（包括长度补位等规则），再调用一次压缩函数，得到的最终状态就是完整数据的SHA-256哈希值。

举个更直观的流程示例：

# 初始化
current_state = SHA256_INITIAL_IV
buffer = b""
total_length = 0

# 接收并处理part1
part1 = receive_data()
buffer += part1
total_length += len(part1)
while len(buffer) >= 64:
    block = buffer[:64]
    current_state = sha256_compress(current_state, block)
    buffer = buffer[64:]

# 接收并处理part2
part2 = receive_data()
buffer += part2
total_length += len(part2)
while len(buffer) >= 64:
    block = buffer[:64]
    current_state = sha256_compress(current_state, block)
    buffer = buffer[64:]

# 接收并处理part3，最后做填充
part3 = receive_data()
buffer += part3
total_length += len(part3)
# 执行SHA-256标准填充操作（补1、补0、补总长度的64位表示）
padded_buffer = sha256_pad(buffer, total_length)
# 处理填充后的所有块
while len(padded_buffer) >= 64:
    block = padded_buffer[:64]
    current_state = sha256_compress(current_state, block)
    padded_buffer = padded_buffer[64:]

# current_state就是完整数据的SHA-256哈希（可转换为十六进制字符串）
final_hash = bytes(current_state).hex()
if final_hash == hashReceived:
    print("哈希验证通过，继续固件更新")
else:
    print("哈希验证失败，终止更新")

针对低内存系统的优势 #

这种方式的内存开销只有：

• 32字节的当前哈希状态
• 最多64字节的数据缓冲区
• 压缩函数所需的临时变量（通常几十字节）

完全符合你低内存嵌入式系统的要求，而且完全遵循SHA-256的标准规范，不会破坏它的任何安全特性（抗碰撞性、不可逆性等）。

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