Given that the likely use case is signing firmware (and software?) updates and (maybe) Root CA certs – we should be OK with smaller-than-2^64 allowed number of faster/smaller signatures.
--
Regards,
Uri
There are two ways to design a system. One is to make is 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/SA1PR09MB8669CC55FD9EF5432F6B9C51E5159%40SA1PR09MB8669.namprd09.prod.outlook.com.
Hi Dustin – do we have figures on how much this would save in terms of key / signature size? If it’s significant, it’s worth considering; if not, then not.
Cheers,
William
From: 'Moody, Dustin (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Wednesday, November 30, 2022 7:28 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [pqc-forum] Request for feedback on possible SPHINCS+ variant
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
--
Dear William, dear all,
You can find the slides of my presentation of SPHINCS+ here:
https://huelsing.net/wordpress/wp-content/uploads/2022/11/20221129_sphincsp_NIST.pdf
Slide 17 shows the signature sizes when reducing the max number of signatures to different values. We also plan to publish a more detailed note on this the coming weeks.
Best wishes,
Andreas
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MN2PR02MB6591F991A260006BEED6B2C2F2149%40MN2PR02MB6591.namprd02.prod.outlook.com.
Thank you!
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/a0ea25da-8a7e-9d8f-e3df-9484627bf980%40huelsing.net.
Hi Dustin,
We would like to confirm that we see value in a version of SPHINCS+ with a lower maximum number of signatures.
The main applications we see are similar to LMS & XMSS, i.e., firmware update and secure boot.
For these use cases
1. Key generation & signing time is not relevant (assuming a single signature for many devices);
2. During the lifetime of systems only relatively few updates are required, certainly less than 2^20.
We acknowledge that for these use cases LMS & XMSS also fit very well, however managing the state on the signer side can be complicated and adds additional risk since this is not typically done with classical algorithms (ECC / RSA).
We think it is useful to have a “small” version of SPHINCS+ to cover the use cases where maintaining such a state is difficult.
Moreover, your email uses the phrase “somewhat smaller” but we think the reduction is very significant.
For example, the “public key + signature” size for Dilithium2 is 3.7 kB, while an instantiation of SPHINCS+ presented by Andreas Hülsing in the NIST workshop was of size ~4 kB.
This provides a PQC digital signature algorithm of similar size, but of much more conservative nature.
This has the additional benefit that combining it with a classical signature might not be necessary, and will accelerate adoption.
Although the above sounds quite positive, we want to note a potential caveat that while a state such as for LMS & XMSS is not necessary, with a lower number of maximum signatures the signing side must be extra careful not to sign too often.
For the above use cases, assuming 1 update a day one could provide updates for ~2800 years and no issues should occur.
However, these assumptions might fail in practice (eg. if keys turn out to be re-used across applications, or per-device signing is used erroneously).
How does NIST or the SPHINCS+ team foresee dealing with this?
If one keeps tracks of the number of signatures, one can argue this is also a state that needs to be maintained, and the advantage over LMS/XMSS disappears.
Are there still any advantages of SPHINCS+ in this case, or is it only useful in scenarios where one does not track the number of signatures?
Kind regards,
NXP PQC team
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of William Whyte
Sent: Thursday, December 1, 2022 2:01 PM
To: Andreas Hülsing <ie...@huelsing.net>; pqc-...@list.nist.gov
Subject: [EXT] RE: [pqc-forum] RE: Request for feedback on possible SPHINCS+ variant
Caution: EXT Email
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR02MB658543E1793C3AF5998C0D1EF2149%40DM6PR02MB6585.namprd02.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AM9PR04MB816172B39772336AF31D4558FF179%40AM9PR04MB8161.eurprd04.prod.outlook.com.
Dear all,
from BSI's point of view a version of SPHINCS+ with a smaller maximum number of signatures would be beneficial to the ecosystem.
Due to the level of common trust in the security of hash-based signatures we see their deployment in (Root-)CA certificates as an important milestone to establish secure PKIs. The stateful hash-based signature schemes impose some hassle due to the state management (which we rate to be manageable for a CA). On the other hand, going for a stateless hash-based signature scheme the current versions of SPHINCS+ might generate issues in a PKI due to the large signatures and hence higher space/bandwidth requirements in comparison to the lattice-based signature schemes. A reduced-number-of-sigs version of SPHINCS+ allowing a certain number of signatures with a security margin (i.e. slow degradation in security after the maximum number of signatures have been reached) would make hash-based signatures more attractive for CA's/PKI's. In certificates, the size of PK+Sig matters, hence it could be comparable to CRYSTALS-Dilithium's space requirements.
The BSI would welcome such versions of SPHINCS+. We would also be in favor of reduced-number-of-sigs variants of SPHINCS+ for the security level 192 (in addition to 128) such that CA's would have the freedom to choose and adjust to their security demands. The benefit of such variants for a 256 security level certainly depends on the specific use case. For a CA we would assume that versions with 2^20 sigs and security margin up to 2^30 as well as 2^30 up to 2^40 would be interesting. For a CA with regular renewals the 2^20 up to 2^30 could be sufficient.
From our point of view such SPHINCS+ variants could also make hash-based signatures more attractive for their actual deployment in end-user OpenPGP / S/MIME-certificates if it is known in advance that 2^20 (or 2^30, respectively) signatures will hardly be reached by the signing entity.
Best
Stavros Kousidis, BSI
--
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/d0b0b53e-9eac-4572-be63-7e283218007cn%40list.nist.gov.
Hi Aymeric,
That sounds interesting! Of course the industry would need it to be a FIPS-approved algorithm. Would you consider submitting a pure FORS variant to the NIST on-ramp?
---
Mike Ounsworth
Software Security Architect, Entrust
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
On Behalf Of Aymeric Genêt
Sent: December 8, 2022 12:18 PM
To: Jade Philipoom <ja...@opentitan.org>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] Re: [pqc-forum] Re: Request for feedback on possible SPHINCS+ variant
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CALX2hLxOigpmX-8XzuSF3dOaxMnR0UMKzqgtFHkREWCXu24iwg%40mail.gmail.com.
Hi Dustin,
We are members of the Uptane Standards group writing in favor of a smaller signatures SPHINC+ variant. The Uptane Standard provides a framework for secure over-the-air automotive updates used throughout the automotive industry. This standard has a need for smaller signatures due to limitations of networking and storage of the electronic control units (ECUs) in automobiles. The standard includes many uses of cryptographic keys, many of which are not used frequently and so can handle a small maximum number of signatures.
Uptane implementations sign metadata about software updates for a few different purposes, and some of these are used infrequently. Some of this software update package metadata is used to direct updates and guarantee timeliness, and keys that sign this metadata are used frequently (many times a day), while other keys, such as those used for the root of trust (a kind of root CA for the system), are only used 3-4 times a year. The keys in this latter category are the most security critical in our Uptane system and would benefit from a smaller SPHINCS variant to help us speed up adoption. As few as 2^10 uses would last more than 200 years for keys only used 4 times a year.
In the automotive space, key size is one of the primary concerns. Key generation and signing is done by the OEMs and Tier1 suppliers, so these operations are done on machines that have access to significant computational resources and hardware security components. On the other hand, any data that is sent to a vehicle has both size and computational overhead issues. So the key size, signature size, and verification requirements are of particular concern.
Thanks,
Marina Moore
Justin Cappos
Ira McDonald
Uptane Standards Group
--
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/a03ba349-82cf-4ac3-b17b-554a0ef89e2fn%40list.nist.gov.
Dear pqc-list,
As mentioned in my talk at the 4th NIST conference, the SPHINCS+
team is interested in feedback regarding a smaller number of max
signatures (as already mentioned in Dustin's mail) and regarding
the SPHINCS+C proposal.
We already saw the feedback so far on the list regarding max
signatures and appreciate it!
The SPHINCS+C proposal can be found at
https://eprint.iacr.org/2022/778
For the reduced max signatures parameters, a short note is
available at https://eprint.iacr.org/2022/1725.
What is especially important for us to learn is if there are
applications that cannot use SPHINCS+ in its current form but
would get enabled by one or the other proposal.
However, we are of course also interested in hearing more about
applications where the reduced costs are not critical but still
helpful.
Moreover, regarding the max signatures proposal, we have the
following questions:
* Is there an interest in this for parameters at a security level
> I? (Right now we mainly looked at level I security)
* What applications would benefit?
* What would be the number of expected signatures?
* Does the reduced size / better speed make a fundamental
difference?
* How important is signature vs verification speed?
Regarding SPHINCS+C we have the following questions:
* What applications would benefit?
* How important is signature vs verification speed?
* How relevant is constant signing time (not be confused with
constant time implementation)
* Does the reduced size / better speed make a fundamental
difference?
Best wishes,
Andreas & the SPHINCS+ team
--
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/SA1PR09MB8669CC55FD9EF5432F6B9C51E5159%40SA1PR09MB8669.namprd09.prod.outlook.com.
On Dec 19, 2022, at 02:48, Andreas Hülsing <ie...@huelsing.net> wrote:
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/dd46337d-2d4d-4ac3-182d-9ad85fb678c4%40huelsing.net.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
If we were to be so bold as to add something to the questionnaire, I’d ask a fifth question:
One way to decrease the size of a signature is to select a parameter set that takes longer to sign. Now, in the range that the ‘S’ Sphincs+ parameters live, you need to increase signing time a lot to shrink the signatures a little; for example, if you were willing to spend 10x as much time to generate a signature, you might be able to shrink the signature 10%. Is this a viable trade-off?
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
Thanks for adding my answer from the conference for reference.
Indeed, we intend to answer such questions if and as we promote MTL mode as a candidate for standardization, for instance in conjunction with submitting an Internet-Draft to IETF.
-- Burt
--
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/33ed4d55-ebf1-4f00-aa6c-ed21750004bfn%40list.nist.gov.