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