Re: [CFRG] NSA vs. hybrid

[Marek Jankowski <[e-mail]>]

Joining Dan, I too believe that the vetting of PQC algorithms should
originate in a public process, and that NIST has not yet proven we should
rely on the finalists alone. I find it important that CFRG advise upon
hybridization both in KEMs and signatures, although I don't have a strong
opinion in the composite vs multi-certs debate.
In the same context, I worry that not having a FIPS standard for Ed25519,
the result of FIPS 186-5's publication being delayed, might cause a delay
in adoption of PQ+EC hybrid signatures. CFRG should address this issue and
take a proactive stance towards NIST by engaging in discussions regarding
the publication of FIPS 186-5 as well as PQC and hybrid standards later on.

Best regards,
Marek

On Thu, Nov 18, 2021 at 7:20 PM Dan Brown <[e-mail]> wrote:

> > D. J. Bernstein wrote (on Friday, November 12, 2021 4:28 AM)
> >  ...
> > I would like to see CFRG instead advising integration of ECC into all
> post-
> > quantum deployments for the foreseeable future. There's no reason that
> this
> > advice has to wait for NISTPQC standards.
> > ...
>
> I largely agree with the point above (as some might recall from my past
> CFRG
> messages).
>
> Hybrid cryptography in IETF ought to be encouraged by CFRG. At minimum,
> hybrid
> ought to be an option for sensitive applications (high-value data, needing
> long-term protection), where the cost seems worth the benefit.  As an
> exception, an IETF WG with low-value, short-term data and little budget
> for
> cryptography, might opt for a single non-hybrid PQC algorithm option.
>
> Real-time authentication (e.g., signature-based server authentication in
> TLS),
> might have less risk than other applications (e.g., TLS key exchange),
> because
> new attacks discovered in the future (e.g., relevant quantum computer)
> cannot
> retroactively break today's real-time authentication. Nonetheless, hybrid
> signatures may still be worth the cost?
>
> For certificate structuring, I don't know which is better: (1)
> certificates
> with hybrid-signatures, or (2) multiple certificates with a
> single-algorithm
> signatures (or (3)=(1)+(2)), but CFRG could contribute significantly to a
> recommendation on this issue (e.g. comments already made in this thread).
> Perhaps CFRG should defer this more protocol-specific detail to LAMPS?
>
> Organizationally, NIST and IETF could continue to have some interoperable
> cryptography options, while working independently on non-interoperable
> cryptography options (i.e., hybrid interoperability ;).
>
> Best regards,
>
> Dan
>
> PS. A simplistic cost-benefit approach to choosing hybrid cryptography:
> https://eprint.iacr.org/2021/608
> Better methods ought to be possible.   A discussion on this at
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/OpFVbuMYk8c
>
>
> ----------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>