文件或消息能否包含自身HMAC？实际应用中HMAC应如何存储？

HMAC存储方式选择 #

两种存储方式都符合规范，根据你的业务场景选择即可：

• 优先选择将HMAC追加到加密后的密文末尾：这种方式不需要额外维护独立的HMAC存储字段，避免出现密文和HMAC关联错位的问题。操作时提前约定使用的HMAC算法对应的固定输出长度，比如HMAC-SHA256固定输出32字节，读取时直接取密文末尾的固定长度内容作为HMAC，剩余部分作为待校验的密文即可。
• 分开存储仅适用于有特殊需求的场景：如果你的业务需要单独拉取校验值做批量校验、或者数据库表结构已经预留了独立的校验字段，也可以将HMAC存在单独的字段中，注意必须用同一个主键关联密文和对应HMAC，避免关联错误。

消息能否包含自身的HMAC #

完全不可能。HMAC的计算依赖完整的输入消息内容，如果你要把HMAC写入消息本身，会出现逻辑死锁：计算HMAC时需要先拿到完整的消息内容，但写入HMAC后消息内容发生了变化，原本计算出的HMAC就失效了，永远无法得到可以匹配自身内容的HMAC值。

针对你的场景的额外建议 #

针对非受信数据库存储加密键值对的场景，更推荐直接使用AEAD（带关联数据的认证加密）算法，比如AES-GCM、ChaCha20-Poly1305，这类算法原生同时支持加密和完整性校验，不需要你手动拼接HMAC，也能避免自行实现加密+HMAC组合时容易出现的密钥复用、校验顺序错误等安全漏洞。注意无论用哪种方案，都要先校验完整性通过后，再执行解密操作，不要先解密再校验。

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