[Pqc] Re: [EXTERNAL] Re: Review of PQC for Engineers

[Sofia Celi <[e-mail]>]

Hi, all,

Not speaking as a chair.

I agree with Thom. The post-quantum schemes currently in standarization 
by NIST do not include standarizing general-purpose ZKP or complex ZKP; 
but many signature algorithms are based on the same ideas as building a 
ZKP, and, as Thom notes, some of the PQC ones proposed are internally 
based on self-knowledge proofs. For the time being, I agree that it is 
best to keep out general ZKP from the document.

However, general ZKP does seem of interest to some protocols of the 
IETF. The one that comes immediately to my mind is Privacy Pass, as the 
internal VOPRF does use a ZKP. There has been some advancements on how 
to build general-ZKP from lattices and others, but for the time being, 
research is still busy on this front.

Thank you,

On 25/07/2024 21:08, Thom Wiggers wrote:
> Hi all,
> 
> I think that Mike, through Picnic, wanted to mention general purpose 
> signature schemes that are *internally* based on zero-knowledge proofs. 
> Picnic was broken, but in the NIST call for additional post-quantum 
> signature schemes there are many proposals based on MPC-in-the-head and 
> other “fancy crypto” constructions internally.
> 
> In very real ways, any signature scheme can of course be viewed as a 
> zero-knowledge proof of knowledge of the private key. Dilithium is also 
> based on the Fiat-Shamir construction, which also transforms a proof of 
> knowledge to digital signature scheme.
> 
> So while I agree that ZKPs and other “fancy crypto" probably don’t have 
> a place in this engineering-focused document, we shouldn’t confuse 
> general-purpose ZKP with these ways of constructing signature schemes. 
> Now, whether these “inside the black box" details are relevant to the 
> document is a separate question, but the same argument can be applied to 
> describing lattice details.
> 
> Cheers,
> 
> Thom
> 
>> Op 25 jul 2024, om 21:59 heeft Tim Hollebeek 
>> <tim.hollebeek=[e-mail]> het volgende geschreven:
>>
>> I would leave out ZKP entirely.  It’s a fun topic (one of my 
>> favorites), but IMO totally unnecessary and distracting when trying to 
>> get up to speed on basic PQC issues.
>> We do have to watch for scope creep, and I think trying to keep it 
>> somewhere near the current scope is smart, or we won’t be done for a 
>> few more years.
>> In particular, I also think trying to agree on definitions for terms 
>> the industry has struggled to define for years is probably a non-goal 
>> from my point of view.
>> Remember, we need to publish RFCs, not just start them and work on them!
>> -Tim
>> *From:*Mike Ounsworth <[e-mail]>
>> *Sent:*Wednesday, July 24, 2024 4:27 PM
>> *To:*Deirdre Connolly <[e-mail]>; Mike Ounsworth 
>> <Mike.Ounsworth=[e-mail]>
>> *Cc:*[e-mail]; tirumal reddy <[e-mail]>; Aritra Banerjee 
>> (Nokia) <[e-mail]>; Tim Hollebeek 
>> <[e-mail]>
>> *Subject:*RE: [EXTERNAL] [Pqc] Re: Review of PQC for Engineers
>> Fair enough to not mention Picnic.
>>
>> Do you feel that the whole category of ZKP should or should not be 
>> mentioned? Is there another example to cite, or just have the 
>> descriptive text with no example?
>> ---
>> *Mike*Ounsworth
>> *From:*Deirdre Connolly <[e-mail] 
>> <mailto:[e-mail]>>
>> *Sent:*Wednesday, July 24, 2024 6:17 PM
>> *To:*Mike Ounsworth <Mike.Ounsworth=[e-mail] 
>> <mailto:Mike.Ounsworth=[e-mail]>>
>> *Cc:*[e-mail] <mailto:[e-mail]>; tirumal reddy 
>> <[e-mail] <mailto:[e-mail]>>; Aritra Banerjee 
>> (Nokia) <[e-mail] 
>> <mailto:[e-mail]>>; Tim Hollebeek 
>> <[e-mail] <mailto:[e-mail]>>
>> *Subject:*[EXTERNAL] [Pqc] Re: Review of PQC for Engineers
>> Suggested the mention be removed on GitHub On Wed, Jul 24, 2024 at 4: 
>>  15 PM Deirdre Connolly <durumcrustulum@ gmail. com> wrote: > I added 
>> a section, under the types of cryptography, about “symmetric-based 
>> public key cryptography” so that
>> Suggested the mention be removed onGitHub 
>> <https://urldefense.com/v3/__https:/github.com/tireddy2/pqc-for-engineers/pull/50/files*r1690570148__;Iw!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQGKiZdR_g$>
>> On Wed, Jul 24, 2024 at 4:15 PM Deirdre Connolly 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     > 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 wasbroken
>>     <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/g/pqc-forum/c/r7DvnGGSp5s/m/lhlpV3BKBAAJ__;!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQHLLWru0Q$>via an attack on its block cipher LowMC. It isno longer a NIST candidate <https://urldefense.com/v3/__https:/csrc.nist.gov/Projects/pqc-dig-sig/round-1-additional-signatures__;!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQGWnfjDZw$>.
>>     On Tue, Jul 23, 2024 at 9:41 PM Mike Ounsworth
>>     <Mike.Ounsworth=[e-mail]
>>     <mailto:[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
>>         <https://urldefense.com/v3/__https:/github.com/tireddy2/pqc-for-engineers/pull/50__;!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQE-b4KHJw$>
>>         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
>>         <https://urldefense.com/v3/__https:/github.com/tireddy2/pqc-for-engineers/issues/49__;!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQHz6wdmGA$>
>>         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
>>         <https://urldefense.com/v3/__https:/github.com/tireddy2/pqc-for-engineers/pull/50__;!!FJ-Y8qCqXTj2!ZXr0neoOXGAmx6ms2HVjk7nNjUn36FHY2ASn4Fu33CyfeK-Z00dIvRLwePOLeCuqZhTugFRRTPVYc3pQw1pOQQE-b4KHJw$>
>>         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)
>>
>>         <image001.png>
>>         <image002.png>
>>
>>         --
>>         Pqc mailing list [e-mail] <mailto:[e-mail]>
>>         To unsubscribe send an email [e-mail]
>>         <mailto:[e-mail]>
>>
>> --
>> Pqc mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places.
Reach me out at: [e-mail]
Website: https://sofiaceli.com/