>>> With RSA the hash algorithm is encoded into the padding so there is >>> no real need to independently agree on a hash algorithm. >> >> No, in RSA PKCS#1v1.5 padding (which is currently the only supported >> padding in IKEv2), the hash algorithm is *not* encoded in the padding. >> Only the length of the length of the hash value can be determined due >> to the reserved zero octet leading the hash value. For SHA-1 and the >> SHA-2 hash functions, the length also determines the function, so your >> assertion in in some way true for these functions. However, RFC 5996 >> does not restrict the hash function to these. As soon as one of the >> SHA-3 contributions is used, the function can not be determined from >> the padding, as SHA-3 contributions were required support 224, 256, >> 384, and 512-bit message digests, exactly the lengths generated by the >> SHA-2 functions. > > Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, aka > RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, section > A.2.4 for both documents. > > To summarize, when using PKCS#1v1.5, the padded message is of the format: > 00 02 FF FF FF FF ... FF 00 <OID> <Hash> > (where there are enough FF bytes to exactly fill the RSA block). > > The byte string I marked as <OID> is a string that depends on the hash > algorithm used; for SHA-256, it is: > 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 >
Right, I was mistaken, I had looked into the padding scheme of the PKCS#1v1.5 encryption scheme not signature. Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
