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

[Christine Cloostermans <[e-mail]>]

That would be in the LAMPS WG.

Thanks and cheers,

Christine

On Thu, Sep 29, 2022, 15:26 Mike Ounsworth <[e-mail]>
wrote:

> Thanks Christine! Valuable work, and good to see you still active in this
> space!
>
>
>
> Last question from me: which working group are you doing this through? I
> just want to make sure I don’t miss updates and discussion!
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Christine Cloostermans <[e-mail]>
> *Sent:* September 29, 2022 4:48 AM
> *To:* Mike Ounsworth <[e-mail]>
> *Cc:* Bas Westerbaan <[e-mail]>; Massimo, Jake <
> [e-mail]>; John Gray <John.Gray=[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]; Panos Kampanakis (pkampana) <
> [e-mail]>; Sean Turner <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Markku-Juhani O. Saarinen <
> [e-mail]>
> *Subject:* Re: [EXTERNAL] Re: [Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> Hi,
>
>
>
> Fielding a couple of the questions at once:
>
>
>
> - The plan is to publish it as an RFC. At the last IETF meeting it was
> decided it would make sense to split it into multiple RFCs (one per
> winner). We are working on the split.
>
> - The split includes a Sphincs+ document. Initially we considered only the
> finalists, but now also added Sphincs+ as it is now a winner.
>
> - Splitting between a seed and the full key is intesting. This might be a
> problem to be fielded in LMS/XMSS as well. Different OIDs seems like it
> would become a long list, but I am not sure whether that is a problem.
>
>
>
> Cheers,
>
>
>
> Christine
>
>
>
> Op wo 28 sep. 2022 om 23:39 schreef Mike Ounsworth <
> [e-mail]>:
>
> > So I’d propose as format either storing the opaque private key (as
> specified by the CRYSTALS team) or the seed.
>
>
>
> I like the idea. What’s the easiest way for a parser trying to read this
> off disk to know the difference between:
>
>
>
>    dilithiumPrivateKey OCTET STRING
>
> and
>
>     dilithiumPrivateKeySeed OCTET STRING
>
> ?
>
>
>
> Different PrivateKeyAlgorithmIdentifier OIDs?
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *From:* Bas Westerbaan <[e-mail]>
> *Sent:* September 28, 2022 4:31 PM
> *To:* Massimo, Jake <[e-mail]>
> *Cc:* Mike Ounsworth <[e-mail]>; John Gray <John.Gray=
> [e-mail]>; [e-mail]; [e-mail]; [e-mail];
> Panos Kampanakis (pkampana) <[e-mail]>; Sean Turner <
> [e-mail]>; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Markku-Juhani O. Saarinen <[e-mail]>
> *Subject:* [EXTERNAL] Re: [Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
>      DilithiumPrivateKey ::= SEQUENCE {
>
>          version                               Version,
>
>          privateKeyAlgorithm      PrivateKeyAlgorithmIdentifier,
>
>          privateKey                        OCTET STRING,
>
>          publicKey                            [0] IMPLICIT
> DilithiumPublicKey OPTIONAL
>
>      }
>
>
>
> PQC private keys are typically rather large and, for many schemes can be
> generated cheaply from a small seed (such as with Dilithium). That’s
> helpful if you store many private keys or are rather constrained in storage.
>
>
>
> So I’d propose as format either storing the opaque private key (as
> specified by the CRYSTALS team) or the seed.
>
>
>
> Best,
>
>
>
>  Bas
>
>
>
>
>
>
>
>
>
>
>
> i.e., the parameters are defined/contained within privateKeyAlgorithm.
> This means we can support the byte array encoding for the private key
> proposed by the algorithm designers in privateKey an OCTET STRING.
>
>
>
> Thoughts?
>
>
>
> Cheers,
>
> Jake
>
>
>
> *From: *Mike Ounsworth <[e-mail]>
> *Date: *Wednesday, 28 September 2022 at 13:26
> *To: *John Gray <John.Gray=[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Cc: *"Massimo, Jake" <[e-mail]>, "Panos Kampanakis (pkampana)"
> <[e-mail]>, Sean Turner <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *RE: [EXTERNAL][Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> My curiosity is about the procedural aspect of draft-uni-qsckeys. Is this
> attached to a working group? Are you indenting to publishing this as an
> RFC, or is this just to bridge prototyping work until NIST publishes real
> standards?
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *From:* Pqc <[e-mail]> *On Behalf Of *John Gray
> *Sent:* September 28, 2022 1:34 PM
> *To:* [e-mail]; [e-mail]; [e-mail]
> *Cc:* Massimo, Jake <[e-mail]>; Panos Kampanakis (pkampana) <
> [e-mail]>; Sean Turner <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* [EXTERNAL] [Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> 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.   😊
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlou-rKXm$>
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlubO7POn$>
>  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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
>
>
>
>    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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
> 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.*
>
>