[Pqc] Re: Review of PQC for Engineers

[Deirdre Connolly <[e-mail]>]

> I added a section, under the types of cryptography, about
“symmetric-based public key cryptography” so that we at least mention
zero-knowledge cryptography and the PICNIC NIST candidate.

Picnic was broken
<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/r7DvnGGSp5s/m/lhlpV3BKBAAJ>
via an attack on its block cipher LowMC. It is no longer a NIST candidate
<https://csrc.nist.gov/Projects/pqc-dig-sig/round-1-additional-signatures>.

On Tue, Jul 23, 2024 at 9:41 PM Mike Ounsworth <Mike.Ounsworth=
[e-mail]> wrote:

> I think this document is great. Ready for WGLC.
>
>
>
> Procedural question: this document refers to a whole ton of internet
> drafts. How is that gonna work when it hits RFC Editor?
>
>
>
>
>
>
>
> I’ve made a BUNCH of comments; it got enough that I decided to just do a
> pull request:
>
> https://github.com/tireddy2/pqc-for-engineers/pull/50
>
> I’ll note here the ones that I think the WG would care about.
>
>
>
>
>
> Introduction
>
>
>
>
>
> I would like to propose definitions for “quantum resistant” and “quantum
> ready”.
>
>
>
> A “quantum ready” system is one that is capable of interacting with peers
> using post-quantum cryptographic protocols.
>
> A “quantum resistant” or “quantum secure” is a system which is fully
> upgraded to use post-quantum cryptography for all internal security
> functions.
>
> To illustrate the difference, consider a device which supports PQC TLS
> ciphersuites, but whose firmware and secure-boot system uses only
> traditional cryptography. Such a system would be considered quantum ready
> but not quantum secure.
>
>
>
> This one I did not put in my PR because I’m not sure con controversial it
> is. I have created this as a github issue:
>
> https://github.com/tireddy2/pqc-for-engineers/issues/49
>
>
>
> We should have a section on quantum side-channel attacks. I am not an
> expert on this. I have written something in a pull request, but it should
> be reviewed.
>
>
>
> I added a section getting people to think about various factors that can
> contribute to the migration time “y”.
>
>
>
> I added a section, under the types of cryptography, about “symmetric-based
> public key cryptography” so that we at least mention zero-knowledge
> cryptography and the PICNIC NIST candidate.
>
>
>
>
>
> Does kemEncaps(pk) return (ss, ct) or (ct, ss)?
>
> I’ve recently had some debate about this. I don’t know if anywhere there
> is an authoritative definition of the KEM API.
>
> The NIST PQC competition C API is (ct, ss), however FIPS 203 and RFC9180
> are (ss, ct). I have updated the draft to the latter.
>
>
>
>
>
>
>
> “Post-Quantum KEMs are inherently interactive Key Exchange (KE) protocols
> because they involve back-and-forth communication to negotiate and
> establish a shared secret key.”
>
>
>
> I think that’s actually incorrect; and contradicts the previous paragraph
> which says “When using Key Encapsulation Mechanisms (KEMs) as the
> underlying primitive, a flow may be non-interactive or authenticated, but
> not both.” There were a few other issues with this section, so I re-worked
> it, and consequently it’s much shorter now 😊
>
>
>
> I updated the discussion of KEM Combiners to reflect recent developments.
>
>
>
>
>
> You had a short description of IND-CCA. I also added a section on Binding.
>
>
>
> Added a reference to the Hale-Connolly non-separability work.
>
> I made plenty of other minor and minor-ish changes in my PR.
>
> https://github.com/tireddy2/pqc-for-engineers/pull/50
>
>
>
>
>
>
>
> Finally, I notice that you only have 4 authors. I have contributed text to
> this document a few times over the years. May I be author please? I took
> the liberty of adding myself.
>
>
>
> - - -
>
> Mike Ounsworth
>
> Software Security Architect
>
> (pronouns: he/him)
>
>
>
>
>
>
> --
> Pqc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>