On Sat, Mar 07, 2026 at 06:57:34AM +0000, John Mattsson wrote: > If you work in industry, the PQC migration is not just a security issue, it’s > also a compliance and business issue. The question is not if, but when you > need to phase out all quantum-vulnerable public-key cryptography.
Well, my perception is that we live in a world where law makers and regulators do often make stupid, buzzword driven decisions, and sometimes these even can and do get corrected. So ,technically speaking i am a lot more interested to understand if/where there are wrong compliance requirements. Instead of just trying to make them happen. Make me know if i am just living in a stupid scenario that can not correct itself or if the compliance and business reasons actually do make sense. First time i had to live through stupid politically pushed wrong technology was about 10 years of ATM in the last century. And yes, it is a lot of fun to make pigs fly, but when i see how much money is now blindly put into these next-gen flying pigs i really like good technical reconfirmation that they really are not flying pigs. > I assume the DevID can be reused after the first bootstrapping for scenarios > such as factory resets and re-provisioning? Today yes. But not necessarily if there is a good reason to not let them. Fundamentally, i just don't see the big risk of someone being able to impersonate a lightbulb because PQ could crack the lightbulbs ECC IDevID. On the other hand, it certainly would make sense to think about a way for secure bootstrap to not have to rely on RSA/ECC to identify a MASA. But instead of moving to PQ certs, maybe check if it's possible to provision a per-pledge symmetric key which then is only known to pledge and MASA. And once the pledge has such a unique symmetric key, to trust a MASA without having to depend on ECC/RSA, that symmetric key can of course also be used instead of a ECC/RSA certificate signature, just need to add some challenge to it to avoid replay attacks.. > NIST is easy, use of RSA and ECC is disallowed after 2035. So ensure that all > RSA and ECC keys in deployments are disabled so they cannot be used beyond > that date... > https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf Sure. But as explained above, dropping the need to rely on RSA/ECC does not necessarily mean to go to PQ asymmetric crypto in all cases. > The EU considers PKI and long-lived devices as high-risk and recommends that, > by 31 December 2030, the PQC transition for high-risk use cases should be > completed. The EU also advises: "It is therefore highly recommended to ensure > that products entering the market with an expected lifetime beyond 2030 > should be upgradable to PQC" > https://ec.europa.eu/newsroom/dae/redirection/document/117507 Sure. I think we're only talking about constrained communication scenarios/pledges here. So which lightbulb is really high risk wrt. impersonation ? Cheers Toerless > Cheers, > John Preuß Mattsson > > From: William Atwood <[email protected]> > Date: Friday, 6 March 2026 at 23:04 > To: Toerless Eckert <[email protected]>, Demi Marie Obenour > <[email protected]> > Cc: John Mattsson <[email protected]>, IOT Operations > <[email protected]>, [email protected] <[email protected]>, Sandra Cespedes > <[email protected]>, Maryam Hatami <[email protected]> > Subject: Re: [Anima] Re: [Iotops] Secure device bootstrapping > > For discussion of the feasibility of using BRSKI in a very constrained > environment (specifically, LoRaWAN), please see M. Hatami, S. Céspedes, > J. Atwood, "A Framework for Secure Autonomic IoT Device Management in > Constrained Networks", in Proceedings of the Applied Networking Research > Workshop 2025, Madrid, Spain, 2025-07-22. > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1145%2F3744200.3744775&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755120393%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xq9uYDXVuDtSW89JfL44FgaEzjIVaTEjfN01k8Gupug%3D&reserved=0<https://doi.org/10.1145/3744200.3744775> > You may also want to look at the associated thesis by M. Hatami, at > Concordia University (visit > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspectrum.concordia.ca%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755132329%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n81d6jm3bwIZjJmcacnebAaN7va2U90W%2FJN%2BTAdPQs0%3D&reserved=0)<https://spectrum.concordia.ca/>. > > This work is focused on defining a framework for, and demonstrating the > feasibility of, establishing a secure management and (user) data path > into constrained devices (using BRSKI and a voucher; see below). It > does not discuss the effect of PQ crypto, but (as is pointed out below) > there is a good likelihood that PQ crypto will not be needed anyway, in > these environments. > > > On 2026-03-06 2:56 p.m., Toerless Eckert wrote: > > Attention This email originates from outside the concordia.ca domain. // Ce > > courriel provient de l'extérieur du domaine de concordia.ca > > > > Adding anima > > > > [ Demi: next time, when you move a thread from one WG/RG to another one, > > please > > include an explicit bread crumb where you came from, so folks in the new > > mailing > > list will know where to look for the origin of the thread. Luckily, IETF > > mail > > archive search was good enough to allow me to find that this all > > originated > > from CFRG thread "Current status of group-action based cryptography". ] > > > > The IETF ANIMA WG standardized secure bootstrap mechanism BRSKI (RFC8995) > > and > > a range of variations do hopefully resolve a good amount of the challenges > > that John lists in his original email appended below. > > > > Yes, the root problem of secure bootstrap "on-site" with minimum amount of > > touch is for who or whatever does the enrolment to have some form of > > credential > > to allow authentication for enrolment by the factory state device. We've > > defined a generic, extensible artefact format for this problem called the > > voucher (RFC8366, -bis currently in WG). It can go all the way down to > > a bearer token, but preferred option is some pledge-manufacturer signed > > owner certificate. Pledge of course has cert of its manufacturer. > > > > Now, i just posted to CFRG the provocative claim that these bootstrap > > protocols themselves likely do not need PG crypto because there is not > > relevant PQ attack vector. Would love that challenge to get some answers - > > either way. > > > > But whether or not PK like ML-KEM is reasonable is not primarily a question > > of bootstrap i think. It is primarily a question whether a device could > > handle through its life cycle the added bitrate of PQ crypto exchanges. > > After all: Why bootstrap devices into PQ crypto material if they can't use > > it afterwards. > > > > Of course there is always some type of constrained environment > > (nodes/devices) > > that will have problem with anything you throw at it. But when it comes to > > current IETF work focus, you probably want to go to DRIP for those with > > the most challenging constraints (messaging to drones often likely via > > bluetooth > > BLE in as few messages as possible). > > > > When it comes to the most common building automation or industrial > > networking > > environments as well as home networks, i think 802.15.4 derived mesh > > networks like ZigBee/Thread are a good reference for low-end wireless. > > These mesh networks typically deliver 256kbps raw or 20kbps end-to-end. > > So i really don't see an issue to bootstrap into PQ. After enrolment, > > these devices then typically only use symmetric keys. > > > > I am not sure what the case of "millions of devices" would be that John > > is referring to. But feel free to ask followup questions. > > > > Cheers > > Toerless > > > > On Fri, Mar 06, 2026 at 03:09:44AM -0500, Demi Marie Obenour wrote: > >> On 3/6/26 02:44, John Mattsson wrote: > >>> 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. > >> > >> This actually leads to a separate problem: how are devices expected to > >> authenticate the control node? This is easy if there is a cloud-based > >> control plane, as the cloud server's authentication keys can be > >> hard-coded. However, requiring a cloud service is undesirable from > >> security, privacy, and reliability perspectives. > >> > >> Otherwise, the device somehow needs to obtain the authentication keys > >> of its owner via an out of band mechanism, which could also be used > >> for bootstrapping. The out of band mechanism could be as simple as > >> the 1-Wire bus, which can be driven by a GPIO. > >> > >> An out of band mechanism is also useful for firmware updates, for > >> which the radio network appears to be way too slow. > >> > >> Are CSIDH derivatives compact enough for frequent ephemeral key > >> exchange? Their keys are still significantly longer than EC keys. > >> > >> As an aside, my understanding is that most OSS development mailing > >> lists prefer avoiding top-posting. Are the norms different here? > >> > >>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsignal.org%2Fdocs%2Fspecifications%2Fmlkembraid%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755140197%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hs5qXy2LUSqVUFtoefP39zpVq2vw3QRzbO3SM3uDxKI%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-spm-lake-pqsuites%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755148052%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3G9LpA2%2BdLuHrqOcxg5KFfm8uj9wTNw1uw%2BgdaMrkE8%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-iotops-security-protocol-comparison%2F09%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755155686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=J5IL2yx3h1Z9UhdpIicnz7eUvM4g4YYg82XXkT4TgMM%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-forum%2Fc%2FNj1c9fWE0S8%2Fm%2Fp8_MPZ6lBAAJ&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755162944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G64y9KOmqBthKwKA%2Fuc1TqQhpTTj5C%2BHjzx3pvBzgE0%3D&reserved=0<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) > >> > >> > >> -- > >> Sincerely, > >> Demi Marie Obenour (she/her/hers) > > > > > > > > > > > > > > -- > Dr. J.W. Atwood, Eng. (retired) > Distinguished Professor Emeritus > Department of Computer Science > and Software Engineering > Concordia University ER 1234 email:[email protected] > 1455 de Maisonneuve Blvd. West > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fusers.encs.concordia.ca%2F~bill&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C27b83296f16a4c1d8ed008de7bcc5869%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639084314755171357%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=omb7OaXeX4IDAsRnIplHwDEJck6SOwmAZTg7n0bC3wU%3D&reserved=0<http://users.encs.concordia.ca/~bill> > Montreal, Quebec Canada H3G 1M8 > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
