David Shaw wrote:
On Mon, Dec 05, 2005 at 06:03:17PM -0500, David Shaw wrote:
On Sat, Nov 26, 2005 at 02:04:11PM +0000, Ben Laurie wrote:
b) EMSA-PKCS1-v1_5 takes two parameters - the message, m, and the length
of the encoded message, emLen. emLen is not specified in -15. By
inspection of existing signatures, it seems to me it is one less than
the size of the modulus (which strikes me as theoretically wrong, but if
that's the way it is, I guess that's the way it is).
I was under the impression that emLen was equal to the size of the
modulus. I'm a bit confused with the two different descriptions of
EMSA-PKCS1-v1_5 (one in rfc-2437, and one in rfc-3447). The leading
zero seems to have been added outside of EMSA-PKCS1-v1_5 in 2437 and
within it in 3447.
I did some digging and I think I see the problem here. 2440 and 1991
correctly describe the encoding. The instructions in 2440bis will not
work as EMSA-PKCS1-v1_5 (the RFC-2437 version) is only part of the
correct encoding. The encoding is effectively to calculate
EMSA-PKCS1-v1_5-ENCODE (m, emLen - 1) and then prefix the resulting
octet string with a zero octet. There is a similar situation with
leading zeroes for EME-PKCS1-v1_5 for the encrypted session key
packets.
To make things more complicated, EMSA-PKCS1-v1_5-ENCODE and
EME-PKCS1-v1_5-ENCODE in RFC-3447 *are* the correct encodings, leading
zero and all.
Since 3447 obsoletes 2437 anyway, maybe the easiest fix is to use 3447
and add a note along the lines of "Use 3447 and not 2437 - we really
mean it".
Assuming you are right about 3447 (I haven't checked it), then definitely.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff