Re: [Pqc] I-D Action: draft-ietf-pquip-pqc-engineers-01.txt

[Ben S3 <[e-mail]>]

Hi Aritra, Tiru, et al.,

Thanks for producing this, as others have said it looks like it'll be a very useful document going forward. Some thoughts below:

[General thoughts]
I think it’s important to make sure the amount of detail included is appropriate for the intended audience. As I understand it, this is intended for people utilising crypt/protocol libraries like OpenSSL, who need to decide which new algorithms to use and when to use them, whereas it is _not_ designed for people writing low-level implementations of post-quantum algorithms. I think it's useful to stick to that and not include excessive information which could bloat the scope of the paper and potentially deter the prospective audience.


[Section 6]
> RSA [RSA] and ECC [RFC6090] can be used for both key encapsulation and signatures, while for post-quantum algorithms, a different algorithm is needed for each. When upgrading protocols, it is important to replace the existing use of classical algorithms with either a PQC key encapsulation method or a PQC signature method, depending on how RSA and/or ECC was previously being used.

I think the language could be tightened up here a bit. ECC isn’t really an algorithm per se, and we can use ECC for both key encapsulation and signatures in the same sense that we can use Module Learning with Errors for both key encapsulation and signatures.
This might make more sense being limited to RSA - perhaps something along the lines of the following:

“These algorithms are not a drop-in replacement for classical asymmetric cryptographic algorithms. For instance, RSA [RSA] can be used as both a key encapsulation method (KEM) and as a signature scheme, whereas there is currently no post-quantum algorithm that can perform both functions. When upgrading protocols, it is important to replace the existing use of classical algorithms with either a PQC KEM or a PQC signature method, depending on how the classical algorithm was previously being used. Additionally, KEMs, as described in Section 10, present a different API than either key agreement or key transport primitives. As a result, they may require protocol-level or application-level changes in order to be incorporated.”


[Section 7.2]
> For example, to provide some context, one would need 20 million noisy qubits to break RSA-2048 in 8 hours [RSA8HRS] or 4099 stable qubits to break it in 10 seconds [RSA10SC].

The reference for the "4099 stable qubits in 10 seconds" figure is a company's blog that doesn't provide any sources to back up that claim. If we want to quote those figures here, it would be good to use a more academic reference that shows their working. Additionally, the standard term in academia is “logical qubit” rather than “stable qubit”, so it might be worth considering changing the terminology.

However, I question whether providing the figures for logical qubits is helpful. Essentially every company creating quantum computers is publishing their sizes in terms of noisy qubits without specifying as such, and not publishing their error rates, and it is unclear how many noisy qubits will be required to build a logical qubit. An engineer might see "4099-qubit quantum computers will break RSA" and become unduly worried, especially with at least one company aiming for a 4000 qubit QC in 2025 (indeed, several journalists have already made this mistake).


[Section 10.3]
> IND-CCA2 [...] prevents the adversary from forging new ciphertexts.

In an IND-CCA2 scheme, given the public key one can always create new ciphertexts, so I’m not sure what’s meant by this.


[Section 11.3]
> Access to a robust floating-point stack in Falcon is essential for accurate, efficient, and secure execution of the mathematical computations involved in the scheme. […]
 
I think the entire paragraph containing this sentence isn’t necessary. I don't think it provides much useful information for the intended audience that isn’t included in the surrounding paragraphs (do we expect everyone using a crypto library to be thinking about the robustness of floating-point support on their architecture?).

> Providing a masked implementation of Falcon also seems impossible, per the authors at the RWPQC 2023 symposium.

This draft doesn't define what a masked implementation is, and I don't think I’d expect the average reader to know. I'd argue that this level of detail is only necessary for low-level crypt library authors, and hence not the primary audience of this paper. You could probably get away with a single sentence along the lines of "Implementors of Falcon will need to be aware that Falcon signing is highly susceptible to side-channel attacks unless constant-time 64-bit floating point operations are used, which is extremely platform-dependent."

> Generally, Dilithium is known for its relatively fast signature generation, while Falcon can provide more efficient signature verification. [...] For further clarity, please refer to the tables in sections Section 12 and Section 13.

Sections 12 and 13 do not provide any info on the runtime of these algorithms. Either that info should be given, or the signposting removed.


[Section 11.5]
I'm a little confused by the title of this section. What is "Sign-Then-Hash"? If this is just comparing using Hash-Then-Sign versus not using it, then maybe the section should just be titled "Hash-Then-Sign".


[Section 15.1]
> Another form of quantum cryptanalysis is 'quantum side-channel' attacks. In such attacks, a device under threat is directly connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantum side-channels.

I assert that quantum side-channel attacks are beyond the scope of what the reader needs to know about.

> Recent attacks on the side-channel implementations using deep learning-based power analysis have also shown that one needs to be cautious while implementing the required PQC algorithms in hardware.

Power analysis is probably also beyond the scope of this paper.


- Ben S


From: tirumal reddy <[e-mail]>
Sent: Wednesday, October 11, 2023 8:24 AM
To: [e-mail]
Subject: Re: [Pqc] I-D Action: draft-ietf-pquip-pqc-engineers-01.txt

This revision https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-01.html, addresses most of the comments from WG.

-Tiru

On Wed, 11 Oct 2023 at 12:49, <[e-mail]<mailto:[e-mail]>> wrote:
Internet-Draft draft-ietf-pquip-pqc-engineers-01.txt is now available. It is a
work item of the Post-Quantum Use In Protocols (PQUIP) WG of the IETF.

   Title:   Post-Quantum Cryptography for Engineers
   Authors: Aritra Banerjee
            Tirumaleswar Reddy
            Dimitrios Schoinianakis
            Timothy Hollebeek
   Name:    draft-ietf-pquip-pqc-engineers-01.txt
   Pages:   37
   Dates:   2023-10-11

Abstract:

   The presence of a Cryptographically Relevant Quantum Computer (CRQC)
   would render state-of-the-art, traditional public-key algorithms
   deployed today obsolete, since the assumptions about the
   intractability of the mathematical problems for these algorithms that
   offer confident levels of security today no longer apply in the
   presence of a CRQC.  This means there is a requirement to update
   protocols and infrastructure to use post-quantum algorithms, which
   are public-key algorithms designed to be secure against CRQCs as well
   as classical computers.  These new public-key algorithms behave
   similarly to previous public key algorithms, however the intractable
   mathematical problems have been carefully chosen so they are hard for
   CRQCs as well as classical computers.  This document explains why
   engineers need to be aware of and understand post-quantum
   cryptography.  It emphasizes the potential impact of CRQCs on current
   cryptographic systems and the need to transition to post-quantum
   algorithms to ensure long-term security.  The most important thing to
   understand is that this transition is not like previous transitions
   from DES to AES or from SHA-1 to SHA-2.  While drop-in replacement
   may be possible in some cases, others will require protocol re-design
   to accommodate significant differences in behavior between the new
   post-quantum algorithms and the classical algorithms that they are
   replacing.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pquip-pqc-engineers-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


--
Pqc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pqc