PKCS#11中C_Decrypt（CKM_AES_CBC_PAD）调用异常问题咨询

先给你明确结论：这种情况更可能是Safenet Luna的PKCS#11库实现特性，而非你的代码问题，下面详细拆解原因和排查点：

1. PKCS#11规范的弹性空间 #

PKCS#11标准里对C_Decrypt的输出长度有明确说明：第一次传入NULL缓冲区时返回的是解密操作所需的最大缓冲区大小，而非精确的明文长度。有些厂商的实现会基于内部处理逻辑，要求输出缓冲区至少等于密文长度——哪怕最终明文更短。

对于AES-CBC-PAD来说，Safenet Luna的HSM内部可能是先把整个密文（272字节）解密成包含填充的中间数据，再去除填充得到256字节的明文。这个过程中，库会要求你的输出缓冲区能容纳中间的272字节数据，否则就返回CKR_BUFFER_TOO_SMALL，哪怕最终只需要256字节。

2. 快速排除代码问题的几个检查点 #

虽然大概率是库的问题，但还是可以快速确认几个细节：

• 第一次调用C_Decrypt（传NULL）时，返回的长度是不是272？如果是的话，库已经明确告诉你需要至少272字节的缓冲区，这时候传256报错是符合库的要求的。
• 确认ulEncryptedDataLen参数确实设为272，传入256字节缓冲区时ulDataLen是否正确初始化为256，调用后有没有检查返回的ulDataLen是否被更新为256。
• 排查缓冲区的实际可用空间：比如如果是栈上分配的缓冲区，有没有因为对齐或其他原因导致实际可用空间不足256字节？

3. Safenet Luna的常见实现特性 #

我接触过不少Safenet Luna的PKCS#11部署，这类HSM为了优化硬件内部的加密/解密流程，经常会要求输出缓冲区大小等于密文长度——哪怕最终明文更短。这是因为硬件模块更倾向于按块处理数据，直接输出完整的解密块后再由软件层处理填充，而不是在硬件内部做截断。

解决方案 #

既然调用272字节缓冲区能成功且返回正确的256字节长度，那最简单的解决方式就是按照库返回的最大长度（272字节）分配输出缓冲区，然后根据调用成功后返回的ulDataLen（256）来截取有效明文即可。这种做法既符合库的要求，也能保证解密结果正确。

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