Call for Additional Signatures is released
Moody, Dustin (Fed)
Paul Hoffman
> For certain applications, such as certificate transparency, NIST may also be interested in signature schemes that have short signatures and fast verification.
--Paul Hoffman
Mike Ounsworth
https://crt.sh/cert-populations
That said, I'm also curious why CT was singled out as *the* motivating use-case in Dustin's announcement.
---
Mike Ounsworth
Software Security Architect, Entrust
-----Original Message-----
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Paul Hoffman
Sent: September 6, 2022 4:42 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] Re: [Ext] [pqc-forum] Call for Additional Signatures is released
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
______________________________________________________________________
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/13C6E198-B827-434C-9EF8-1AA8609A8DDD%40icann.org.
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
Paul Hoffman
>
> crt.sh shows that we're in the single-digit-billion certs in the index. If you were to download and integrity-check the entire thing on a regular basis, then I could see short signatures and fast verifications being a big deal.
--Paul Hoffman
Bas Westerbaan
crt.sh shows that we're in the single-digit-billion certs in the index. If you were to download and integrity-check the entire thing on a regular basis, then I could see short signatures and fast verifications being a big deal.
Blumenthal, Uri - 0553 - MITLL
Having a small-signature && fast-verification is crucial for constrained environments (that I’m often dealing with).
I agree that a smaller signature at the cost of slightly larger public key would be a good compromise, at least for my use cases.
Thanks!
--
V/R,
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
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoW%2B2EOTBfcLF0ERATw9GgmkQd-EPJh_-Y0uPnsSatiphA%40mail.gmail.com.
Bo Lin
Sent: Wednesday, September 7, 2022 12:49 pm
To: pqc-forum <pqc-...@list.nist.gov>
Edoardo Persichetti
Best,
Edoardo
On Sep 7, 2022, at 5:42 PM, Bo Lin <crypt...@outlook.com> wrote:
EXTERNAL EMAIL : Exercise caution when responding, opening links, or opening attachments.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/LO2P123MB36612BE22406EE5C8F3385A484419%40LO2P123MB3661.GBRP123.PROD.OUTLOOK.COM.
Sofi Celi
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/489BEB1A-0041-4425-8E76-E845767A88F0%40fau.edu.
@claucece
Cryptographic research and implementation at many places, but specially at Brave
Samuel Lavery
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yixfZfD5Fe8WMzyRNBZJHDnuuhJkEycSKLG3fB3Rt2LFjw%40mail.gmail.com.
Brent Kimberley
Sent: Wednesday, September 7, 2022, 8:54 p.m.
To: Sofi Celi <sofi...@gmail.com>
Cc: Edoardo Persichetti <epersi...@fau.edu>; Bo Lin <crypt...@outlook.com>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; pqc-forum <pqc-...@list.nist.gov>
John Mattsson
Just like IETF, 3GPP has had a lot of discussion about PQC. I expect 3GPP to introduce PQC in their specifications as soon as NIST has released final standards and IETF has published updates to TLS 1.3, IKEv2, X.509, and HPKE. 3GPP relies on IETF standards for almost all use of public key cryptography. 3GPP might mandate support of level 1 or 3 and have high security level 5 as should support. This is what current 3GPP documents mostly do regarding P-256/SHA-256 and P-384/SHA-384. I agree with the CNSA 2.0 statement that Kyber and Dilithium should not be used before there are final NIST standards. I think we need to make sure there are NIST and IETF standards before setting timelines for 5G.
3GPP RAN mostly rely on pre-shared keys for authentication and key exchange. 5G introduces the use of ECIES to encrypt identities over the air and there is 2000 bytes reserved to be able to handle PQC KEMs. HPKE with Kyber would likely be a good choice. There is also work on introducing ECDHE in AKA (see EAP-AKA' FS) to provide forward secrecy and align with zero trust principles. Always assuming breach such as key compromise (e.g., in the sim card supply chain) and minimizing the impact of breach are essential zero-trust principles. This should be a main priority for the next 5G releases. Would be good with NIST help to drive zero trust in 5G RAN.
https://www.ericsson.com/en/blog/2022/4/extensible-authentication-protocol-eap-networks
Non-constrained wireless networks will likely be impacted similarly to wired protocols, but it would be good with more research. For very constrained wireless protocols the situation is dire and Kyber and Dilithium do in many cases not work at all. I have written a position paper to the NIST Fourth PQC Standardization Conference about this that I will submit soon.
Cheers,
John
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/YT1PR01MB418707F08A6A4CD8255F6E11FA409%40YT1PR01MB4187.CANPRD01.PROD.OUTLOOK.COM.
Blumenthal, Uri - 0553 - MITLL
Hi all! I guess, for us designers, it would be great to have a more precise understanding of what are the ballparks and sizes discussed here, with reference for the various use cases, since the terms “large”, “short”, “slightly larger” and similar are very vague.
OK, for you designers: my “constrained” use case prefers
- signatures in ballpark of 1 Kbyte or less,
- public keys for KEM – in ballpark of 1.5 KB or less,
- public keys for signature – within a couple of KB, if over-the-air exchange of intermediate CA certificates required – less than 2 KB.
Performance for signature:
- fast verification is a-must,
- fast signing is preferred,
- fast keygen is not that critical.
Performance for KEM: everything must be fast.
Hope this helps.
TNX
Edoardo Persichetti
Best,
Edoardo
Bas Westerbaan
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/3199409D-8CFA-4CD3-B27A-511BC647ACA0%40fau.edu.
Moody, Dustin (Fed)
As noted in my previous email, "NIST is primarily interested in additional general-purpose signature schemes that are not based on structured lattices." For applications such as DNSSEC, where both public key and signature size are a concern, these schemes would likely be the ones of most interest (in addition to those already selected).
Separately from the interest in general-purpose signature schemes, NIST understands that some applications would benefit from signature sizes that are substantially smaller than those of Dilithium or Falcon even if the schemes had relatively large public key sizes. Certificate transparency happens to be one example that is well known and that is part of a widely-used protocol (HTTP over TLS). As Bas noted, CT involves a small number of public keys that are distributed out-of-band and a large number of signatures (2 or more per initial TLS handshake) that are distributed in-band. There are other applications where accepting (potentially) much larger public keys in exchange for much smaller signatures would be a good tradeoff, but CT is likely the most well known and most widely used one.
We would expect some submissions to target the non-lattice-based general-purpose use case and some to target the small-signature use case. We were not necessarily expecting to receive any submissions that would be good general-purpose signature schemes that also had small signatures and fast verification.
From: pqc-...@list.nist.gov on behalf of Paul Hoffman
Sent: Tuesday, September 6, 2022 5:42 PM
To: pqc-forum
Subject: Re: [Ext] [pqc-forum] Call for Additional Signatures is released
> For certain applications, such as certificate transparency, NIST may also be interested in signature schemes that have short signatures and fast verification.
Can you say more about the motivation here? Are you forcusing on schemes that have possibly-giant keys but short signatures, or are you still hoping for schemes that have a variety of different key/signature size balances? I ask as someone who supports a protocol (DNSSEC) that is concerned with delivering both keys and signatures, so size of each will matter to us.
--Paul Hoffman
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
Blumenthal, Uri - 0553 - MITLL
Does it mean that NIST is not interested in lattice-based schemes?
I have in mind specifically https://eprint.iacr.org/2022/1155.pdf , which IMHO would be nice to see considered for Round 4.
Thanks!
--
V/R,
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
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB86699EFD77C84C6C5902613EE5439%40SA1PR09MB8669.namprd09.prod.outlook.com.
Fx FRT
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/9B454A1B-4533-49A9-A0F9-74CF81F6BEF6%40ll.mit.edu.
Fx FRT
John Mattsson
Hi,
Note that there are much more constrained networks than Uri's use case. The world "constrained" can refer to systems with several orders of magniture difference in capabilities. While constrained devices has gotten quite a lot of attention, the radio is often the most constrained part. To reduce overhead and processing in constrained radio networks, IETF has created several working groups and technologies for constrained networks such as 6lo, 6LoWPAN, 6TiSCH, ACE, CBOR, CoRE (CoAP, OSCORE), COSE, LAKE (EDHOC) ROLL (RPL), and LPWAN (SCHC).
Constrained radio networks are characterized by very small frame sizes on the order of tens of bytes transmitted a few times per day at ultra-low speeds, high latency, and severe duty cycles constraints. The number of different constrained radio network technologies is large and growing. Some examples of constrained network technologies are LoRaWAN, NB-IoT, Sigfox, Wi-SUN FAN, Bluetooth Low Energy, and IEEE 802.15.4. IEEE 802.15.4 is used in Zigbee, ISA100.11a, WirelessHART, MiWi, 6LoWPAN, 6TiSCH, Thread and SNAP. Low Power Wide Area Networks (LPWANs) is a huge and very quickly growing market expected to reach over 1000 billion USD globally by 2027.
To work well in constrained radio networks, the message sizes need to align with the tens of bytes transmitted a few times per day that the networks are designed for. Infrequently sending a few hundred bytes is acceptable in many constrained networks but sending a thousand bytes is not feasible in more constrained networks. Note that static keys often do not need to be sent over constrained links, as they can be provisioned or accessed over non-constrained links. Moreover, signatures can in many cases be replaced by a symmetrical MAC from an Ephemeral-Static or Static-Static key exchange by changing the architecture and protocols, as long as the proving node is online.
As several people asked me offline, here is a copy of the paper we submitted to NIST.
https://drive.google.com/file/d/1Vky_uA8DhJMGM-keHH-ujF23xG6stUXq
Cheers,
John
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/3199409D-8CFA-4CD3-B27A-511BC647ACA0%40fau.edu.
Brent Kimberley
>> Note that static keys..
Please note, an actuary, statistician, or equivalent with operational experience should be involved when making the final determination re risk / contingency-holdback / energy budget / expected operational demand / effective headroom – especially if the systems are life-crit.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/HE1PR0701MB30509C8666E8BABB0DC9B89489449%40HE1PR0701MB3050.eurprd07.prod.outlook.com.
Brent Kimberley
For example bulk electric protection doesn’t permit more than one mal event per 40 years.
Blumenthal, Uri - 0553 - MITLL
Note that there are much more constrained networks than Uri's use case.
Please note that I’ve only listed my use case constraints, fully understanding that there are other more constrained applications.
The world "constrained" can refer to systems with several orders of magniture difference in capabilities. While constrained devices has gotten quite a lot of attention, the radio is often the most constrained part.
Yes.
Constrained radio networks are characterized by very small frame sizes on the order of tens of bytes transmitted a few times per day at ultra-low speeds, high latency, and severe duty cycles constraints. The number of different constrained radio network technologies is large and growing. Some examples of constrained network technologies are LoRaWAN, NB-IoT, Sigfox, Wi-SUN FAN, Bluetooth Low Energy, and IEEE 802.15.4. IEEE 802.15.4 is used in Zigbee, ISA100.11a, WirelessHART, MiWi, 6LoWPAN, 6TiSCH, Thread and SNAP. Low Power Wide Area Networks (LPWANs) is a huge and very quickly growing market expected to reach over 1000 billion USD globally by 2027.
To work well in constrained radio networks, the message sizes need to align with the tens of bytes transmitted a few times per day that the networks are designed for. Infrequently sending a few hundred bytes is acceptable in many constrained networks but sending a thousand bytes is not feasible in more constrained networks.
I concur, and wonder what would be the PQ solution for those.
Note that static keys often do not need to be sent over constrained links, as they can be provisioned or accessed over non-constrained links.
I disagree. In some cases the above is true. In others, like mine – decidedly not so. The only reasonable pre-provisioning in my case is for the known-in-advance CA certs.
I understand that there are others who can pre-provision static keys, in which case McEliece doesn’t sound all that bad. 😉 \
Just don’t start thinking that it’s the “usual” case.
Moreover, signatures can in many cases be replaced by a symmetrical MAC from an Ephemeral-Static or Static-Static key exchange by changing the architecture and protocols, as long as the proving node is online.
Yes. Tradeoff between how much to send, how often, and who to (including how many entities to talk with during this process).
As several people asked me offline, here is a copy of the paper we submitted to NIST.
https://drive.google.com/file/d/1Vky_uA8DhJMGM-keHH-ujF23xG6stUXq
Thank you! Let me read it and get back with questions, if any.
TNX
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/HE1PR0701MB30509C8666E8BABB0DC9B89489449%40HE1PR0701MB3050.eurprd07.prod.outlook.com.