iOS上不同的填充类型有什么区别？ [英] What is the difference between the different padding types on iOS?
问题描述
在iOS上，证书，密钥和信任服务 API包含以下填充类型：
-
kSecPaddingNone -
kSecPaddingPKCS1 -
kSecPaddingPKCS1MD2 -
kSecPaddingPKCS1MD5 -
kSecPaddingPKCS1SHA1
- 与
kSecPaddingPKCS1有什么区别？ - 是否根据RFC 3447的基础RSA操作的原始填充是
kSecPaddingPKCS1 - 当使用
SecKeyRawSign（）签名SHA-256，SHA-384或SHA-512摘要时，开发人员需要使用kSecPaddingPKCS1并执行ASN.1自己填充？ ASN.1填充是否需要或可以省略？
任何提示指向正确的方向非常感谢。 / p>
PKCS＃1 包含RSA签名的两个paddings，新的（称为PSS，在2.1版本中添加）和旧版（v1.5），因为它已经在版本中1.5 PKCS＃1）。我们正在谈论v1.5的填充。
当一些数据被签名时，首先用合适的散列函数（例如SHA-1）散列，然后哈希值（20字节，如果使用SHA-1）被包装成两个连续的层：
-
哈希值被编码为ASN .1的结构也指定使用哪个哈希函数。实际上，如果哈希值是H，那么第一个包装会导致字节序列A || H 其中 || 是连接， A 是特定于散列函数（通常为15到20字节）的标题。 / p>
-
A || H 扩展了一些额外的字节：
0x00 0x01 0xFF 0xFF ... 0xFF 0x00 || A || H
将值为0xFF 的字节数调整为总大小等于RSA模数的大小（即128字节的1024位RSA密钥）。
第二步是PKCS＃1调用type 1 padding。
kSecPaddingPKCS1 表示该函数仅执行第二步：它假定输入数据已经是正确的 A || H 。请注意， SSL / TLS （最高版本1.1）使用需要此模式的签名变体（没有 A ，但是有两个哈希函数）。使用 kSecPaddingPKCS1SHA1 ，签名函数希望将哈希值作为输入，并添加 A 标题。
对于可以通过第三方实现来验证的适当的，符合标准的签名，必须在某个时候添加 A 头。您可以自己添加，并使用 kSecPaddingPKCS1 ，或使用 kSecpaddingPKCS1SHA1 ，让引擎自身添加，这可能更少
（截至2011年，不推荐使用SHA-1;最好切换到SHA-256或SHA-512，另外，您尝试使用的API似乎是相当低级别的，整个可疑的看起来好像是要绑定实现自己的加密协议，而不是使用现有的库或框架。）
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.
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".
kSecPaddingPKCS1 means 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). With kSecPaddingPKCS1SHA1, 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 use kSecpaddingPKCS1SHA1 and 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.)
这篇关于iOS上不同的填充类型有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
