Hi Demi,
The operational aspects are probably better discussed in venues such
as IOTOPS. There are many practical challenges. Bootstrapping during
manufacturing is often too inflexible. Secure on-site bootstrapping
using a relay requires the device to support a second network
technology and requires the installer to carry special equipment and,
in remote locations, a portable Internet connection. Even when it
works, the the devices becomes significantly more expensive and
the installation process becomes slower and more complex, which
significantly increases the cost per installation, and deployments
may involve thousands or even millions of devices.
From a security perspective, using trusted nodes is not
advisable. Many systems are deployed by independent installers,
and giving them access to secret keys significantly increases the
risk of compromise or leakage and may create legal issues. While
ephemeral key exchanges should ideally occur frequently, this
is unlikely to be feasible with ML-KEM. Even a single ML-KEM key
exchange for one device is challenging due to the limited uplink
and extremely constrained downlink capacity. If millions of devices
were to perform frequent ML-KEM exchanges, they would likely exceed
the network capacity. There is typically no “free” space to
piggyback ML-KEM fragments on existing messages. And while 1500
bytes is the additional overhead compared to ECC, implementing
secure and reliable fragmentation over many weeks with new messages
introduces a substantial amount of further overhead. More exact
estimates likely require similation.
On 2026-03-06, 04:52, "Demi Marie Obenour" <[email protected]> wrote:
On 3/5/26 14:28, John Mattsson wrote:
Demi Marie Obenour wrote:
Would it be possible to split the KEM over many messages, with forward
error correction used to ensure that the message eventually arrives?
The key exchange itself would take a very long time, but after setup
(which could be out of band) it would happen concurrently with traffic
already flowing through the network. Is sending 1500 bytes over a
matter of days a reasonable option?
I think it is very good that you explicitly mention that in more constrained
networks this could take days. Many people do not realize this, and it puts the
“seconds of computation” discussion in a completely different light.
An additional challenge in LPWAN networks is that downlink
capacity is typically much smaller than uplink capacity. An
installation process that takes several days would significantly
increase operational costs, since failures would only be detected
much later. While a single device might still be able to complete
bootstrapping over the course of several days, deploying thousands
of devices at scale could become problematic due to limited network
capacity. In such cases, the overall installation process could
stretch into weeks.
Would it be possible to perform bootstrapping out of band over an
unconstrained (or less-constrained) network? This should almost always
be possible because the devices need to be physically placed in their
intended locations. This means the devices need to be physically close
to a trusted party, and the key exchange could happen at this time.
Since the device only needs to communicate over a short distance,
it can use a high-speed network such as Bluetooth or Wi-Fi.
There are at least two ways this can be implemented:
1. Each person deploying a device carries a relay node that has a
high-bandwidth uplink, such as cellular or LEO satellite service.
This is used to proxy traffic from the constrained device back to
its controller.
2. Each person deploying a device carries a trusted node that records
the derived symmetric keys. After they return to base, this node
uploads the (encrypted) symmetric keys to the controller.
Subsequent key exchange is only necessary for forward secrecy, for
which https://signal.org/docs/specifications/mlkembraid/
<45acac64-721b-4904-9c71-686fcd0cef4e> can be used.
Thanks to Deirdre Connolly for mentioning this.
I wonder if they expect these networks to adapt to the changing
cryptographic requirements, rather than the other way around.
I think government agencies sometimes have limited insight into how
cryptography is used in different industries. One practical example I
encountered was a government representative who had worked primarily
with military systems and was very surprised that industry places
significant emphasis on performance and cost.
Another example is the suggestion to limit European industry to
the ECCG ACM list. Such a restriction would be extremely costly for
European industry and, in many cases, reduce security rather than
improve it. More broadly, the focus on cryptographic algorithms is
somewhat misplaced. Implementation bugs, misuse, and poor protocol
design are often much greater sources of security problems than
the algorithms themselves.
I agree. In particular, the low downlink capacity means that
OTA firmware updates are quite difficult, despite being absolutely
critical for security. Unless one is going to formally verify all
firmware that deals with untrusted inputs, there is likely to be at
least one remotely-exploitable vulnerability found.
From what very little I have read, it seems that the main reasons
these networks have such poor throughput are limited radio spectrum
and limited battery size. Both are ultimately under human control:
the first can be changed by regulators, and the second can be changed
by spending more on the product.
Yes, but the total amount of spectrum is fixed and not under human
control. There is very little unused spectrum in the sub-GHz bands
suitable for LPWAN, and expanding spectrum for these networks would
require reducing spectrum available to other services, something
that is rarely practical.
If bootstrapping occurs only once over the device’s 10-year
lifetime, the impact on battery life is likely limited.
I think that key exchange should happen many times so that forward
secrecy is obtained, but the subsequent key exchanges are not
performance critical. OTA firmware updates are much harder.
On 2026-03-05, 10:53, "Demi Marie Obenour" <[email protected]
<4baf4eaa-f9cc-47e6-8f0c-efc0a170e02c>> wrote:
On 3/5/26 02:42, John Mattsson wrote:
Hi,
The large sizes of ML-KEM and the absence of NIKE have been identified as
significant hurdles for constrained radio systems. In secdispatch, Demi Marie
Obenour asked about the current status of CSIDH and group-action–based
cryptography. While I try to keep up with developments, many members of CFRG
undoubtedly have a far more comprehensive understanding of the field.
What is the current state of the art for quantum-resistant group-action–based
NIKEs, and when might this area be ready for standardisation?
Cheers,
John Preuß Mattsson
From: John Mattsson <[email protected]
<c93fc91c-4b2e-459c-ae15-4ca2c8d822fb><mailto:[email protected]
<f6d1f6ee-4e4b-4fe7-9c22-131c935a96bf>>>
Date: Thursday, 5 March 2026 at 08:27
To: Demi Marie Obenour <[email protected] <507852db-f462-45df-9523-3d67b80471e4><mailto:[email protected]
<7166d630-1a9a-43dd-86d5-cc14284455ea>>>, Phillip Hallam-Baker <[email protected]
<d2de2b1c-53f4-4034-a1ab-07f4daa8a952><mailto:[email protected] <9f129067-dd58-4a2f-92d8-ee6819e40fcd>>>, Carlos Aguilar
Melchor <[email protected] <06e9e16f-15fc-473a-8d88-a5363bb5fb6b><mailto:[email protected]
<549ad24b-618a-4796-9b09-8df8c8f8f7e4>>>
Cc: Russ Housley <[email protected] <78a594b5-efd5-4fc3-a69a-1270786e71db><mailto:[email protected]
<77cb8763-6075-4db8-9acc-45296c1cd16c>>>, IETF SecDispatch <[email protected]
<d4317401-e51e-4f46-9c54-601dab18d5ff><mailto:[email protected] <cd37fd42-6ccf-4a01-be4f-59cc0cf039ed>>>
Subject: [Secdispatch] Re: Topic request: Security protocols that optimized for
non-web and PQC
Demi Marie Obenour wrote:
What are some known improvements on CSIDH? Are further improvements believed
possible?
There has been extensive follow-up work on CSIDH and group-action
based cryptography since 2018. Research has focused on improving
software and hardware performance, strengthening implementation
security, refining parameter selection, and developing improved
cryptanalytic attacks. There are literally hundreds of papers.
As far as I know, the general view is that further improvements are
very likely and that new attacks may emerge. I do not believe that
even the trade-offs of Kuperberg’s algorithm is yet sufficiently
well understood.
Are any of these improvements likely to decrease the message sizes?
Right now, it seems that quantum attacks keep increasing them.
Stephen Farrell wrote:
It'd be useful if there were a draft with tables that showed the sizes with pq
algs as well.
The 600-byte absolute difference would still remain and still be
significant if ML-KEM were deployed. However, for many systems,
adding 1,500 bytes of overhead is simply not feasible. Many
constrained radio systems have no option but to continue using ECC,
or revert to symmetric-key-only solutions, with all the associated
limitations. A NIKE with much smaller public keys than ML-KEM would
therefore be a major advantage, even if it requires more computation.
Would it be possible to split the KEM over many messages, with forward
error correction used to ensure that the message eventually arrives?
The key exchange itself would take a very long time, but after setup
(which could be out of band) it would happen concurrently with traffic
already flowing through the network. Is sending 1500 bytes over a
matter of days a reasonable option?
I have asked both NIST and European agencies what they expect
constrained radio systems to do when they forbid ECC in 2030–2035
without getting any answers. I have also heard Scott asking NIST what
they plan as a replacement for the currently specified static-static
modes without gettting any answers.
I wonder if they expect these networks to adapt to the changing
cryptographic requirements, rather than the other way around. Nature
does not owe us secure cryptography with small keys and messages.
It could be that the only option that maintains security is to send
more data.
From what very little I have read, it seems that the main reasons
these networks have such poor throughput are limited radio spectrum
and limited battery size. Both are ultimately under human control:
the first can be changed by regulators, and the second can be changed
by spending more on the product. Neither helps cases like wildlife
trackers, though, as those need to be small and light enough that
they do not disturb the animal they are attached to.
At some point, I would like to see a ramp-on for NIKEs.
I know it isn't an option for constrained devices, but SWOOSH
is a (hopefully) fast option when bandwidth is not a concern.
Cheers,
John Preuß Mattsson
On 2026-03-04, 21:57, "Demi Marie Obenour" <[email protected]
<6b8c2b80-d82a-4a21-992a-8b4e5c7a970b><mailto:[email protected]
<ccebc57f-a951-43a2-a23d-cdfa2830c883>>> wrote:
On 3/4/26 05:04, John Mattsson wrote:
Hi Demi,
The LAKE WG is working on integrating PQC algorithms into EDHOC.
https://datatracker.ietf.org/doc/draft-spm-lake-pqsuites/
<eeccd51d-3824-4c2d-b3bd-eeaf4d2beb2c>
This draft registers ML-KEM cipher suites for EDHOC, which can be used with
both signature and PSK authentication. While EDHOC with ML-KEM-512 is much
larger than EDHOC with ECC, it is still significantly smaller than, for
example, TLS 1.3 with X25519MLKEM768 or ML-KEM-512:
https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/09/
<d82148bd-2a84-4a2b-81af-5bffa0aeaa8c>
For signatures, NIST is making good progress. FN-DSA, MQ, and SQISign are all
considerably smaller than ML-DSA:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Nj1c9fWE0S8/m/p8_MPZ6lBAAJ
<1579b886-25dd-4f54-865e-c058927885ce>
CSIDH and its subsequent improvements do appear to be the only viable option for
quantum-resistant key exchange with much smaller "key shares" than ML-KEM.
Other lattice-based key exchange algorithms do not offer significant improvements and
often comes with some disadvantages compared to ML-KEM. I wish NIST, CFRG, or an
independent crypto competition would place more focus on isogeny-based NIKEs as a
potential candidate for future standardization. They aren’t ready yet, but more focused
efforts could help to make them ready. CSIDH would be a drop-in replacement for ECDH and
EDHOC and could be used for both key exchange and authentication.
What are some known improvements on CSIDH? Are further improvements
believed possible?
Another significant concern with lattice-based and code-based KEMs is
that they are difficult to defend from physical side-channel attacks.
This is because one cannot validate ciphertexts without using the
secret key, so very powerful side-channel-assisted chosen-ciphertext
attacks are possible.
I expect that there are cases where side channel resistance is much
more important than speed or message size. In these cases, I expect
Raccoon to be the obvious choice for signatures. For KEMs, would it
make sense to require that the sender provide a zero-knowledge proof
that the ciphertext was honestly generated? Or are there lattice-based
or code-based KEMs that are easy to protect from physical side-channel
attacks?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
--
Sincerely,
Demi Marie Obenour (she/her/hers)
--
Sincerely,
Demi Marie Obenour (she/her/hers)
