[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Signature::Decode bug?
You are correct, the signature decoding logic in
cml/cmapi/src/CM_Signature.cpp, lines 363-420, is wrong. The DSA code
should simply use 20 bytes as the length of both the r and s values
(since only SHA-1 is supported).
For ECDSA, the length of r and s should both be nLen, which is not known
to the Signature::Decode() function. Therefore, for ECDSA, the code
should simply copy the r and s values from the decoded structure without
padding. (The correct padding will need to be performed prior to
performing signature verification.)
Thank you for reporting this bug. We'll add it to the list of changes
to be made for the next patch or release. At this point, however, we
don't have an anticipated date for the next SMP release due to funding
Richard E. Nicholas
Secure Systems Consultant
BAE Systems Information Technology
From: owner-imc-sfl@xxxxxxxxxxxx [mailto:owner-imc-sfl@xxxxxxxxxxxx] On
Behalf Of Bruce Stephens
Sent: Monday, December 18, 2006 12:39 PM
Subject: Signature::Decode bug?
This is quite probably a misunderstanding on my part, but the logic for
DSA and EC signature decoding in cml/cmapi/src/CM_Signature.cpp looks
The signature structures are both
s INTEGER }
the code decodes the signature, and then wants to put the two integers
in a buffer, with both integers being the same length (padding if
necessary). (Possibly DSA is more constrained than ECDSA.)
It uses the length of the hash to decide how long the integers are, but
that's wrong, I think: the length's determined by a property of the
asymmetric key. Specifically, for ECDSA the length is at most 2 nLen,
where nLen "is the length in octets of the base point order n".
Am I misunderstanding something?
(For usual size keys, and especially for DSA, I guess this'll work
fine: one wouldn't ordinarily use a hash with a DSA or ECDSA key which
produced a larger signature than the hash.)