在iOS上,Certificate, Key, and Trust Services API包含以下填充类型:
kSecPaddingNone
kSecPaddingPKCS1
kSecPaddingPKCS1MD2
kSecPaddingPKCS1MD5
kSecPaddingPKCS1SHA1
Apple CDSA mailing list上的用户说“kSecPaddingPKCS1 [...]与PKCS#1 1.5”相同。证书,密钥和信任服务参考使用“标准ASN.1填充以及PKCS1”注释后三种填充类型(kSecPaddingPKCS1MD2
,kSecPaddingPKCS1MD5
和kSecPaddingPKCS1SAH
)底层RSA操作的填充“。
kSecPaddingPKCS1
有什么区别? kSecPaddingPKCS1
只是基础RSA操作的原始填充吗?SecKeyRawSign()
签署SHA-256,SHA-384或SHA-512摘要时,开发人员是否需要使用kSecPaddingPKCS1
并自行执行ASN.1填充? ASN.1填充是必要的还是可以省略?任何暗示我指向正确方向的提示都受到高度赞赏。
答案 0 :(得分:21)
PKCS#1包含两个用于RSA签名的“填充”,“新”签名(称为PSS,在2.1版中添加)和“旧”签名(由于它已经在以前更名为“v1.5”) PKCS#1版本1.5)。我们正在谈论v1.5填充。
当一些数据被签名时,首先使用合适的散列函数(例如SHA-1)进行散列,然后散列值(如果使用SHA-1则为20字节)被包装成两个连续的层:
哈希值被编码到基于ASN.1的结构中,该结构还指定使用了哪个哈希函数。实际上,如果哈希值是 H ,那么第一个包装将产生字节序列 A || H 其中“ || ”是串联,“ A ”是特定于散列函数的标头(通常为15到20个字节)。 / p>
“ A || H ”扩展了一些额外的字节:
0x00 0x01 0xFF 0xFF ... 0xFF 0x00 || A || ħ
将值 0xFF 的字节数调整为总大小等于RSA模数的大小(即1024位RSA密钥的128字节)。
第二步是PKCS#1调用“类型1填充”。
kSecPaddingPKCS1
表示该函数仅执行第二步:它假定输入数据已经是正确的“ A || H ”。请注意,SSL/TLS(最高版本1.1)使用需要此模式的签名变体(没有“ A ”,但有两个散列函数)。使用kSecPaddingPKCS1SHA1
,签名函数将哈希值作为输入,并添加“ A ”标题本身。
对于可由第三方实施验证的正确,符合标准的签名,必须在某个时刻添加“ A ”标头。您可以自己添加并使用kSecPaddingPKCS1
,或使用kSecpaddingPKCS1SHA1
并让引擎自行添加它,这可能不太容易出错。
(截至2011年,不建议使用SHA-1;您最好切换到SHA-256或SHA-512。此外,您尝试使用的API似乎相当低级,并且整个事情看起来好像你想要实现自己的加密协议而不是使用现有的库或框架。)