本文共 4126 字，大约阅读时间需要 13 分钟。
This article tell us that it's the same for signature encoding method (EMSA-PKCS1-v1_5) between PKCS#1 v2.0 and PKCS#1 v2.1:
arcoding to the rsassa-pkcs1-v1_5-sign(K,M), you must use the EMSA-PKCS1-v1_5-Encode to
realize the arithmetic.
how the csdn show my article like this, so sad. i must read the article in edit mode.
Suram Chandra Sekhar wrote:>> Hi,> I have a question on Encoding method for RSA signature as specified> in the ikev2-clarification-document.> > In Section 2.2,> Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]> signature encoding method (see next section for details), which> includes the algorithm identifier for the hash algorithm.>> Here it is said that IKEv2 uses the PKCS#1 v1.5.> > The next section> Section 2.3 specifies as follows...> > The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different> encoding methods (ways of "padding the hash") for signatures.> However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That> version has only one encoding method for signatures> (EMSA-PKCS1-v1_5), and thus there is no ambiguity.>> In this section it is said that IKEv2 points to the older PKCS#1 v2.0.> > Is this a typo or both the versions are same??IKEv2 uses the "PKCS#1 v1.5" encoding method and signaturegeneration/verification operations; the definition for thesecan be found in several different documents, including theoriginal PKCS#1 v1.5 (also RFC 2313), v2.0 (also RFC 2437) and v2.1 (also RFC 3447).The "v1.5" signature generation/verification operations definedin all those documents are compatible (but written slightlydifferently).> The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by > PKCS#1v2.1 (rfc 3447).> > The problem is that, for the encoding method EMSA-PKCS1-v1_5 > looks different in both the versions.> > Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to> form the encoded message as follows...>> 5. Concatenate PS, the DER encoding, and other padding to> form the encoded message EM as: > EM = 01 || PS || 00 || T> > Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form> the encoded message as follows..>> 5. Concatenate PS, the DER encoding T, and other padding to > form the encoded message EM as > EM = 0x00 || 0x01 || PS || 0x00 || T.>> In version 2.1 of PKCS#1, the encoding starts with 00 01 where as > in version 2.0 of PKCS#1, the encoding starts with 01.Adding zeroes in front of the message does not matter for RSAoperations, because they treat the message as a non-negativeinteger. So if one implementation implements RSA signaturegeneration/verification according to v2.1 and another implementor uses v2.0, they're still compatible.> I want to know the following things..> > 1. Why is it decided to go with an obsoleted rfc.No reason (or more likely, the reference was put there beforeRFC 3447 was published, and nobody updated it). The RFC editormight fix the reference to point to the latest version.> 2. I see there is ambiguity with padding between v2.0 and v2.1 > of PKCS#1. Can this be clarified further.We'll try to rephrase the text slightly when doing clarifications version -04.> I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with> the encoding method as only EMSA_PKCS1_V1_5. Also as specified in> the clarification document, hash function can be recommended to be> SHA1.> > Please clarify on this.>> Regards> SuramBest regards,Pasi_______________________________________________Ipsec mailing listIpsec at ietf.org
转载地址：http://mpnfb.baihongyu.com/