-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Johannes Merkle
Sent: Monday, July 23, 2012 3:16 PM
To: Dan Harkins
Cc: [email protected]; Tero Kivinen
Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec
>>
>> 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
For SHA-1, it is:
30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14
And there are other OIDs for a number of other hash functions. This OID (when
concatenated with the hash) is a DER string the means "The result of <Hash
Function> is <Hash>". And, yes, a signature verifier can use this OID string
to figure out which hash function to use (by running the RSA public operation
on the signature, looking through the resulting block, checking which OID it
lists, and then running the appropriate hash on the data).
When SHA-3 comes out, they'll just allocate more OIDs (if they haven't already)
to denote the various sizes of SHA-3; no confusion between SHA-256 and
SHA-3-256 will be necessary.
Perhaps you have this confused with signatures in IKEv1; there, they do
something nonstandard and don't include the OID (possibly because they are not
actually using the hash function, but instead the HMAC version).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
