Re: [pkix] How to select the ASN.1 structure of EC-SDSA (Schnorr signature with ECC)?

[Ernst G Giessmann <[e-mail]>]

Am 2022-08-22 um 22:27 schrieb Michael StJohns:
> On 8/22/2022 3:04 PM, Ernst G Giessmann wrote:
>> Hi folks,
>> TLDR;
>> is anywhere in PKIX the ASN1 format of the EC based Schnorr digital
>> signature algorithm EC-SDSA
>> (aka https://oid-rep.orange-labs.fr/get/1.0.14888.3.0.13)
>> defined?
>>
> AFAICT, not explicitly, but the German version of the spec
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03111/BSI-TR-03111_V-2-1_pdf.pdf?__blob=publicationFile&v=1
> suggests that the r field of a ECSDSA signature is still an integer,
> converted from the R value using the OS2I primitive on formation, and
> the I2OS primitive for verification.    That works for both the simple
> r||s and ASN1 encodings.
> 
> Mike

Mike,
thanks for the reference, but I'm not very sure that this is the right
approach. In contrast to EC-DSA the r field in EC-SDSA is clearly a
constant length hash value, and therefore the appropriate encoding seems
to be the constant length bit or octet string representation. An integer
encoding must ignore leading zero bits and has to consider the first bit
as a sign.

Other places where hash values show up in ASN1 are the KeyIdentifier in
X.509, the KeyHash in OCSP and the digest value encoding in PKCS#1 v1.5.
All are encoded as octet strings.

/Ernst

OT: In case of EC-FSDSA (full Schnorr) the r field is the elliptic curve
point P (aka pre-signature). Should it also be encoded as an integer? ;-).



>> This signature algo has the advantage, that it provides the full
>> strength of the hash function used, regardless of the strength (bit
>> length) of the underlying curve.
>>
>> Just to recall, it is defined as follows:
>>
>> Input:
>>     base point G of an elliptic curve
>>     privat key X (integer)
>>     public key [X]∙G (point on the curve)
>>     message to be signed M (octet string)
>>
>> Signing:
>> (FE2BS is the straight-forward field element to bit string conversion,
>> and BS2I the conversion of a base 2 representation to an integer)
>>     select a random integer K
>>     compute the pre-signature P = [K]∙G (point on the curve)
>>     witness R is computed as the hash of the x-coordinate PX of
>>       point P concatenated with the message M:
>>         R = h(FE2BS(PX) || M).
>>     the second part S of the signature (R,S) is computed as
>>         S = K + BS2I(R)X
>>
>> Verification:
>>     recompute the pre-signature
>>         P' = S∙G – BS2I(R)∙Y
>>     recompute the witness
>>         R' = h(FE2BS(P'X) || M)
>>     accept if R = R'
>>
>> In contrast to EC-DSA, where the elements R and S of the signature are
>> both integers, we got here the full length (no truncation as for
>> EC-DSA) hash value as a bit string R and an integer S.
>>
>> So I guess that the ASN.1 structure for EC-SDSA should be defined as
>>
>> ECSDSA-Sig-Value ::= SEQUENCE {
>>       r     BIT STRING,
>>       s     INTEGER }
>>
>> Is that correct?
>>
>> Thanks for any suggestions
>> /Ernst.
>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>