Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible.

["Markku-Juhani O. Saarinen" <[e-mail]>]

On Thu, Sep 29, 2022 at 2:51 PM John Gray <John.Gray=
[e-mail]> wrote:

> We are doing some interoperability testing with different vendors using
> the new Dilithium, Falcon and SPHINCS+ algorithms.   We have come across at
> least two drafts which are trying to specify the ASN.1 encoding formats for
> these algorithms.   However, the encoding formats are not compatible with
> each other.   I imagine the authors of these drafts should get together and
> come up with a common format (I have copied them on this email).   This
> means we must choose one or the other, or even worse, support multiple
> formats (which can lead to bugs).   Initially I started more than a year
> ago using my own encoding format for internal prototyping, but now need to
> interoperate with others outside of our organization, so a common format is
> definitely needed at this point.   😊
>

Indeed it is remarkable that various people have been trying to create
"exploded" ASN.1 encodings for Dilithium keys, none of which are compatible
with each other, *or the actual Dilithium specification, reference
implementation, and the test vectors*.

Section 5.4 of the specification defines it as a concatenated byte
sequence, or as a 32-byte seed value. For ASN.1 these can be naturally
expressed as a simple OCTET STRING.
https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf





*"Secret key. The secret key contains ρ, K , tr, s1 , s2 and t0 and is also
stored as theconcatenation of the bit-packed representation of these
quantities in the given order.Consequently, a secret key requires 32 + 32 +
32 + 32((k + `) · dlog(2η + 1)e + 13k) bytes.As mentioned previously, the
signer also has the option of simply storing the 32-byte valueζ and then
simply re-deriving all the other elements of the secret key."*

The public key is similarly defined. There is no practical advantage of
exploding it into individual components -- repacking would always be needed
for both signing and signature verification.

Best Regards,
- markku

Dr. Markku-Juhani O. Saarinen
Staff Cryptography Architect
PQShield Ltd



M:             [phone]

E:              [e-mail]
W:             www.pqshield.com




>
>
> We fully realize the OID values will be changing once official OIDs are
> registered, (changing those are trivial), but the ASN.1 formats of the
> public and private keys is kind of important as well…  😊
>
>
>
For example:
>
>
>
> The LAMPS group has a specification of Dilithium public keys in this draft:
>
> https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/
>
>
>
> the public key format is this:
>
>
>
> The Dilithium public key MUST be encoded using the ASN.1 type
>
>    DilithiumPublicKey:
>
>
>
>      DilithiumPublicKey ::= OCTET STRING
>
>
>
> The private key format is this:
>
>
>
>      DilithiumPrivateKey ::= SEQUENCE {
>
>          rho         BIT STRING,         - nonce/seed
>
>          K           BIT STRING,         - key/seed
>
>          tr          BIT STRING,         - PRF bytes (CRH in spec.)
>
>          s1          BIT STRING,         - vector l
>
>          s2          BIT STRING,         - vector k
>
>          t0          BIT STRING,         - encoded vector
>
>          PublicKey   IMPLICIT DilithiumPublicKey OPTIONAL
>
>      }
>
>
>
>
>
> In this draft:
>
> https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/
>
>
>
> Dilithium keys have this encoding:
>
>
>
>
>
>    DilithiumPublicKey ::= SEQUENCE {
>
>        rho         OCTET STRING,
>
>        t1          OCTET STRING
>
>    }
>
>
>
>
>
>   DilithiumPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}     -- version (round 3)
>
>        nonce       BIT STRING,         -- rho
>
>        key         BIT STRING,         -- key/seed/D
>
>        tr          BIT STRING,         -- PRF bytes (CRH in spec)
>
>        s1          BIT STRING,         -- vector(L)
>
>        s2          BIT STRING,         -- vector(K)
>
>        t0          BIT STRING,
>
>        publicKey  [0] IMPLICIT DilithiumPublicKey OPTIONAL
>
>                                        -- see next section
>
>    }
>
>
>
> The draft-uni-qsckeys does not cover SPHINCS+,  it does cover Falcon, but
> I don’t know of another draft that specifies Falcon.
>
>
>
> There are also encodings for Kyber mentioned in two documents that I see.
> There is an early
> https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/
>  draft which mentions it is up to the document defining Kyber to give more
> details.    In the draft-uni-qsckeys draft it is more specific.
>
>
>
> https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/
>
>
>
>    KyberPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}   -- version (round 3)
>
>        s           OCTET STRING,     -- sample s
>
>        publicKey   [0] IMPLICIT KyberPublicKey OPTIONAL,
>
>                                      -- see next section
>
>        hpk         OCTET STRING      -- H(pk)
>
>        nonce       OCTET STRING,     -- z
>
>    }
>
>
>
> Partial public key encoding:
>
>
>
> KyberPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}   -- version (round 3)
>
>        s           OCTET STRING,     -- EMPTY
>
>        publicKey   [0] IMPLICIT KyberPublicKey OPTIONAL,
>
>                                      -- see next section
>
>        hpk         OCTET STRING      -- EMPTY
>
>        nonce       OCTET STRING,     -- d
>
>    }
>
>
>
> Full public key encoding:
>
>
>
>    KyberPublicKey ::= SEQUENCE {
>
>        t           OCTET STRING,
>
>        rho         OCTET STRING
>
>    }
>
>
>
> Is https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/ meant to become
> the document that defines the key formats for all the PQ keys that will be
> standardized?    If not, then it should probably just refer to whatever
> documents will define the formats so that we can at least agree on one
> common format for the PQ keys.
>
>
>
>
>
> Cheers,
>
>
>
> John Gray
>
> Entrust
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>