On 3/11/21 11:42 AM, Jarkko Sakkinen wrote:
On Thu, Mar 11, 2021 at 10:47:50AM +0800, Jia Zhang wrote:
On 2021/3/11 上午5:39, Jarkko Sakkinen wrote:
On Wed, Mar 10, 2021 at 08:44:44PM +0800, Jia Zhang wrote:
On 2021/3/2 下午9:47, Jarkko Sakkinen wrote:
On Mon, Mar 01, 2021 at 09:54:37PM -0800, Andy Lutomirski wrote:
On Mon, Mar 1, 2021 at 9:06 PM Tianjia Zhang
<tianjia.zhang@xxxxxxxxxxxxxxxxx> wrote:
On 3/1/21 5:54 PM, Jarkko Sakkinen wrote:
On Mon, Mar 01, 2021 at 01:18:36PM +0800, Tianjia Zhang wrote:
q2 is not always 384-byte length. Sometimes it only has 383-byte.
What does determine this?
In this case, the valid portion of q2 is reordered reversely for
little endian order, and the remaining portion is filled with zero.
I'm presuming that you want to say "In this case, q2 needs to be reversed because...".
I'm lacking these details:
1. Why the length of Q2 can vary?
2. Why reversing the bytes is the correct measure to counter-measure
this variation?
/Jarkko
When use openssl to generate a key instead of using the built-in
sign_key.pem, there is a probability that will encounter this problem.
Here is a problematic key I encountered. The calculated q1 and q2 of
this key are both 383 bytes, If the length is not processed, the
hardware signature will fail.
Presumably the issue is that some keys have parameters that have
enough leading 0 bits to be effectively shorter. The openssl API
(and, sadly, a bunch of the ASN.1 stuff) treats these parameters as
variable-size integers.
But the test uses a static key. It used to generate a key on fly but
IMO even though the test code, it comes from the linux kernel, meaning
that its quality has a certain guarantee and it is a good reference, so
the test code still needs to ensure its correctness.
Hmm... what is working incorrectly then?
In current implementation, it is working well, after all the static key
can derive the full 384-byte length of q1 and q2. As mentioned above, if
someone refers to the design of signing tool from selftest code, it is
quite possible that the actual implementation will use dynamical or
external signing key deriving shorter q1 and/or q2 in length.
A self-test needs is not meant to be generic to be directly used in 3rd
party code. With the current key there is not issue => there is no issue.
For keys generated on fly, self-test does not work properly, this
experience is really worse.
Best regards,
Tianjia
