iOS 上不同的填充类型有什么区别? [英] What is the difference between the different padding types on iOS?

问题描述

在 iOS 上，证书、密钥和信任服务 API 包含以下填充类型:

On iOS, the Certificate, Key, and Trust Services API contains the following padding types:

• kSecPaddingNone
• kSecPaddingPKCS1
• kSecPaddingPKCS1MD2
• kSecPaddingPKCS1MD5
• kSecPaddingPKCS1SHA1

Apple CDSA 邮件列表中的用户说kSecPaddingPKCS1 [...] 与 PKCS #1 1.5 相同".证书、密钥和信任服务参考使用标准 ASN.1"注释后三种填充类型(kSecPaddingPKCS1MD2、kSecPaddingPKCS1MD5 和 kSecPaddingPKCS1SAH)将完成填充，以及底层 RSA 操作的 PKCS1 填充".

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".

1. 与kSecPaddingPKCS1 有什么区别?
2. 根据 RFC 3447，kSecPaddingPKCS1 是否只是底层 RSA 操作的原始填充?
3. 在使用 SecKeyRawSign() 签署 SHA-256、SHA-384 或 SHA-512 摘要时，开发人员是否需要使用 kSecPaddingPKCS1 并执行 ASN.1 填充自己?ASN.1 填充是必需的还是可以省略?

1. What is the difference to kSecPaddingPKCS1?
2. Is kSecPaddingPKCS1 just the raw padding of the underlying RSA operation according to RFC 3447?
3. When signing a SHA-256, SHA-384, or SHA-512 digest with SecKeyRawSign(), does a developer need to use kSecPaddingPKCS1 and 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 包含两个填充"；对于带有 RSA 的签名，新的"一个(称为 PSS，在 2.1 版中添加)和旧"一个(重命名为v1.5"，因为它已经在 PKCS#1 的 1.5 版中).我们谈论的是 v1.5 填充.

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.

当一些数据被签名时，它首先用合适的散列函数(例如 SHA-1)散列，然后散列值(如果使用 SHA-1，则为 20 个字节)被包装成两个连续的层:

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:

1. 散列值被编码到基于 ASN.1 的结构中，该结构还指定使用了哪个散列函数.实际上，如果哈希值为H，那么第一次换行的结果是字节序列A ||H 其中||"；是连接，A"是特定于哈希函数的标头(通常为 15 到 20 个字节).

1. 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).

A ||H"扩展了一些额外的字节:

The "A || H" is expanded with some extra bytes:

0x00 0x01 0xFF 0xFF ... 0xFF 0x00 ||一个||嗯

值0xFF的字节数调整为总大小等于RSA模数的大小(即1024位RSA密钥为128字节).

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).

第二步是 PKCS#1 所谓的类型 1 填充".

The second step is what PKCS#1 calls "type 1 padding".

kSecPaddingPKCS1 表示函数只执行第二步:它假设输入数据已经是正确的A ||H".请注意，SSL/TLS(直到 1.1 版)使用需要此签名的变体模式(没有A"，但有两个散列函数).使用 kSecPaddingPKCS1SHA1，签名函数期望哈希值作为输入，并添加A"；标题本身.

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.

对于可由第三方实现验证的正确、符合标准的签名，A"必须在某个时候添加标题.您可以自己添加并使用 kSecPaddingPKCS1，或者使用 kSecpaddingPKCS1SHA1 并让引擎自行添加，这样可能不太容易出错.

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.

(截至 2011 年，不推荐使用 SHA-1；您最好切换到 SHA-256 或 SHA-512.此外，您尝试使用的 API 似乎相当低级，并且整个事情看起来很可疑，就好像您要实现自己的加密协议，而不是使用现有的库或框架.)

(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屋！