iOS 上不同的填充类型有什么区别？
在 iOS 上， 证书、密钥和信任服务 API 包含以下填充类型：
kSecPaddingNonekSecPaddingPKCS1kSecPaddingPKCS1MD2kSecPaddingPKCS1MD5< /code>kSecPaddingPKCS1SHA1
上的用户Apple CDSA 邮件列表 表示“kSecPaddingPKCS1 [...] 与 PKCS #1 1.5 相同”。证书、密钥和信任服务参考用“Standard ASN.1”注释了后三种填充类型（kSecPaddingPKCS1MD2、kSecPaddingPKCS1MD5 和 kSecPaddingPKCS1SAH）将完成填充，以及底层 RSA 操作的 PKCS1 填充”。
- 与
kSecPaddingPKCS1有什么区别？ - 根据 RFC 3447，kSecPaddingPKCS1 只是底层 RSA 操作的原始填充吗？
- 使用 SecKeyRawSign() 签署 SHA-256、SHA-384 或 SHA-512 摘要时，开发人员是否需要使用 kSecPaddingPKCS1 并自行执行 ASN.1 填充？ ASN.1 填充是必需的还是可以省略？
任何为我指明正确方向的提示都将受到高度赞赏。
On iOS, the Certificate, Key, and Trust Services API contains the following padding types:
kSecPaddingNonekSecPaddingPKCS1kSecPaddingPKCS1MD2kSecPaddingPKCS1MD5kSecPaddingPKCS1SHA1
A user on the Apple CDSA mailing list says that "kSecPaddingPKCS1 [...] is the same as PKCS #1 1.5". The Certificate, Key, and Trust Services Reference annotates the latter three padding types (kSecPaddingPKCS1MD2, kSecPaddingPKCS1MD5, and kSecPaddingPKCS1SAH) with "Standard ASN.1 padding will be done, as well as PKCS1 padding of the underlying RSA operation".
- What is the difference to
kSecPaddingPKCS1? - Is
kSecPaddingPKCS1just the raw padding of the underlying RSA operation according to RFC 3447? - When signing a SHA-256, SHA-384, or SHA-512 digest with
SecKeyRawSign(), does a developer need to usekSecPaddingPKCS1and perform the ASN.1 padding herself? Is the ASN.1 padding necessary or can it be omitted?
Any hint that points me in the right direction is highly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
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 ||一个 || H
值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 似乎相当低级，整个事情很可疑看起来好像您正在尝试实现自己的加密协议，而不是使用现有的库或框架。）
PKCS#1 contains two "paddings" for signatures with RSA, the "new" one (called PSS, added in version 2.1) and the "old" one (renamed "v1.5" since it was already in version 1.5 of PKCS#1). We are talking about the v1.5 padding.
When some data is signed, it is first hashed with a suitable hash function (e.g. SHA-1), then the hash value (20 bytes if using SHA-1) is wrapped into two successive layers:
The hash value is encoded into an ASN.1-based structure which also specifies which hash function was used. In practice, if the hash value is H, then the first wrapping results in the sequence of bytes A || H where "||" is concatenation, and "A" is a header which is specific to the hash function (typically 15 to 20 bytes).
The "A || H" is expanded with some extra bytes:
0x00 0x01 0xFF 0xFF ... 0xFF 0x00 || A || H
The number of bytes of value 0xFF is adjusted to that the total size equals the size of the RSA modulus (i.e. 128 bytes for a 1024-bit RSA key).
The second step is what PKCS#1 calls "type 1 padding".
kSecPaddingPKCS1means that the function performs only the second step: it assumes that the input data is already the proper "A || H". Note that SSL/TLS (up to version 1.1) uses a signature variant which requires this mode (there's no "A", but there are two hash functions). WithkSecPaddingPKCS1SHA1, the signature function expects the hash value as input, and adds the "A" header itself.For a proper, standards-compliant signature which can be verified by third-party implementations, the "A" header must be added at some point. You can add it yourself and use
kSecPaddingPKCS1, or usekSecpaddingPKCS1SHA1and let the engine add it itself, which is probably less error-prone.(As of 2011, use of SHA-1 is not recommended; you'd better switch to SHA-256 or SHA-512. Also, the API you are trying to use seem to be quite low-level, and the whole thing suspiciously looks as if you are tying to implement your own cryptographic protocol instead of using an existing library or framework.)