英文:
java openssl X509_SIG structure and encode / decode functions
问题
抱歉，你提供的内容似乎包含了代码部分，根据你的要求，我将不会翻译或回答与代码相关的内容。如果你有其他非代码的文本需要翻译，欢迎随时提问。
英文:
I'm trying to do in java a signature algorithm i've made in C that use the openssl C API RSA_sign function.
This function does not encrypt the data, but put the data into a X509_SIG structure with some metadata, encode the structure using i2d_X509_SIG openssl function and then finally encrypt the result of this encoding.
Is there a way to reproduce this way to sign data with Java ? Does X509_SIG struct and encoding / decoding functions exists in some java library ?
Yd
答案1
得分: 3
你已经错误描述（或误解）了RSA_sign的功能。
忽略掉一些在此不适用的特殊情况，它实现了最初在PKCS1 v1中定义的RSA签名方案，作为“type 1”，现在在PKCS1 v2中保留为RSASSA-PKCS1-v1_5（即来自PKCS1 v1.5的带附加的RSA签名方案）；参见rfc8017的第8.2节和第9.2节，以及第5.2节中的相关基元。为了签名（或者更正式地说，根据RFC更正式地生成签名），它按照以下顺序执行：
E1. 对消息进行哈希处理。
E2. 对哈希值进行编码，加上哈希算法的算法标识符，以DER格式的ASN.1结构DigestInfo表示；由于DER的工作方式，这等效于根据第9.2节中的注释添加一个固定的前缀。
E3-E5. 使用00 01 FF...进行填充（根据需要，但至少为8个）00。
G2. 将八位字节字符串转换为数字，应用原语RSASP1，该原语使用私有指数进行模指数运算，然后将（新的）数字转换回到正确大小的八位字节字符串。从历史上看，一代人之前，有时会将其描述为“使用私钥进行加密”，并且同样将RSAVP1描述为“使用公钥进行解密”，尽管这在语义上是错误的，因为签名不是加密，很快就发现这种混淆导致了脆弱且破损的系统设计，因此在本世纪我们称之为签名和验证。
RSA_sign要求调用者执行散列步骤（E1）。然后，它调用encode_pkcs1来执行步骤E2，将标准上称为DigestInfo的结构命名为X509_SIG。然后，它调用RSA_private_encrypt来执行步骤E3-E5和G2；这个命名是因为OpenSSL源自几十年前编写的SSLeay，在那时“签名是加密反过来”的混淆仍然很常见。
这个签名方案（1）是标准的，（2）非常常见，并且在Java加密中实现——包括标准要求的散列步骤，这与OpenSSL的RSA_sign不同，以及相同的DigestInfo步骤。请参阅https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#signature-algorithms中的java.security.Signature算法名称（方案）{SHA1,SHA256,etc}withRSA。
英文:
You have misdescribed (or misunderstood) what RSA_sign does.
Ignoring some special cases not applicable here, it implements the RSA signature scheme originally defined in PKCS1 v1 as 'type 1', and now retained in PKCS1 v2 as RSASSA-PKCS1-v1_5 (i.e. the RSA Signature Scheme with Appendix from v1.5 of PKCS1); see section 8.2 and section 9.2 of rfc8017, plus the related primitives in section 5.2. To sign (or as the RFC states it more formally, to generate a signature) this effectively does the following, in order:
E1. hash the message
E2. encode the hash value plus an algorithm identifier for the hash algorithm as the ASN.1 structure DigestInfo in DER; because of the way DER works this is equivalent to adding a fixed prefix as described in the Notes to section 9.2.
E3-5. pad with 00 01 FF... (as needed but at least 8) 00
G2. convert the octet string to a number, apply the primitive RSASP1 which does modular exponentiation with the private exponent, and convert the (new) number back to an octet string of the correct size. Historically, a generation ago, this was sometimes described as 'encrypting with the private key', and RSAVP1 similarly as 'decrypting with the public key', even though this is semantically wrong because signing is not encryption, and it was soon discovered that this confusion led to bad system designs that were vulnerable and broken, so in this century we call them signing and verifying.
RSA_sign requires the caller to do do the hashing step (E1). It then calls encode_pkcs1 to do step E2, using the name X509_SIG for the structure that is standardly called DigestInfo. It then calls RSA_private_encrypt which does E3-5 and G2; this naming is because OpenSSL descends from SSLeay which was written decades ago, when the confusion over 'signing is encryption backwards' was still common.
This signature scheme is (1) standard and (2) very common, and is implemented in Java crypto -- including the hashing step called for by the standard which differs from OpenSSL RSA_sign, and the DigestInfo step which is the same. See the java.security.Signature algorithm names (schemes) {SHA1,SHA256,etc}withRSA in https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#signature-algorithms .
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论