在 iOS 上，Certificate, Key, and Trust Services API 包含以下填充类型:
kSecPaddingNonekSecPaddingPKCS1kSecPaddingPKCS1MD2kSecPaddingPKCS1MD5kSecPaddingPKCS1SHA1
Apple CDSA mailing list 上的用户表示“kSecPaddingPKCS1 [...] 与 PKCS #1 1.5 相同”。证书、 key 和信任服务引用用“标准 ASN.1将完成填充，以及底层 RSA 操作的 PKCS1 填充”。
kSecPaddingPKCS1有什么区别？kSecPaddingPKCS1是否只是根据 RFC 3447 对底层 RSA 操作的原始填充？- 当使用
SecKeyRawSign()签署 SHA-256、SHA-384 或 SHA-512 摘要时，开发人员是否需要使用kSecPaddingPKCS1并执行 ASN. 1 填充自己？ ASN.1 填充是必需的还是可以省略？
非常感谢任何给我指出正确方向的提示。
最佳答案
PKCS#1包含两个用于 RSA 签名的“填充”，"new"一个(称为 PSS，在 2.1 版中添加)和“旧”一个(重命名为“v1.5”，因为它已经在 PKCS#1 的 1.5 版中)。我们正在谈论 v1.5 填充。
当一些数据被签名时，首先使用合适的散列函数(例如 SHA-1)对其进行散列，然后将散列值(如果使用 SHA-1 则为 20 字节)包装到两个连续的层中:
散列值被编码为基于 ASN.1 的结构，该结构还指定使用了哪个散列函数。实际上，如果哈希值是 H，那么第一个包装结果是字节序列 A || H 其中“||”是串联，“A”是特定于哈希函数的 header (通常为 15 到 20 字节)。
“A || H”扩展了一些额外的字节:
0x00 0x01 0xFF 0xFF ... 0xFF 0x00 ||一个||嗯
值 0xFF 的字节数调整为总大小等于 RSA 模数的大小(即 1024 位 RSA key 为 128 字节)。
第二步是 PKCS#1 所说的“类型 1 填充”。
kSecPaddingPKCS1 表示该函数仅执行第二步:它假定输入数据已经是正确的“A || H”。注意 SSL/TLS (直到版本 1.1)使用需要此模式的签名变体(没有“A”，但有两个哈希函数)。使用 kSecPaddingPKCS1SHA1，签名函数需要哈希值作为输入，并添加“A” header 本身。
对于可以由第三方实现验证的正确的、符合标准的签名，必须在某些时候添加“A” header 。您可以自己添加它并使用 kSecPaddingPKCS1，或者使用 kSecpaddingPKCS1SHA1 并让引擎自己添加它，这可能不太容易出错。
(截至 2011 年，不建议使用 SHA-1；您最好切换到 SHA-256 或 SHA-512。此外，您尝试使用的 API 似乎相当低级，并且整个事情看起来很可疑，好像您正在尝试实现自己的加密协议(protocol)，而不是使用现有的库或框架。)
关于iphone - iOS 上不同的填充类型有什么区别？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5054036/