Re: [CFRG] NSA vs. hybrid

Hi Uri,

On Thu, Dec 2, 2021 at 7:55 AM Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> NIST did not invent the finalists – some of them have more than two
> decades of research behind them. Situation looks comparable to that with
> RSA and ECC when those algorithms were brought into standards.
>
>
>
> Thus, I do not support the Hybrid approach.
>
> --
>
> Regards,
>
> Uri
>
>
>
> *There are two ways to design a system. One is to make it so simple there
> are obviously no deficiencies.*
>
> *The other is to make it so complex there are no obvious deficiencies.*
>
> *
>                                                                                                                    -
> C. A. R. Hoare*
>
>
>
>
>
> *From: *CFRG <cfrg-bounces@irtf.org> on behalf of Marek Jankowski <
> mjankowski309@gmail.com>
> *Date: *Thursday, December 2, 2021 at 06:23
> *To: *Dan Brown <danibrown@blackberry.com>
> *Cc: *CFRG <cfrg@irtf.org>, "D. J. Bernstein" <djb@cr.yp.to>
> *Subject: *Re: [CFRG] NSA vs. hybrid
>
>
>
> 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 <danibrown@blackberry.com>
> 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
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

Thanks for sharing. Could you elaborate more on why you do not support the
Hybrid approach? You said "Thus, I do not support the Hybrid approach" but
did not establish a predicate for this conclusion.

Thank you,
Soatok