Update on SP 800-208
5,266 views
Skip to first unread message
Moody, Dustin (Fed)
Nov 8, 2024, 8:18:32 AM11/8/24
to pqc-forum
All,
NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, was published in 2020. We've received feedback from some in industry in regards to the restriction against private key export as laid out in 208. In response, NIST has held
a few public discussions about possible options about how to deal with issue. NIST would like to share our approach for how we plan to revise SP 800-208 that would enable key export, but also mitigate security concerns.
For those interested, NIST will hold a virtual meeting where John Kelsey will outline our path forward. We realize this is short notice, so we will be sure to post slides, and record the talk as well. Thanks,
Dustin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Wednesday, November 13th
Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
Meeting ID: 220 481 575 152
Passcode: vRCadd
Phone conference ID: 505 996 741#
Join on a video conferencing device
Tenant key: 1013...@teams-us.bjn.vc
Video ID: 118 970 311 8
John Mattsson
Nov 9, 2024, 2:43:53 AM11/9/24
to Moody, Dustin (Fed), pqc-forum
>so we will be sure to post slides
If possible it would be good if NIST could share slides before the meeting. That way you can get more insightful feedback during the meeting.
Cloudflare's recent very useful blog post states that:
"A final quirk of stateful hash-based signatures is that their security is bottlenecked on non-repudiation: the listed LMS instance has 192 bits of security against forgery, but only 96 bits against the signer themselves creating a single signature that verifies two different messages."
https://blog.cloudflare.com/another-look-at-pq-signatures/
800-208 states:
"This possibility does not affect the formal security properties of the schemes because it remains the case that only the signer could produce a valid signature on a message."
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf
Just looking at this very quickly I tend to agree with NIST. It seems to me that XMSS and LMS do offer non-repudiation in the sense that the signer cannot deny responsibility for performing any of the signatures. The missing property seems rather to be some exotic message commitment property for signatures. When updating 800-208, I think it would be if NIST clearly states if the SHBS signatures offer non-repudiation (In FIPS 205 it is mentioned in the abstract) and if any exotic property is missing.
Cheers,
John
--
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 visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669DD47DC55BBAC74CD1D4BE55D2%40SA1PR09MB8669.namprd09.prod.outlook.com.
Rune Fiedler
Nov 11, 2024, 7:30:32 AM11/11/24
to John Mattsson, Moody, Dustin (Fed), pqc-forum
Hi,
the notion of "a single signature that verifies two different messages"
is known as *message-bound signatures* (with a game-based definition by
[BCJZ21]), and *non-colliding signatures* (with a definition in the
symbolic model by [JCCS19]). Previously, [SPMS02] used the term
*non-repdudiation* to for the absense of *duplicate signatures*.
While all the aforementioned papers look at stateless signature schemes,
it appears the notion translates directly to stateful signature schemes.
Best regards,
Rune
[BCJZ21] https://eprint.iacr.org/2020/823
[JCCS19] https://eprint.iacr.org/2019/779
[SPMS02] https://doi.org/10.1007/3-540-45708-9_7
Am 09/11/2024 um 08.43 schrieb 'John Mattsson' via pqc-forum:
>>so we will be sure to post slides
>
> If possible it would be good if NIST could share slides before the
> meeting. That way you can get more insightful feedback during the meeting.
>
> Cloudflare's recent very useful blog post states that:
>
> /"A final quirk of stateful hash-based signatures is that their security
>
> /https://blog.cloudflare.com/another-look-at-pq-signatures/ <https://
> blog.cloudflare.com/another-look-at-pq-signatures/>/
>
> 800-208 states:
>
> /"This possibility does not affect the formal security properties of the
>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
> NIST.SP.800-208.pdf <https://nvlpubs.nist.gov/nistpubs/
> SpecialPublications/NIST.SP.800-208.pdf>
> *Date: *Friday, 8 November 2024 at 14:18
> *To: *pqc-forum <pqc-...@list.nist.gov>
> *Subject: *[pqc-forum] Update on SP 800-208
>
> All,
>
> NIST SP 800-208, /Recommendation for Stateful Hash-Based Signature
> Schemes/, was published in 2020. We've received feedback from some in
>
> *_Join the meeting now <https://teams.microsoft.com/l/meetup-
> join/19%3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli%40thread.v2/0?context=%7b%22Tid%22%3a%222ab5d82f-d8fa-4797-a93e-054655c61dec%22%2c%22Oid%22%3a%22dd46ae92-6bb7-47b9-aaf6-07052c29b63a%22%7d>_*
>
> *Dial in by phone*
>
> _+1 443-339-4347,,505996741#_United States, Sherwood Forest
>
> _Find a local number <https://dialin.teams.microsoft.com/292b8cb3-
> df78-4db2-b335-f5296905ed36?id=505996741>_
> _More info <https://dialin.bluejeans.com/teams?
> key=101340915&conf=1189703118&domain=teams-us.bjn.vc>_
> forum+un...@list.nist.gov>.
> SA1PR09MB8669DD47DC55BBAC74CD1D4BE55D2%40SA1PR09MB8669.namprd09.prod.outlook.com <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669DD47DC55BBAC74CD1D4BE55D2%40SA1PR09MB8669.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>.
> forum+un...@list.nist.gov>.
> GVXPR07MB9678CA76722C267E3B7925C6895E2%40GVXPR07MB9678.eurprd07.prod.outlook.com <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB9678CA76722C267E3B7925C6895E2%40GVXPR07MB9678.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>.
the notion of "a single signature that verifies two different messages"
is known as *message-bound signatures* (with a game-based definition by
[BCJZ21]), and *non-colliding signatures* (with a definition in the
symbolic model by [JCCS19]). Previously, [SPMS02] used the term
*non-repdudiation* to for the absense of *duplicate signatures*.
While all the aforementioned papers look at stateless signature schemes,
it appears the notion translates directly to stateful signature schemes.
Best regards,
Rune
[BCJZ21] https://eprint.iacr.org/2020/823
[JCCS19] https://eprint.iacr.org/2019/779
[SPMS02] https://doi.org/10.1007/3-540-45708-9_7
Am 09/11/2024 um 08.43 schrieb 'John Mattsson' via pqc-forum:
>>so we will be sure to post slides
>
> If possible it would be good if NIST could share slides before the
> meeting. That way you can get more insightful feedback during the meeting.
>
> Cloudflare's recent very useful blog post states that:
>
> is bottlenecked on non-repudiation: the listed LMS instance has 192 bits
> of security against forgery, but only 96 bits against the signer
> themselves creating a single signature that verifies two different
> messages."///
> of security against forgery, but only 96 bits against the signer
> themselves creating a single signature that verifies two different
>
> /https://blog.cloudflare.com/another-look-at-pq-signatures/ <https://
> blog.cloudflare.com/another-look-at-pq-signatures/>/
>
> 800-208 states:
>
> /"This possibility does not affect the formal security properties of the
> schemes because it remains the case that only the signer could produce a
> valid signature on a message."/
>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
> NIST.SP.800-208.pdf <https://nvlpubs.nist.gov/nistpubs/
> SpecialPublications/NIST.SP.800-208.pdf>
>
> Just looking at this very quickly I tend to agree with NIST. It seems to
> me that XMSS and LMS do offer non-repudiation in the sense that the
> signer cannot deny responsibility for performing any of the signatures.
> The missing property seems rather to be some exotic message commitment
> property for signatures. When updating 800-208, I think it would be if
> NIST clearly states if the SHBS signatures offer non-repudiation (In
> FIPS 205 it is mentioned in the abstract) and if any exotic property is
> missing.
>
> Cheers,
>
> John
>
> *From: *'Moody, Dustin (Fed)' via pqc-forum <pqc-...@list.nist.gov>
> Just looking at this very quickly I tend to agree with NIST. It seems to
> me that XMSS and LMS do offer non-repudiation in the sense that the
> signer cannot deny responsibility for performing any of the signatures.
> The missing property seems rather to be some exotic message commitment
> property for signatures. When updating 800-208, I think it would be if
> NIST clearly states if the SHBS signatures offer non-repudiation (In
> FIPS 205 it is mentioned in the abstract) and if any exotic property is
> missing.
>
> Cheers,
>
> John
>
> *Date: *Friday, 8 November 2024 at 14:18
> *To: *pqc-forum <pqc-...@list.nist.gov>
> *Subject: *[pqc-forum] Update on SP 800-208
>
> All,
>
> NIST SP 800-208, /Recommendation for Stateful Hash-Based Signature
> Schemes/, was published in 2020. We've received feedback from some in
> industry in regards to the restriction against private key export as
> laid out in 208. In response, NIST has held a few public discussions
> about possible options about how to deal with issue. NIST would like to
> share our approach for how we plan to revise SP 800-208 that would
> enable key export, but also mitigate security concerns.
>
> For those interested, NIST will hold a virtual meeting where John Kelsey
> will outline our path forward. We realize this is short notice, so we
> will be sure to post slides, and record the talk as well. Thanks,
>
> Dustin
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> Date: Wednesday, November 13th
>
> Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
>
> *Microsoft Teams*_Need help? <https://aka.ms/JoinTeamsMeeting?omkt=en-US>_
> laid out in 208. In response, NIST has held a few public discussions
> about possible options about how to deal with issue. NIST would like to
> share our approach for how we plan to revise SP 800-208 that would
> enable key export, but also mitigate security concerns.
>
> For those interested, NIST will hold a virtual meeting where John Kelsey
> will outline our path forward. We realize this is short notice, so we
> will be sure to post slides, and record the talk as well. Thanks,
>
> Dustin
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> Date: Wednesday, November 13th
>
> Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
>
>
> *_Join the meeting now <https://teams.microsoft.com/l/meetup-
> join/19%3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli%40thread.v2/0?context=%7b%22Tid%22%3a%222ab5d82f-d8fa-4797-a93e-054655c61dec%22%2c%22Oid%22%3a%22dd46ae92-6bb7-47b9-aaf6-07052c29b63a%22%7d>_*
>
> Meeting ID: 220 481 575 152
>
> Passcode: vRCadd
>
> ------------------------------------------------------------------------
> Meeting ID: 220 481 575 152
>
> Passcode: vRCadd
>
>
> *Dial in by phone*
>
> _+1 443-339-4347,,505996741#_United States, Sherwood Forest
>
> _Find a local number <https://dialin.teams.microsoft.com/292b8cb3-
> df78-4db2-b335-f5296905ed36?id=505996741>_
>
> Phone conference ID: 505 996 741#
>
> *Join on a video conferencing device*
> Phone conference ID: 505 996 741#
>
> _More info <https://dialin.bluejeans.com/teams?
> key=101340915&conf=1189703118&domain=teams-us.bjn.vc>_
>
> --
> 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 <mailto:pqc-
> --
> 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
> forum+un...@list.nist.gov>.
> SA1PR09MB8669DD47DC55BBAC74CD1D4BE55D2%40SA1PR09MB8669.namprd09.prod.outlook.com <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669DD47DC55BBAC74CD1D4BE55D2%40SA1PR09MB8669.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>.
>
> --
> 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 <mailto:pqc-
> --
> 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
> forum+un...@list.nist.gov>.
> GVXPR07MB9678CA76722C267E3B7925C6895E2%40GVXPR07MB9678.eurprd07.prod.outlook.com <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB9678CA76722C267E3B7925C6895E2%40GVXPR07MB9678.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>.
dustin...@nist.gov
Nov 18, 2024, 9:22:39 AM11/18/24
to pqc-forum, dustin...@nist.gov
All,
We have posted the slides from John Kelsey's presentation on NIST's planned update for SP 800-208:
We also recorded a video of the presentation. If you'd like access, please contact me and I can share the video. NIST plans to have a follow-up meeting for some additional discussion and feedback. Details will be announced when that is set up.
Dustin Moody
NIST
NIST
Sebastien Riou
Nov 18, 2024, 11:09:01 AM11/18/24
to pqc-forum, dustin...@nist.gov, john....@nist.gov
All,
After publishing the RFC draft Hash-based Signatures: State and Backup Management, PQShield continued to think about state and backup management and ultimately came to the conclusion that things would be more robust if we could split the secret key in two parts:
- the stateless part: includes parameters and secret seeds
- the stateful part: the monotonic counter (referred as q in RFC8554 section 5.2)
The stateless part could be then backed up just like any other stateless key, so we would be in known territory here.
The stateful part still requires particular care but since its content is not a secret and its mutation is fully deterministic, we can manage it in new ways.
We describe briefly two of those new ways in the attached file. There are many variations around those ideas. We presented them to some major HSM manufacturers, signing service providers and large OEMs. We received mostly positive feedback however two questions have been consistently raised:
- Is it compliant with CAVP and CMVP ?
- If not, do you plan to approach NIST to make it happen ?
I therefore share it here now that revision of SP800-208 seems imminent.
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov.
Simo Sorce
Nov 18, 2024, 3:04:15 PM11/18/24
to Sebastien Riou, pqc-forum, dustin...@nist.gov, john....@nist.gov
Aren't you increasing the risk of having the "stateless" part reused if
you separate it from the "stateful part"? Sounds like a step in the
wrong direction. The "stateful part" is the most important part of a
stateful system.
The scheme you propose below requires all HSMs to always be online and
reachable therefore each of them is a single point of failure.
The most sensible scheme for distributed HSMs is to partition the
counter space so that no two HSMs ever can use the same "counter", and
accept the loss of part of the space if one of the HSMs is
destructively lost. Allocating small chunks (of M values) at a time to
each HSM would allow to reduce the number of "lost counters" in case of
failure, while allowing individual HSMs to safely perform M signatures
while disconnected during transient networking issues or maintenance
windows. M can be tuned according to use case, to either maximize
throughput/resilience to failure, or maximize use of counter-space.
All that said, now that there is a standardized stateless signature
scheme (SLH-DSA) that has all the good properties of LMS and does not
have critical failure modes when recovering from backup, why bother
with increasing the usability of LMS at all?
Simo.
On Mon, 2024-11-18 at 17:08 +0100, 'Sebastien Riou' via pqc-forum
wrote:
> > > NIST SP 800-208, *Recommendation for Stateful Hash-Based Signature
> > > Schemes*, was published in 2020. We've received feedback from some in
> > > *Join the meeting now
> > > <https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli%40thread.v2/0?context=%7b%22Tid%22%3a%222ab5d82f-d8fa-4797-a93e-054655c61dec%22%2c%22Oid%22%3a%22dd46ae92-6bb7-47b9-aaf6-07052c29b63a%22%7d>*
> > > Dial in by phone
> > > *+1 443-339-4347 <(443)%20339-4347>,,505996741#* United States, Sherwood
> > > Forest
> > > *Find a local number
> > > <https://dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741>*
> > > <https://dialin.bluejeans.com/teams?key=101340915&conf=1189703118&domain=teams-us.bjn.vc>*
> > .
> >
>
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
you separate it from the "stateful part"? Sounds like a step in the
wrong direction. The "stateful part" is the most important part of a
stateful system.
The scheme you propose below requires all HSMs to always be online and
reachable therefore each of them is a single point of failure.
The most sensible scheme for distributed HSMs is to partition the
counter space so that no two HSMs ever can use the same "counter", and
accept the loss of part of the space if one of the HSMs is
destructively lost. Allocating small chunks (of M values) at a time to
each HSM would allow to reduce the number of "lost counters" in case of
failure, while allowing individual HSMs to safely perform M signatures
while disconnected during transient networking issues or maintenance
windows. M can be tuned according to use case, to either maximize
throughput/resilience to failure, or maximize use of counter-space.
All that said, now that there is a standardized stateless signature
scheme (SLH-DSA) that has all the good properties of LMS and does not
have critical failure modes when recovering from backup, why bother
with increasing the usability of LMS at all?
Simo.
On Mon, 2024-11-18 at 17:08 +0100, 'Sebastien Riou' via pqc-forum
wrote:
> All,
>
> After publishing the RFC draft Hash-based Signatures: State and Backup
> Management <https://datatracker.ietf.org/doc/draft-wiggers-hbs-state/>,
>
> After publishing the RFC draft Hash-based Signatures: State and Backup
> > > Schemes*, was published in 2020. We've received feedback from some in
> > > industry in regards to the restriction against private key export as laid
> > > out in 208. In response, NIST has held a few public discussions about
> > > possible options about how to deal with issue. NIST would like to share
> > > our approach for how we plan to revise SP 800-208 that would enable key
> > > export, but also mitigate security concerns.
> > >
> > > For those interested, NIST will hold a virtual meeting where John Kelsey
> > > will outline our path forward. We realize this is short notice, so we will
> > > be sure to post slides, and record the talk as well. Thanks,
> > >
> > > Dustin
> > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > >
> > > Date: Wednesday, November 13th
> > > Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
> > >
> > >
> > > Microsoft Teams *Need help? <https://aka.ms/JoinTeamsMeeting?omkt=en-US>*
> > > out in 208. In response, NIST has held a few public discussions about
> > > possible options about how to deal with issue. NIST would like to share
> > > our approach for how we plan to revise SP 800-208 that would enable key
> > > export, but also mitigate security concerns.
> > >
> > > For those interested, NIST will hold a virtual meeting where John Kelsey
> > > will outline our path forward. We realize this is short notice, so we will
> > > be sure to post slides, and record the talk as well. Thanks,
> > >
> > > Dustin
> > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > >
> > > Date: Wednesday, November 13th
> > > Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
> > >
> > >
> > > *Join the meeting now
> > > <https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli%40thread.v2/0?context=%7b%22Tid%22%3a%222ab5d82f-d8fa-4797-a93e-054655c61dec%22%2c%22Oid%22%3a%22dd46ae92-6bb7-47b9-aaf6-07052c29b63a%22%7d>*
> > > Meeting ID: 220 481 575 152
> > > Passcode: vRCadd
> > > ------------------------------
> > > Passcode: vRCadd
> > > Dial in by phone
> > > *+1 443-339-4347 <(443)%20339-4347>,,505996741#* United States, Sherwood
> > > Forest
> > > *Find a local number
> > > <https://dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741>*
> > > Phone conference ID: 505 996 741#
> > > Join on a video conferencing device
> > > Tenant key: 1013...@teams-us.bjn.vc
> > > Video ID: 118 970 311 8
> > > *More info
> > > Join on a video conferencing device
> > > Tenant key: 1013...@teams-us.bjn.vc
> > > Video ID: 118 970 311 8
> > > <https://dialin.bluejeans.com/teams?key=101340915&conf=1189703118&domain=teams-us.bjn.vc>*
> > >
> > > --
> > 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 visit
> > https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov
> > <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov?utm_medium=email&utm_source=footer>
> > > --
> > 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 visit
> > https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov
> > .
> >
>
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Mike Ounsworth
Nov 18, 2024, 3:27:56 PM11/18/24
to Simo Sorce, Sebastien Riou, pqc-forum, dustin...@nist.gov, john....@nist.gov
I agree with Simo.
A scheme that increases the risk of two independent systems using the same tree with different counters sounds like the worst of all worlds.
That said, an _auditing_ mechanism that allows external tracking of which states have been used, should be fine (you can do this simply by auditing the signatures produced).
> All that said, now that there is a standardized stateless signature
scheme (SLH-DSA) that has all the good properties of LMS and does nothave critical failure modes when recovering from backup, why botherwith increasing the usability of LMS at all?
Yeah, I have the same question. Is anyone actually waiting for a fixed LMS instead of using SLH-DSA?
---
Mike Ounsworth
> PQShield continued to think about state and backup management and> ultimately came to the conclusion that things would be more robust if we> could split the secret key in two parts:> - the stateless part: includes parameters and secret seeds> - the stateful part: the monotonic counter (referred as q in RFC8554> section 5.2)> > The stateless part could be then backed up just like any other stateless> key, so we would be in known territory here.> The stateful part still requires particular care but since its content is> not a secret and its mutation is fully deterministic, we can manage it in> new ways.> > We describe briefly two of those new ways in the attached file. There are> many variations around those ideas. We presented them to some major HSM> manufacturers, signing service providers and large OEMs. We received mostly> positive feedback however two questions have been consistently raised:> - Is it compliant with CAVP and CMVP ?> - If not, do you plan to approach NIST to make it happen ?> > I therefore share it here now that revision of SP800-208 seems imminent.> > Best regards,> > > Sebastien Riou> > Director, Product Security Architecture> > PQShield Ltd> > > > M: +33 782 320 285> > E: sebasti...@pqshield.com
> > > > On Mon, 18 Nov 2024 at 15:22, 'dustin...@nist.gov' via pqc-forum <> pqc-...@list.nist.gov> wrote:
> > > All,> > > > We have posted the slides from John Kelsey's presentation on NIST's> > planned update for SP 800-208:> > > > > > We also recorded a video of the presentation. If you'd like access,> > please contact me and I can share the video. NIST plans to have a> > follow-up meeting for some additional discussion and feedback. Details> > will be announced when that is set up.> > > > Dustin Moody> > NIST> > > > On Friday, November 8, 2024 at 8:18:32 AM UTC-5 dustin...@nist.gov wrote:
> > > > > All,> > > > > > NIST SP 800-208, *Recommendation for Stateful Hash-Based Signature> > > Schemes*, was published in 2020. We've received feedback from some in> > > industry in regards to the restriction against private key export as laid> > > out in 208. In response, NIST has held a few public discussions about> > > possible options about how to deal with issue. NIST would like to share> > > our approach for how we plan to revise SP 800-208 that would enable key> > > export, but also mitigate security concerns.> > > > > > For those interested, NIST will hold a virtual meeting where John Kelsey> > > will outline our path forward. We realize this is short notice, so we will> > > be sure to post slides, and record the talk as well. Thanks,> > > > > > Dustin> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wednesday, November 13th> > > Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)> > > > > > > > > Microsoft Teams *Need help? <https://urldefense.com/v3/__https://aka.ms/JoinTeamsMeeting?omkt=en-US__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n4tndGyc$>*
> > > *Join the meeting now> > > <https://urldefense.com/v3/__https://teams.microsoft.com/l/meetup-join/19*3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli*40thread.v2/0?context=*7b*22Tid*22*3a*222ab5d82f-d8fa-4797-a93e-054655c61dec*22*2c*22Oid*22*3a*22dd46ae92-6bb7-47b9-aaf6-07052c29b63a*22*7d__;JSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n7bvyVNU$>*
> > > Meeting ID: 220 481 575 152> > > Passcode: vRCadd> > > ------------------------------> > > Dial in by phone> > > *+1 443-339-4347 <(443)%20339-4347>,,505996741#* United States, Sherwood> > > Forest> > > *Find a local number> > > Phone conference ID: 505 996 741#> > > Join on a video conferencing device> > > Tenant key: 1013...@teams-us.bjn.vc
> > > Video ID: 118 970 311 8> > > *More info> > > > > > --> > 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 visit> > https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n3uz6872$
> > <https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n5QJX7eO$>
> > .> > > -- Simo SorceDistinguished EngineerRHEL Crypto TeamRed Hat, Inc -- 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.
Jeff Andersen
Nov 18, 2024, 3:30:32 PM11/18/24
to Mike Ounsworth, Simo Sorce, Sebastien Riou, pqc-forum, dustin...@nist.gov, john....@nist.gov
CNSA 2.0 doesn't leave any room for a non-stateful hash-based signature scheme, unfortunately.
--Jeff Andersen
Simo Sorce
Nov 18, 2024, 3:44:09 PM11/18/24
to Jeff Andersen, Mike Ounsworth, Sebastien Riou, pqc-forum, dustin...@nist.gov, john....@nist.gov
CNSA needs to be changed, the recommendations are way far from optimal
and having stateful hash signatures as the only option is just not
something people should accept without question.
(ML-DSA is also allowed but it is unclear whether a hybrid signature
would and using ML-DSA adds a lot more risk compared to Hash-based
signatures so that is not an equivalent option).
Simo.
On Mon, 2024-11-18 at 12:30 -0800, Jeff Andersen wrote:
> CNSA 2.0 doesn't leave any room for a non-stateful hash-based signature
> scheme, unfortunately.
>
> --Jeff Andersen
>
>
> On Mon, Nov 18, 2024 at 12:27 PM 'Mike Ounsworth' via pqc-forum <
> pqc-...@list.nist.gov> wrote:
>
> > I agree with Simo.
> >
> >
> >
> > A scheme that increases the risk of two independent systems using the same
> > tree with different counters sounds like the worst of all worlds.
> >
> >
> >
> > which states have been used, should be fine (you can do this simply by
> > auditing the signatures produced).
> >
> >
> >
> >
> >
> >
> >
> > > All that said, now that there is a standardized stateless signature
> >
> > scheme (SLH-DSA) that has all the good properties of LMS and does not
> >
> > have critical failure modes when recovering from backup, why bother
> >
> > with increasing the usability of LMS at all?
> >
> >
> >
> > Yeah, I have the same question. Is anyone actually waiting for a fixed LMS
> > instead of using SLH-DSA?
> >
> >
> >
> > ---
> >
> > *Mike* Ounsworth
> > auditing the signatures produced).
> >
> >
> >
> >
> >
> >
> >
> > > All that said, now that there is a standardized stateless signature
> >
> > scheme (SLH-DSA) that has all the good properties of LMS and does not
> >
> > have critical failure modes when recovering from backup, why bother
> >
> > with increasing the usability of LMS at all?
> >
> >
> >
> > Yeah, I have the same question. Is anyone actually waiting for a fixed LMS
> > instead of using SLH-DSA?
> >
> >
> >
> > ---
> >
> >
> >
> >
> > *From:* pqc-...@list.nist.gov <pqc-...@list.nist.gov> *On Behalf Of *Simo
> > Sorce
> > *Sent:* Monday, November 18, 2024 2:04 PM
> > *To:* Sebastien Riou <sebasti...@pqshield.com>; pqc-forum <
> > pqc-...@list.nist.gov>
> > *Cc:* dustin...@nist.gov <dustin...@nist.gov>; john....@nist.gov
> > *Subject:* [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
> >
> > > PQShield continued to think about state and backup management and
> >
> > > ultimately came to the conclusion that things would be more robust if we
> >
> > > could split the secret key in two parts:
> >
> > > - the stateless part: includes parameters and secret seeds
> >
> > > - the stateful part: the monotonic counter (referred as q in RFC8554
> >
> > > section 5.2)
> >
> > >
> >
> > > The stateless part could be then backed up just like any other stateless
> >
> > > key, so we would be in known territory here.
> >
> > > The stateful part still requires particular care but since its content is
> >
> > > not a secret and its mutation is fully deterministic, we can manage it in
> >
> > > new ways.
> >
> > >
> >
> > > We describe briefly two of those new ways in the attached file. There are
> >
> > > many variations around those ideas. We presented them to some major HSM
> >
> > > manufacturers, signing service providers and large OEMs. We received mostly
> >
> > > positive feedback however two questions have been consistently raised:
> >
> > > - Is it compliant with CAVP and CMVP ?
> >
> > > - If not, do you plan to approach NIST to make it happen ?
> >
> > >
> >
> > > I therefore share it here now that revision of SP800-208 seems imminent.
> >
> > >
> >
> > > Best regards,
> >
> > >
> >
> > >
> >
> > > Sebastien Riou
> >
> > >
> >
> > > Director, Product Security Architecture
> >
> > >
> >
> > > PQShield Ltd
> >
> > >
> >
> > >
> >
> > >
> >
> > > M: +33 782 320 285
> >
> > >
> >
> > > E: sebasti...@pqshield.com
> >
> > >
> >
> > > W: https://urldefense.com/v3/__http://www.pqshield.com__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n2cRi022$ <https://urldefense.com/v3/__http:/www.pqshield.com__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n2cRi022$>
> > > PQShield continued to think about state and backup management and
> >
> > > ultimately came to the conclusion that things would be more robust if we
> >
> > > could split the secret key in two parts:
> >
> > > - the stateless part: includes parameters and secret seeds
> >
> > > - the stateful part: the monotonic counter (referred as q in RFC8554
> >
> > > section 5.2)
> >
> > >
> >
> > > The stateless part could be then backed up just like any other stateless
> >
> > > key, so we would be in known territory here.
> >
> > > The stateful part still requires particular care but since its content is
> >
> > > not a secret and its mutation is fully deterministic, we can manage it in
> >
> > > new ways.
> >
> > >
> >
> > > We describe briefly two of those new ways in the attached file. There are
> >
> > > many variations around those ideas. We presented them to some major HSM
> >
> > > manufacturers, signing service providers and large OEMs. We received mostly
> >
> > > positive feedback however two questions have been consistently raised:
> >
> > > - Is it compliant with CAVP and CMVP ?
> >
> > > - If not, do you plan to approach NIST to make it happen ?
> >
> > >
> >
> > > I therefore share it here now that revision of SP800-208 seems imminent.
> >
> > >
> >
> > > Best regards,
> >
> > >
> >
> > >
> >
> > > Sebastien Riou
> >
> > >
> >
> > > Director, Product Security Architecture
> >
> > >
> >
> > > PQShield Ltd
> >
> > >
> >
> > >
> >
> > >
> >
> > > M: +33 782 320 285
> >
> > >
> >
> > > E: sebasti...@pqshield.com
> >
> > >
> >
> >
> > >
> >
> > >
> >
> > > On Mon, 18 Nov 2024 at 15:22, 'dustin...@nist.gov' via pqc-forum <
> >
> > > pqc-...@list.nist.gov> wrote:
> >
> > >
> >
> > > > All,
> >
> > > >
> >
> > > > We have posted the slides from John Kelsey's presentation on NIST's
> >
> > > > planned update for SP 800-208:
> >
> > > >
> >
> > > > https://urldefense.com/v3/__https://csrc.nist.gov/Projects/stateful-hash-based-signatures/presentations__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n4Bm9kDa$ <https://urldefense.com/v3/__https:/csrc.nist.gov/Projects/stateful-hash-based-signatures/presentations__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n4Bm9kDa$>
> > >
> >
> > >
> >
> > > On Mon, 18 Nov 2024 at 15:22, 'dustin...@nist.gov' via pqc-forum <
> >
> > > pqc-...@list.nist.gov> wrote:
> >
> > >
> >
> > > > All,
> >
> > > >
> >
> > > > We have posted the slides from John Kelsey's presentation on NIST's
> >
> > > > planned update for SP 800-208:
> >
> > > >
> >
> >
> > > >
> >
> > > > We also recorded a video of the presentation. If you'd like access,
> >
> > > > please contact me and I can share the video. NIST plans to have a
> >
> > > > follow-up meeting for some additional discussion and feedback. Details
> >
> > > > will be announced when that is set up.
> >
> > > >
> >
> > > > Dustin Moody
> >
> > > > NIST
> >
> > > >
> >
> > > > On Friday, November 8, 2024 at 8:18:32 AM UTC-5 dustin...@nist.gov wrote:
> >
> > > >
> >
> > > > > All,
> >
> > > > >
> >
> > > > > NIST SP 800-208, *Recommendation for Stateful Hash-Based Signature
> >
> > > > > Schemes*, was published in 2020. We've received feedback from some in
> >
> > > > > industry in regards to the restriction against private key export as laid
> >
> > > > > out in 208. In response, NIST has held a few public discussions about
> >
> > > > > possible options about how to deal with issue. NIST would like to share
> >
> > > > > our approach for how we plan to revise SP 800-208 that would enable key
> >
> > > > > export, but also mitigate security concerns.
> >
> > > > >
> >
> > > > > For those interested, NIST will hold a virtual meeting where John Kelsey
> >
> > > > > will outline our path forward. We realize this is short notice, so we will
> >
> > > > > be sure to post slides, and record the talk as well. Thanks,
> >
> > > > >
> >
> > > > > Dustin
> >
> > > > >
> >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> >
> > > > >
> >
> > > > > Date: Wednesday, November 13th
> >
> > > > > Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
> >
> > > > >
> >
> > > > >
> >
> > > > > Microsoft Teams *Need help? <https://urldefense.com/v3/__https://aka.ms/JoinTeamsMeeting?omkt=en-US__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n4tndGyc$ <https://urldefense.com/v3/__https:/aka.ms/JoinTeamsMeeting?omkt=en-US__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n4tndGyc$>>*
> > > >
> >
> > > > We also recorded a video of the presentation. If you'd like access,
> >
> > > > please contact me and I can share the video. NIST plans to have a
> >
> > > > follow-up meeting for some additional discussion and feedback. Details
> >
> > > > will be announced when that is set up.
> >
> > > >
> >
> > > > Dustin Moody
> >
> > > > NIST
> >
> > > >
> >
> > > > On Friday, November 8, 2024 at 8:18:32 AM UTC-5 dustin...@nist.gov wrote:
> >
> > > >
> >
> > > > > All,
> >
> > > > >
> >
> > > > > NIST SP 800-208, *Recommendation for Stateful Hash-Based Signature
> >
> > > > > Schemes*, was published in 2020. We've received feedback from some in
> >
> > > > > industry in regards to the restriction against private key export as laid
> >
> > > > > out in 208. In response, NIST has held a few public discussions about
> >
> > > > > possible options about how to deal with issue. NIST would like to share
> >
> > > > > our approach for how we plan to revise SP 800-208 that would enable key
> >
> > > > > export, but also mitigate security concerns.
> >
> > > > >
> >
> > > > > For those interested, NIST will hold a virtual meeting where John Kelsey
> >
> > > > > will outline our path forward. We realize this is short notice, so we will
> >
> > > > > be sure to post slides, and record the talk as well. Thanks,
> >
> > > > >
> >
> > > > > Dustin
> >
> > > > >
> >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> >
> > > > >
> >
> > > > > Date: Wednesday, November 13th
> >
> > > > > Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
> >
> > > > >
> >
> > > > >
> >
> >
> > > > > *Join the meeting now
> >
> > > > > <https://urldefense.com/v3/__https://teams.microsoft.com/l/meetup-join/19*3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli*40thread.v2/0?context=*7b*22Tid*22*3a*222ab5d82f-d8fa-4797-a93e-054655c61dec*22*2c*22Oid*22*3a*22dd46ae92-6bb7-47b9-aaf6-07052c29b63a*22*7d__;JSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n7bvyVNU$ <https://urldefense.com/v3/__https:/teams.microsoft.com/l/meetup-join/19*3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli*40thread.v2/0?context=*7b*22Tid*22*3a*222ab5d82f-d8fa-4797-a93e-054655c61dec*22*2c*22Oid*22*3a*22dd46ae92-6bb7-47b9-aaf6-07052c29b63a*22*7d__;JSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n7bvyVNU$>>*
> >
> > > > > Meeting ID: 220 481 575 152
> >
> > > > > Passcode: vRCadd
> >
> > > > > ------------------------------
> >
> > > > > Dial in by phone
> >
> > > > > *+1 443-339-4347 <(443)%20339-4347> <(443)%20339-4347>,,505996741#* United States, Sherwood
> > > > > Meeting ID: 220 481 575 152
> >
> > > > > Passcode: vRCadd
> >
> > > > > ------------------------------
> >
> > > > > Dial in by phone
> >
> >
> > > > > Forest
> >
> > > > > *Find a local number
> >
> > > > > <https://urldefense.com/v3/__https://dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n2-x3OXN$ <https://urldefense.com/v3/__https:/dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n2-x3OXN$>>*
> > > > > Forest
> >
> > > > > *Find a local number
> >
> >
> > > > > Phone conference ID: 505 996 741#
> >
> > > > > Join on a video conferencing device
> >
> > > > > Tenant key: 1013...@teams-us.bjn.vc
> >
> > > > > Video ID: 118 970 311 8
> >
> > > > > *More info
> >
> > > > > <https://urldefense.com/v3/__https://dialin.bluejeans.com/teams?key=101340915&conf=1189703118&domain=teams-us.bjn.vc__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n80cXMeS$ <https://urldefense.com/v3/__https:/dialin.bluejeans.com/teams?key=101340915&conf=1189703118&domain=teams-us.bjn.vc__;!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n80cXMeS$>>*
> > > > > Phone conference ID: 505 996 741#
> >
> > > > > Join on a video conferencing device
> >
> > > > > Tenant key: 1013...@teams-us.bjn.vc
> >
> > > > > Video ID: 118 970 311 8
> >
> > > > > *More info
> >
> >
> > > > >
> >
> > > > > --
> >
> > > > 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 visit
> >
> > > > https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n3uz6872$ <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n3uz6872$>
> > > > >
> >
> > > > > --
> >
> > > > 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 visit
> >
> >
> > > > <https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n5QJX7eO$ <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n5QJX7eO$>>
> >
> > > > .
> >
> > > >
> >
> > >
> >
> >
> >
> > --
> >
> > Simo Sorce
> >
> > Distinguished Engineer
> >
> > RHEL Crypto Team
> >
> > Red Hat, Inc
> >
> >
> >
> > --
> >
> > 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 visit https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/9203085da154b1e5516ed0b78961af84f19c9c3a.camel*40redhat.com__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n1a7zm9-$ <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/9203085da154b1e5516ed0b78961af84f19c9c3a.camel*40redhat.com__;JQ!!FJ-Y8qCqXTj2!dSjVi585rJE2nH3K9YQ9hjtouT5aZHb1TpWSilbl8ToVT5xv5bRBjXTVWgIkn-Q-TAitxI_-n1a7zm9-$>.
> > > > .
> >
> > > >
> >
> > >
> >
> >
> >
> > --
> >
> > Simo Sorce
> >
> > Distinguished Engineer
> >
> > RHEL Crypto Team
> >
> > Red Hat, Inc
> >
> >
> >
> > --
> >
> > 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.
> >
> >
> > --
> > 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 visit
> > https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739ABEAA4EA999C2956D8769F272%40CH0PR11MB5739.namprd11.prod.outlook.com
> > --
> > 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 visit
> > <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739ABEAA4EA999C2956D8769F272%40CH0PR11MB5739.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer>
Sebastien Riou
Nov 18, 2024, 3:48:47 PM11/18/24
to Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
Hi Simo, All
First of all I would like to say that the concepts described are examples that will hopefully inspire others so that a better SP800-208 can emerge.
Aren't you increasing the risk of having the "stateless" part reused if
you separate it from the "stateful part"?
The stateless part is meant to be reused, up to the maximum value of the stateful part.
The scheme you propose below requires all HSMs to always be online and
reachable therefore each of them is a single point of failure.
The stateless HSMs are backed up and therefore allowed to fail.
In the first concept, the stateful HSMs are duplicated to avoid backup and therefore they are allowed to fail too (just not all at the same time). The arbiter HSM is allowed to fail because it is stateless.
Now if by "single point of failure" you mean that if an HSM fails then the system is not available for the few hours needed to replace it, yes, you are right. We consider it not a problem for code signing applications because signing a release is a low frequency event and a few hours or even one day or two of delay is typically not a big deal. For those who disagree, it is also possible to duplicate the stateless HSM to be able to replace them almost in real time.
The most sensible scheme for distributed HSMs is to partition the
counter space so that no two HSMs ever can use the same "counter", and
accept the loss of part of the space if one of the HSMs is
destructively lost. Allocating small chunks (of M values) at a time to
each HSM would allow to reduce the number of "lost counters" in case of
failure, while allowing individual HSMs to safely perform M signatures
while disconnected during transient networking issues or maintenance
windows. M can be tuned according to use case, to either maximize
throughput/resilience to failure, or maximize use of counter-space.
This is what the second concept (time based) is doing!
All that said, now that there is a standardized stateless signature
scheme (SLH-DSA) that has all the good properties of LMS and does not
have critical failure modes when recovering from backup, why bother
with increasing the usability of LMS at all?
LMS is faster and simpler, considering only the device side. That's the ideal solution for ASICs/MCUs secure boot.
Jeff Andersen
Nov 18, 2024, 3:58:11 PM11/18/24
to Sebastien Riou, Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
CNSA needs to be changed, the recommendations are way far from optimal and having stateful hash signatures as the only option is just not something people should accept without question.
I agree. I've been part of multiple calls with NSA where we've advocated for SLH-DSA to be accepted for the narrow use-case of secure boot, where interoperability is much less of a concern. Unfortunately, thus far NSA has not been receptive to these arguments.
--Jeff Andersen
--
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.
Mike Ounsworth
Nov 18, 2024, 4:01:36 PM11/18/24
to Sebastien Riou, Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
Hi Sebastien,
I see. Your usecase does not need or benefit from parallelism. You are fine with the restriction that only one copy of this key will ever be active at a time (enforced operationally), but you want a solution where one device can fail and the next device can just resume, using some external state synchronization, which could be a clock or a signature audit service, or something.
In that case, I see your point that synchronizing one large but static private key (the tree) and one small but dynamic private key (the counter) is much easier than synchronizing a massive private key object.
---
Mike Ounsworth
--
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.
Watson Ladd
Nov 18, 2024, 5:58:21 PM11/18/24
to Mike Ounsworth, Sebastien Riou, Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
Parallelism is also supportable by chopping bits of the tree off to
work with independently. Conceptually this is what SPHINCS does with
enough pieces to be able to forget the state.
State updates are never going to be high performance and durable with
broad synchronization.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB573934DCFE67126E8AF3E7B09F272%40CH0PR11MB5739.namprd11.prod.outlook.com.
--
Astra mortemque praestare gradatim
work with independently. Conceptually this is what SPHINCS does with
enough pieces to be able to forget the state.
State updates are never going to be high performance and durable with
broad synchronization.
--
Astra mortemque praestare gradatim
Jennifer Linn Trokey
Nov 18, 2024, 6:02:18 PM11/18/24
to Watson Ladd, Mike Ounsworth, Sebastien Riou, Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
Very true....
Sebastien Riou
Nov 19, 2024, 3:39:10 AM11/19/24
to Watson Ladd, Mike Ounsworth, Simo Sorce, pqc-forum, dustin...@nist.gov, john....@nist.gov
In the first concept (Multi Party Counting), the arbiter HSM is there precisely to enforce serialisation of state updates, so yes, parallelism is inherently absent from this concept. That said, the few round trips communication involved in getting a new counter value should be done within a second so several stateless HSMs can be operated almost in parallel if needed.
In the second concept (Time Division), true parallelism can be supported: for example if we want to be able to create 2 signatures in parallel then we assign 2 stateless HSMs to the same time slot and we enforce that one HSM is consuming odd counter values and the other the even values. While this is possible, I am curious why anyone would like to do this. In my view, code signing shall be a rare event. In PQShield, the signing of a release occurs only after a time consuming CI process and, for high security product, a third party security evaluation which takes weeks if not months.
Does someone have a use case for high frequency code signing (with the same key) ?
An LMS key with 32K signatures can support one release a day for 89 years, does someone have a use case where more signatures are needed ? (here I assume that everybody is going to generate a new key for each new product / hardware revision)
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
Stefan-Lukas Gazdag
Nov 19, 2024, 4:35:15 AM11/19/24
to pqc-...@list.nist.gov, Mike Ounsworth, Simo Sorce, dustin...@nist.gov, john....@nist.gov, Sebastien Riou, Watson Ladd
Hi,
regarding the number of signatures for code signing I guess it's hard to make a generic assumption but I think one shouldn't underestimate that number of signatures being made.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I see the point that with proper key management and a code signing environment ajdusted to HBS keys, a rather large HBS key (per product, release, some form of time period, ...) should be good enough for many scenarios of use-cases. But what I want to point out is that with some code signing scenarios out there, there's really lots of signatures being made and introducing HBS keys may either be challenging by meeting the need for the full number of signatures or making major changes to the status-quo of the code signing (policy).
Still I wouldn't consider code signing as high frequency signing, so I'm not sure how performant the signing and key updates got to be.
Kind Regards,
Stefan
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
Stefan-Lu...@genua.de
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
Vorteile: www.genua.de/karriere
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
T +49 89 991950-0, F -999, www.genua.de
Geschäftsführer: Matthias Ochs, Marc Tesch
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Von: 'Sebastien Riou' via pqc-forum <pqc-...@list.nist.gov>
Gesendet: Dienstag, 19. November 2024 09:38:51
An: Watson Ladd
Cc: Mike Ounsworth; Simo Sorce; pqc-forum; dustin...@nist.gov; john....@nist.gov
Betreff: [EXT] Re: [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
In the first concept (Multi Party Counting), the arbiter HSM is there precisely to enforce serialisation of state updates, so yes, parallelism is inherently absent from this concept. That said, the few round trips communication involved in getting a new counter value should be done within a second so several stateless HSMs can be operated almost in parallel if needed.
In the second concept (Time Division), true parallelism can be supported: for example if we want to be able to create 2 signatures in parallel then we assign 2 stateless HSMs to the same time slot and we enforce that one HSM is consuming odd counter values and the other the even values. While this is possible, I am curious why anyone would like to do this. In my view, code signing shall be a rare event. In PQShield, the signing of a release occurs only after a time consuming CI process and, for high security product, a third party security evaluation which takes weeks if not months.
Does someone have a use case for high frequency code signing (with the same key) ?
An LMS key with 32K signatures can support one release a day for 89 years, does someone have a use case where more signatures are needed ? (here I assume that everybody is going to generate a new key for each new product / hardware revision)
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
E: sebasti...@pqshield.com<mailto:sebasti...@pqshield.com>
W: www.pqshield.com<http://www.pqshield.com/>
> E: sebasti...@pqshield.com<mailto:sebasti...@pqshield.com>
>
> W: www.pqshield.com<http://www.pqshield.com>
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
regarding the number of signatures for code signing I guess it's hard to make a generic assumption but I think one shouldn't underestimate that number of signatures being made.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I see the point that with proper key management and a code signing environment ajdusted to HBS keys, a rather large HBS key (per product, release, some form of time period, ...) should be good enough for many scenarios of use-cases. But what I want to point out is that with some code signing scenarios out there, there's really lots of signatures being made and introducing HBS keys may either be challenging by meeting the need for the full number of signatures or making major changes to the status-quo of the code signing (policy).
Still I wouldn't consider code signing as high frequency signing, so I'm not sure how performant the signing and key updates got to be.
Kind Regards,
Stefan
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
Stefan-Lu...@genua.de
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
Vorteile: www.genua.de/karriere
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
T +49 89 991950-0, F -999, www.genua.de
Geschäftsführer: Matthias Ochs, Marc Tesch
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Von: 'Sebastien Riou' via pqc-forum <pqc-...@list.nist.gov>
Gesendet: Dienstag, 19. November 2024 09:38:51
An: Watson Ladd
Cc: Mike Ounsworth; Simo Sorce; pqc-forum; dustin...@nist.gov; john....@nist.gov
Betreff: [EXT] Re: [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
In the first concept (Multi Party Counting), the arbiter HSM is there precisely to enforce serialisation of state updates, so yes, parallelism is inherently absent from this concept. That said, the few round trips communication involved in getting a new counter value should be done within a second so several stateless HSMs can be operated almost in parallel if needed.
In the second concept (Time Division), true parallelism can be supported: for example if we want to be able to create 2 signatures in parallel then we assign 2 stateless HSMs to the same time slot and we enforce that one HSM is consuming odd counter values and the other the even values. While this is possible, I am curious why anyone would like to do this. In my view, code signing shall be a rare event. In PQShield, the signing of a release occurs only after a time consuming CI process and, for high security product, a third party security evaluation which takes weeks if not months.
Does someone have a use case for high frequency code signing (with the same key) ?
An LMS key with 32K signatures can support one release a day for 89 years, does someone have a use case where more signatures are needed ? (here I assume that everybody is going to generate a new key for each new product / hardware revision)
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
W: www.pqshield.com<http://www.pqshield.com/>
>
> W: www.pqshield.com<http://www.pqshield.com>
>
> --
> 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<mailto:pqc-forum%2Bunsu...@list.nist.gov>.
> --
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3BvYoGAkQtw4814n4y7cz50tPs-0Vxgwdyo%3Dh5SRM32g%40mail.gmail.com.
>
> --
> 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<mailto:pqc-forum%2Bunsu...@list.nist.gov>.
>
> --
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB573934DCFE67126E8AF3E7B09F272%40CH0PR11MB5739.namprd11.prod.outlook.com.
--
Astra mortemque praestare gradatim
--
Astra mortemque praestare gradatim
--
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<mailto:pqc-forum+...@list.nist.gov>.
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Sebastien Riou
Nov 19, 2024, 5:08:03 AM11/19/24
to Stefan-Lukas Gazdag, pqc-...@list.nist.gov, Mike Ounsworth, Simo Sorce, dustin...@nist.gov, john....@nist.gov, Watson Ladd
Hi Stefan-Lukas,
Thanks for your feedback, I answer your question with the hope that people with other opinions will reply as well in a detailed manner.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
The best practice here seems clear: use one key per product / major release. The rationale is simple: limit the impact of catastrophic events like the compromission of a key or the loss of a key.
Hence my question if there is anyone having a situation where it is desirable to do otherwise.
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
The best practice seems clear as well: production keys shall be used only for production release, i.e., the binaries which are sent to devices in the field. If a test build is signed with a production key, then it can be used on any device on the planet, that's a recipe for disaster as by definition they are not even tested. Development/test/demo and so on shall be done using test key(s).
About complex systems involving multiple sub-modules signed separately: I hope that the device manufacturer signs the whole as one top level release (after having checked that the specific version of all sub modules actually work together of course, using the release version signed with test key(s)).
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I would like to understand such a use-case. I have discussed the matter at length with a lot of people in the tech industry, often the conversation starts like that but ultimately we end up concluding that there isn't a real need for signing so much so often with a single key. (except with people who disagree on the first two points but by now I can tell you that they are clearly in the minority, like 1 to 20).
In my opinion, there is no point in making a standard to accommodate dangerous use cases or use cases which don't make sense, just to honour the status-quo. Standards often end up being bloated with plenty of features to accommodate various corner cases. Each "real" corner case shall be covered for sure, but if we can avoid the ones which don't make sense, then the standard is much better.
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
Simo Sorce
Nov 19, 2024, 9:06:32 AM11/19/24
to Sebastien Riou, Watson Ladd, Mike Ounsworth, pqc-forum, dustin...@nist.gov, john....@nist.gov
On Tue, 2024-11-19 at 09:38 +0100, Sebastien Riou wrote:
> In the first concept (Multi Party Counting), the arbiter HSM is there
> precisely to enforce serialisation of state updates, so yes, parallelism is
> inherently absent from this concept. That said, the few round trips
> communication involved in getting a new counter value should be done within
> a second so several stateless HSMs can be operated almost in parallel if
> needed.
>
> In the second concept (Time Division), true parallelism can be supported:
> for example if we want to be able to create 2 signatures in parallel then
> we assign 2 stateless HSMs to the same time slot and we enforce that one
> HSM is consuming odd counter values and the other the even values. While
> this is possible, I am curious why anyone would like to do this. In my
> view, code signing shall be a rare event. In PQShield, the signing of a
> release occurs only after a time consuming CI process and, for high
> security product, a third party security evaluation which takes weeks if
> not months.
>
> Does someone have a use case for high frequency code signing (with the same
> key) ?
Some vendors have thousands of packages with hundreds to thousand
> In the first concept (Multi Party Counting), the arbiter HSM is there
> precisely to enforce serialisation of state updates, so yes, parallelism is
> inherently absent from this concept. That said, the few round trips
> communication involved in getting a new counter value should be done within
> a second so several stateless HSMs can be operated almost in parallel if
> needed.
>
> In the second concept (Time Division), true parallelism can be supported:
> for example if we want to be able to create 2 signatures in parallel then
> we assign 2 stateless HSMs to the same time slot and we enforce that one
> HSM is consuming odd counter values and the other the even values. While
> this is possible, I am curious why anyone would like to do this. In my
> view, code signing shall be a rare event. In PQShield, the signing of a
> release occurs only after a time consuming CI process and, for high
> security product, a third party security evaluation which takes weeks if
> not months.
>
> Does someone have a use case for high frequency code signing (with the same
> key) ?
potentially built in a single day. Your use case is tied to a specific
production pipeline you are familiar with but it is not the only way
software is built, and increasingly teams are moving to faster
cadences.
> An LMS key with 32K signatures can support one release a day for 89 years,
> does someone have a use case where more signatures are needed ? (here I
> assume that everybody is going to generate a new key for each new product /
> hardware revision)
day. (we are not really impressed with the prospect of trying to use
something like LMS which is why I think CNSA has a broken selection of
algorithms).
Sebastien Riou
Nov 19, 2024, 10:28:58 AM11/19/24
to Simo Sorce, Watson Ladd, Mike Ounsworth, pqc-forum, dustin...@nist.gov, john....@nist.gov
Hi Simo,
Some vendors have thousands of packages with hundreds to thousand
potentially built in a single day. Your use case is tied to a specific
production pipeline you are familiar with but it is not the only way
software is built, and increasingly teams are moving to faster
cadences.
Indeed, my focus is on ASIC/FPGA/MCU, first stage bootloaders, tiny real time OS. Everything where the firmware image size is in kilobytes and each micro second in the boot time matters. This is where LMS really shines compared to other algorithms (high security devices / root of trust products are also preferably using it due to its simplicity).
For use cases where the device is about to boot a complex OS like Linux, I think LMS is not particularly interesting, I would go for ML-DSA and ECDSA. I guess a lot of your package are multi mega bytes in size, and in that case, the verification time is dominated by the hashing of the image, so the algorithm does not matter much (see the table 2 in https://content.pqshield.com/post-quantum-secure-boot-for-processors-and-fpgas ).
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
Stefan-Lukas Gazdag
Nov 19, 2024, 11:20:33 AM11/19/24
to Sebastien Riou, pqc-...@list.nist.gov, Mike Ounsworth, Simo Sorce, dustin...@nist.gov, john....@nist.gov, Watson Ladd
Dear Sebastien,
thanks for your answer. Just to make sure I'm not being misunderstood as I do see that I should've been clearer / more detailed in what I wrote, here's an attempt for clarification. Most importantly, I'm not saying we should support applying HBS like it was a classical scheme and do everything as we used to.
As of my personal experience in the introduction of XMSS software updates at genua in 2017/2018, the number of actual releases and thus of signatures is relatively small for our use-case, meaning a low frequency for the production key(s). For testing purposes not so much. There's kinds of tests where you can dynamically create or maybe don't even need a test key/signature, but in some cases a test key should/needs be used the way a production key would be used and securely stored. Making sure where in testing a signature is really necessary can reduce the number of signatures quite a lot, that much I do agree.
But (also from what others told me about their code signing) there's test builds - before running tests or after regular testing but not (yet) meant for productive use - where you still want a signature with a test key to be done, because you e. g. don't want an unsigned (or only classically signed) software to exist (especially when this software may leave a restricted dev/test environment for further testing outside these environments), your test/experimental use includes signature verification anyway, etc. Even if you suitably reduce the number of required signatures, but take such builds into account that are meant or suited for installation somewhere (non-productive), for many use-cases the number of signatures is likely more than one per day, though with the approach of one key per major release per purpose (production, production but customized, different means of testing, whatever) an HBS key should likely be good enough (though of course some details depend on how releases are deployed and if you e. g. have to use an old key to introduce a new major release with a new key). But I guess elaborating on this via mailing list might be a bit much. As I'm quite interested in your opinion, may I suggest a conversation off-list, sharing relevant findings via the mailing list afterwards?
I do agree that the effects of problems with the key (as key compromise) should be as limited as possible. I'd like to add key backups to the discussion, meaning several (likely two or few) pub keys are deployed, but only one is the 'active' signing key and the other private key is being stored securely only to be used if something happend to the active key, with the backup key being stored in a secure manner (different HSM, smart card, ...). This approach may not be suitable for use-cases where space is extremely limited, but might be interesting (slightly different approach than 'Distributed Multi-Tree Hash-Based Signatures').
About 'modular' software: I don't think that it is always possible to sign a whole release with all potential modules. There sure are use-cases for that, especially when all modules are delivered within a specific piece of software and e. g. only activated via a license code or a specific device is considered as a whole system, more like firmware signing, secure boot, etc.. But also think of such a kind of software where modules/extensions are provided individually in addtion or of big software projects, where you have lots of packages, that are usually treated as individual 'units'. There a lot of signatures by the production key may be necessary. I think for some use-cases it will hardly scale, whether for a single key or for creating one key per module/package (even considering multi-tree constructions and assigning sub-trees to specific modules). But I'd also be happy if someone proves me wrong. (Of course in some of such use-cases a different PQ algorithm may be suitable instead, also considering SLH-DSA.)
My exemplary questions come from various conversations regarding lived practice in different use-cases out there and you're right, that these (especially in the generic formulation I used) don't necessarily imply sensible or secure usage of keys, while the SP and regulation e. g. via FIPS are importantly of course meant to provide (binding) guidelines and recommondations to ensure the safest possible implementation. Yet, for some use-cases of code signing the transition to HBS can be very demanding and I do wonder about mechanisms that may smoothen the switch in a secure way, not encouraging people to stick with the old way of doing things, but also not hindering them too much, if possible and sensible. I agree standards shouldn't be bloated. But some will surely think about the total number of signatures as well as signatures per time and HBS may not even always be the right answer.
Kind Regards and please excuse the wall of text,
Gesendet: Dienstag, 19. November 2024 11:07:37
An: Stefan-Lukas Gazdag
Cc: pqc-...@list.nist.gov; Mike Ounsworth; Simo Sorce; dustin...@nist.gov; john....@nist.gov; Watson Ladd
Betreff: Re: [EXT] Re: [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
Hi Stefan-Lukas,
Thanks for your feedback, I answer your question with the hope that people with other opinions will reply as well in a detailed manner.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
The best practice here seems clear: use one key per product / major release. The rationale is simple: limit the impact of catastrophic events like the compromission of a key or the loss of a key.
Hence my question if there is anyone having a situation where it is desirable to do otherwise.
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
The best practice seems clear as well: production keys shall be used only for production release, i.e., the binaries which are sent to devices in the field. If a test build is signed with a production key, then it can be used on any device on the planet, that's a recipe for disaster as by definition they are not even tested. Development/test/demo and so on shall be done using test key(s).
About complex systems involving multiple sub-modules signed separately: I hope that the device manufacturer signs the whole as one top level release (after having checked that the specific version of all sub modules actually work together of course, using the release version signed with test key(s)).
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I would like to understand such a use-case. I have discussed the matter at length with a lot of people in the tech industry, often the conversation starts like that but ultimately we end up concluding that there isn't a real need for signing so much so often with a single key. (except with people who disagree on the first two points but by now I can tell you that they are clearly in the minority, like 1 to 20).
In my opinion, there is no point in making a standard to accommodate dangerous use cases or use cases which don't make sense, just to honour the status-quo. Standards often end up being bloated with plenty of features to accommodate various corner cases. Each "real" corner case shall be covered for sure, but if we can avoid the ones which don't make sense, then the standard is much better.
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
E: sebasti...@pqshield.com<mailto:sebasti...@pqshield.com>
W: www.pqshield.com<http://www.pqshield.com/>
On Tue, 19 Nov 2024 at 10:35, Stefan-Lukas Gazdag <stefan-lu...@genua.de<mailto:stefan-lu...@genua.de>> wrote:
Hi,
regarding the number of signatures for code signing I guess it's hard to make a generic assumption but I think one shouldn't underestimate that number of signatures being made.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I see the point that with proper key management and a code signing environment ajdusted to HBS keys, a rather large HBS key (per product, release, some form of time period, ...) should be good enough for many scenarios of use-cases. But what I want to point out is that with some code signing scenarios out there, there's really lots of signatures being made and introducing HBS keys may either be challenging by meeting the need for the full number of signatures or making major changes to the status-quo of the code signing (policy).
Still I wouldn't consider code signing as high frequency signing, so I'm not sure how performant the signing and key updates got to be.
Kind Regards,
Stefan
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
Stefan-Lu...@genua.de<mailto:Stefan-Lu...@genua.de>
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
Vorteile: www.genua.de/karriere<http://www.genua.de/karriere>
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
T +49 89 991950-0, F -999, www.genua.de<http://www.genua.de>
W: www.pqshield.com<http://www.pqshield.com><http://www.pqshield.com/>
> E: sebasti...@pqshield.com<mailto:sebasti...@pqshield.com><mailto:sebasti...@pqshield.com<mailto:sebasti...@pqshield.com>>
>
> W: www.pqshield.com<http://www.pqshield.com><http://www.pqshield.com>
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
thanks for your answer. Just to make sure I'm not being misunderstood as I do see that I should've been clearer / more detailed in what I wrote, here's an attempt for clarification. Most importantly, I'm not saying we should support applying HBS like it was a classical scheme and do everything as we used to.
As of my personal experience in the introduction of XMSS software updates at genua in 2017/2018, the number of actual releases and thus of signatures is relatively small for our use-case, meaning a low frequency for the production key(s). For testing purposes not so much. There's kinds of tests where you can dynamically create or maybe don't even need a test key/signature, but in some cases a test key should/needs be used the way a production key would be used and securely stored. Making sure where in testing a signature is really necessary can reduce the number of signatures quite a lot, that much I do agree.
But (also from what others told me about their code signing) there's test builds - before running tests or after regular testing but not (yet) meant for productive use - where you still want a signature with a test key to be done, because you e. g. don't want an unsigned (or only classically signed) software to exist (especially when this software may leave a restricted dev/test environment for further testing outside these environments), your test/experimental use includes signature verification anyway, etc. Even if you suitably reduce the number of required signatures, but take such builds into account that are meant or suited for installation somewhere (non-productive), for many use-cases the number of signatures is likely more than one per day, though with the approach of one key per major release per purpose (production, production but customized, different means of testing, whatever) an HBS key should likely be good enough (though of course some details depend on how releases are deployed and if you e. g. have to use an old key to introduce a new major release with a new key). But I guess elaborating on this via mailing list might be a bit much. As I'm quite interested in your opinion, may I suggest a conversation off-list, sharing relevant findings via the mailing list afterwards?
I do agree that the effects of problems with the key (as key compromise) should be as limited as possible. I'd like to add key backups to the discussion, meaning several (likely two or few) pub keys are deployed, but only one is the 'active' signing key and the other private key is being stored securely only to be used if something happend to the active key, with the backup key being stored in a secure manner (different HSM, smart card, ...). This approach may not be suitable for use-cases where space is extremely limited, but might be interesting (slightly different approach than 'Distributed Multi-Tree Hash-Based Signatures').
About 'modular' software: I don't think that it is always possible to sign a whole release with all potential modules. There sure are use-cases for that, especially when all modules are delivered within a specific piece of software and e. g. only activated via a license code or a specific device is considered as a whole system, more like firmware signing, secure boot, etc.. But also think of such a kind of software where modules/extensions are provided individually in addtion or of big software projects, where you have lots of packages, that are usually treated as individual 'units'. There a lot of signatures by the production key may be necessary. I think for some use-cases it will hardly scale, whether for a single key or for creating one key per module/package (even considering multi-tree constructions and assigning sub-trees to specific modules). But I'd also be happy if someone proves me wrong. (Of course in some of such use-cases a different PQ algorithm may be suitable instead, also considering SLH-DSA.)
My exemplary questions come from various conversations regarding lived practice in different use-cases out there and you're right, that these (especially in the generic formulation I used) don't necessarily imply sensible or secure usage of keys, while the SP and regulation e. g. via FIPS are importantly of course meant to provide (binding) guidelines and recommondations to ensure the safest possible implementation. Yet, for some use-cases of code signing the transition to HBS can be very demanding and I do wonder about mechanisms that may smoothen the switch in a secure way, not encouraging people to stick with the old way of doing things, but also not hindering them too much, if possible and sensible. I agree standards shouldn't be bloated. But some will surely think about the total number of signatures as well as signatures per time and HBS may not even always be the right answer.
Kind Regards and please excuse the wall of text,
Stefan
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
Stefan-Lu...@genua.de
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
Vorteile: www.genua.de/karriere
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
T +49 89 991950-0, F -999, www.genua.de
Geschäftsführer: Matthias Ochs, Marc Tesch
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Von: Sebastien Riou <sebasti...@pqshield.com>
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
Stefan-Lu...@genua.de
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
Vorteile: www.genua.de/karriere
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
T +49 89 991950-0, F -999, www.genua.de
Geschäftsführer: Matthias Ochs, Marc Tesch
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Gesendet: Dienstag, 19. November 2024 11:07:37
An: Stefan-Lukas Gazdag
Cc: pqc-...@list.nist.gov; Mike Ounsworth; Simo Sorce; dustin...@nist.gov; john....@nist.gov; Watson Ladd
Betreff: Re: [EXT] Re: [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
Hi Stefan-Lukas,
Thanks for your feedback, I answer your question with the hope that people with other opinions will reply as well in a detailed manner.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
The best practice here seems clear: use one key per product / major release. The rationale is simple: limit the impact of catastrophic events like the compromission of a key or the loss of a key.
Hence my question if there is anyone having a situation where it is desirable to do otherwise.
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
The best practice seems clear as well: production keys shall be used only for production release, i.e., the binaries which are sent to devices in the field. If a test build is signed with a production key, then it can be used on any device on the planet, that's a recipe for disaster as by definition they are not even tested. Development/test/demo and so on shall be done using test key(s).
About complex systems involving multiple sub-modules signed separately: I hope that the device manufacturer signs the whole as one top level release (after having checked that the specific version of all sub modules actually work together of course, using the release version signed with test key(s)).
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I would like to understand such a use-case. I have discussed the matter at length with a lot of people in the tech industry, often the conversation starts like that but ultimately we end up concluding that there isn't a real need for signing so much so often with a single key. (except with people who disagree on the first two points but by now I can tell you that they are clearly in the minority, like 1 to 20).
In my opinion, there is no point in making a standard to accommodate dangerous use cases or use cases which don't make sense, just to honour the status-quo. Standards often end up being bloated with plenty of features to accommodate various corner cases. Each "real" corner case shall be covered for sure, but if we can avoid the ones which don't make sense, then the standard is much better.
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
W: www.pqshield.com<http://www.pqshield.com/>
On Tue, 19 Nov 2024 at 10:35, Stefan-Lukas Gazdag <stefan-lu...@genua.de<mailto:stefan-lu...@genua.de>> wrote:
Hi,
regarding the number of signatures for code signing I guess it's hard to make a generic assumption but I think one shouldn't underestimate that number of signatures being made.
Does a company use one key for all or at least several products? Or is it actually one key per product / major release?
Is only the final release being signed? Or each developer's build, test builds, nightly builds, artifacts in a CI/CD pipeline and so on? Is the code signing itself being tested regularly? How about some kind of (sub-) modules for the software with the basic release and each module being signed separately?
For some use-cases of code signing depending on how complex the build / test infrastructure is, this may mean hundreds of signatures per day which may exhaust an HBS key sooner than one would expect. And for the classical code signing with RSA or (EC)DSA this was managable.
I see the point that with proper key management and a code signing environment ajdusted to HBS keys, a rather large HBS key (per product, release, some form of time period, ...) should be good enough for many scenarios of use-cases. But what I want to point out is that with some code signing scenarios out there, there's really lots of signatures being made and introducing HBS keys may either be challenging by meeting the need for the full number of signatures or making major changes to the status-quo of the code signing (policy).
Still I wouldn't consider code signing as high frequency signing, so I'm not sure how performant the signing and key updates got to be.
Kind Regards,
Stefan
--
Stefan-Lukas GAZDAG
Research
T +49 89 991950-272
genua bietet Professionals und Berufsstartern an fünf
Standorten spannende Perspektiven und zahlreiche
genua GmbH
Domagkstraße 7, 85551 Kirchheim bei München
Geschäftsführer: Matthias Ochs, Marc Tesch
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Von: 'Sebastien Riou' via pqc-forum <pqc-...@list.nist.gov<mailto:pqc-...@list.nist.gov>>
Amtsgericht München HRB 98238
genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
________________________________________
Gesendet: Dienstag, 19. November 2024 09:38:51
An: Watson Ladd
Cc: Mike Ounsworth; Simo Sorce; pqc-forum; dustin...@nist.gov<mailto:dustin...@nist.gov>; john....@nist.gov<mailto:john....@nist.gov>
An: Watson Ladd
Betreff: [EXT] Re: [EXTERNAL] Re: [pqc-forum] Re: Update on SP 800-208
In the first concept (Multi Party Counting), the arbiter HSM is there precisely to enforce serialisation of state updates, so yes, parallelism is inherently absent from this concept. That said, the few round trips communication involved in getting a new counter value should be done within a second so several stateless HSMs can be operated almost in parallel if needed.
In the second concept (Time Division), true parallelism can be supported: for example if we want to be able to create 2 signatures in parallel then we assign 2 stateless HSMs to the same time slot and we enforce that one HSM is consuming odd counter values and the other the even values. While this is possible, I am curious why anyone would like to do this. In my view, code signing shall be a rare event. In PQShield, the signing of a release occurs only after a time consuming CI process and, for high security product, a third party security evaluation which takes weeks if not months.
Does someone have a use case for high frequency code signing (with the same key) ?
An LMS key with 32K signatures can support one release a day for 89 years, does someone have a use case where more signatures are needed ? (here I assume that everybody is going to generate a new key for each new product / hardware revision)
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
E: sebasti...@pqshield.com<mailto:sebasti...@pqshield.com><mailto:sebasti...@pqshield.com<mailto:sebasti...@pqshield.com>>
In the first concept (Multi Party Counting), the arbiter HSM is there precisely to enforce serialisation of state updates, so yes, parallelism is inherently absent from this concept. That said, the few round trips communication involved in getting a new counter value should be done within a second so several stateless HSMs can be operated almost in parallel if needed.
In the second concept (Time Division), true parallelism can be supported: for example if we want to be able to create 2 signatures in parallel then we assign 2 stateless HSMs to the same time slot and we enforce that one HSM is consuming odd counter values and the other the even values. While this is possible, I am curious why anyone would like to do this. In my view, code signing shall be a rare event. In PQShield, the signing of a release occurs only after a time consuming CI process and, for high security product, a third party security evaluation which takes weeks if not months.
Does someone have a use case for high frequency code signing (with the same key) ?
An LMS key with 32K signatures can support one release a day for 89 years, does someone have a use case where more signatures are needed ? (here I assume that everybody is going to generate a new key for each new product / hardware revision)
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
W: www.pqshield.com<http://www.pqshield.com><http://www.pqshield.com/>
>
> W: www.pqshield.com<http://www.pqshield.com><http://www.pqshield.com>
>
> --
> 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<mailto:pqc-forum%2Bunsu...@list.nist.gov><mailto:pqc-forum%2Bunsu...@list.nist.gov<mailto:pqc-forum%252Buns...@list.nist.gov>>.
> --
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3BvYoGAkQtw4814n4y7cz50tPs-0Vxgwdyo%3Dh5SRM32g%40mail.gmail.com.
>
> --
> 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<mailto:pqc-forum%2Bunsu...@list.nist.gov><mailto:pqc-forum%2Bunsu...@list.nist.gov<mailto:pqc-forum%252Buns...@list.nist.gov>>.
>
> --
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB573934DCFE67126E8AF3E7B09F272%40CH0PR11MB5739.namprd11.prod.outlook.com.
--
Astra mortemque praestare gradatim
--
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<mailto:pqc-forum%2Bunsu...@list.nist.gov><mailto:pqc-forum+...@list.nist.gov<mailto:pqc-forum%2Bunsu...@list.nist.gov>>.
--
Astra mortemque praestare gradatim
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M3cHCZeZBSkOXQUkRJ0-c3EGRyaMv1-7hDvgrDkXzYwcA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Jim Goodman
Nov 21, 2024, 4:08:17 PM11/21/24
to dustin...@nist.gov, pqc-forum
Hi Dustin and team,
First of all, we’d like to thank you for listening to the feedback from
the industry, and for the presentation last week on this topic. Crypto4A
would be happy to contribute to this discussion, and collaborate on
defining an appropriate private key format that incorporates the additional
information required to implement “Scheme #2” of John’s presentation. We
have a format that we’ve been using extensively for 6+ years that we think
will work well for this purpose, and which we’re happy to share with the
rest of the community.
At Crypto4A, we’ve been using HSS as a way to secure our HSMs (e.g., FW
signing, attestation, etc.) since 2018 and we use a concept we refer to
as sectorization which appears to be the same as “Scheme #2” in the
presentation slides. It is based on, and is essentially an instantiation
of, the reservation systems described in section 5 of McGrew et. al.’s
original HBS state-management paper. In our scheme, the private key is
divided into 2d sectors that each cover a mutually exclusive set of OTS
keys, and there is a separate step to “provision” each sector that is
required prior to signing. Fundamentally, establishing a distinction
between the “setup” and the “provision” steps decouples the state management
problem from the operational signing considerations. This has many
advantages, including the ability to perform concurrent signing operations,
scale the performance, provide resilience against disasters, have geo-
redundancy, etc.
We agree with all of the requirements and constraints you’ve outlined in
your presentation. However, we have gathered a few additional requirements
both from our own use of the method, as well as many interactions with
various parties in the industry. In order to reference them more easily
later on, here is a summary of all the requirements gathered so far (“N”
refers to requirements outlined by NIST, and “C” refers to additional
requirements we would like to add):
- N1: Must be able to recover from device failure.
- N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
- N3: Must allow for keys to move from one vendor to another.
- N4: Must minimize the changes to SP800-208.
- N5: Should avoid using patents.
- N6: Signatures must be performed within an HSM.
- C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
- C2: Must be compatible and compliant with CNSA 2.0.
- C3: Must support air-gapped/offline deployments.
- C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
- C5: Should minimize the cost of ownership.
- C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
- C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
- C5c: Should require a minimal level of expertise to maintain.
- C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
- C5e: Should allow for manual/procedural or fully automated support for state management.
As an HSM vendor, we strive to offer solutions that work for as many use
cases as possible (i.e. crypto-agility by design) while understanding that
different sets of constraints may apply based on the specific circumstances.
When it comes to scheme #2, we believe that the responses to the
questions at the end of John’s presentations are as follows:
- Is there some reason this won’t work?
- We have been using scheme #2 very successfully for over 6 years for our own manufacturing processes and it works.
- How hard will these be to allow in SP800-208?
- We would suggest that only a few changes to SP800-208 are necessary to accommodate scheme #2. They are as follows:
- The private key format for export must be extended to include the additional information (i.e., Merkle tree path data of upper d levels), and should be standardized to promote HSM interoperability and prevent vendor lock-in.
- The requirement in section 6.1 of SP800-208 on LMS key generation that dictates that “the same SEED value shall be used to generate every private element in a single LMS instance” must be relaxed to allow for the generation of sectors that cover a mutually exclusive set of OTS keys. We would not be averse to allowing these sector seeds to be generated from a root/master seed using a suitable one-way PRNG, provided that root/master seed is destroyed upon completion of the generation of the sector seeds.
- The requirement in section 8.1 of SP800-208 that dictates that “the cryptographic module shall not allow for the export of private keying material” should be relaxed as was described in the meeting on November 13.
- Will these meet industry needs?
- We believe so based on our interactions with companies and customers who have elected to utilize S-HBS.
Take care, and thank you once again for continuing this discussion within the
PQC community!
Jim and the rest of the Crypto4A team
From: 'dustin...@nist.gov' via pqc-forum <pqc-...@list.nist.gov>
Sent: November 18, 2024 9:23 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: dustin...@nist.gov <dustin...@nist.gov>
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov.
Mike Ounsworth
Nov 21, 2024, 4:33:01 PM11/21/24
to Jim Goodman, dustin...@nist.gov, pqc-forum
Thanks Jim. Well worded. At a first glance, I see no problems with your proposed technical content.
This is a nit, but for:
“C5c: Should require a minimal level of expertise to maintain.”
I think here you mean “maintain” as in “requires minimal expertise to operate because the HSM hides all the complexity” and not “requires minimal expertise for an HSM vendor to implement the sectorization algorithm”?
I suggest instead: “C5c: Should require a minimal level of expertise to initially configure and operate over time a crypto module operating in this mode”.
Also, can you please comment specifically on:
“N5: Should avoid using patents.”
Can you please comment directly on whether Crypto4A holds or is aware of any patents around your sectorization method?
---
Mike Ounsworth
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59%2476e003b0%2464a00b10%24%40crypto4a.com.
Jeff Andersen
Nov 21, 2024, 4:56:02 PM11/21/24
to Mike Ounsworth, Jim Goodman, dustin...@nist.gov, pqc-forum
Jim, a comment on one of your suggestions. You write:
The requirement in section 6.1 of SP800-208 on LMS key generation that dictates that “the same SEED value shall be used to generate every private element in a single LMS instance” must be relaxed to allow for the generation of sectors that cover a mutually exclusive set of OTS keys. We would not be averse to allowing these sector seeds to be generated from a root/master seed using a suitable one-way PRNG, provided that root/master seed is destroyed upon completion of the generation of the sector seeds.
It would be useful to allow different sectors to be generated and managed by different HSMs. In that scenario, no coordination of the seed value should be necessary between HSMs; each HSM should be able to generate its own seed, associated with the portion of the counter space managed by that HSM.
--Jeff Andersen
Jim Goodman
Nov 21, 2024, 9:24:38 PM11/21/24
to Mike Ounsworth, dustin...@nist.gov, pqc-forum
Hi Mike,
Thanks for your excellent feedback! Please
see my responses inline below in red.
Take care.
Jim
From: Mike Ounsworth <Mike.Ou...@entrust.com>
Sent: November 21, 2024 4:33 PM
To: Jim Goodman <ji...@crypto4a.com>; 'dustin...@nist.gov' <dustin...@nist.gov>; 'pqc-forum' <pqc-...@list.nist.gov>
Subject: RE: [EXTERNAL] RE: [pqc-forum] Re: Update on SP 800-208
Thanks Jim. Well worded. At a first glance, I see no problems with your proposed technical content.
[[JimG]] Thanks, glad to hear that you’re alright with the gist of the proposal!
This is a nit, but for:
“C5c: Should require a minimal level of expertise to maintain.”
I think here you mean “maintain” as in “requires minimal expertise to operate because the HSM hides all the complexity” and not “requires minimal expertise for an HSM vendor to implement the sectorization algorithm”?
I suggest instead: “C5c: Should require a minimal level of expertise to initially configure and operate over time a crypto module operating in this mode”.
[[JimG]] That is indeed what we were thinking, and the meaning we meant to convey, thank you so very much for the clarified text!
Also, can you please comment specifically on:
“N5: Should avoid using patents.”
Can you please comment directly on whether Crypto4A holds or is aware of any patents around your sectorization method?
[[JimG]] Absolutely! As stated below, our sectorization approach is based on the state reservation schemes described in a paper published by McGrew et. al. in April 2016, and as far as we know they never patented any of these ideas (Scott and Dave, please jump in and correct our understanding if we’re mistaken on this front). As we have stated on multiple occasions, Crypto4A has no patent (filed or pending) on this technique, and has no intention of patenting the idea now or in the future. We’ve always advocated for defining IP-free mechanisms that help everyone succeed (a rising tide raises all boats…), and to that end we’re happy to also share our existing sectorized private key format with the community to facilitate HSM interoperability and avoid vendor lock-in due to proprietary key formats and the like. Hopefully this statement makes our position clear on the matter, but please let me know if you still have questions/concerns. Thanks!
---
Mike Ounsworth
From: <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov> On Behalf Of Jim Goodman
Sent: Thursday, November 21, 2024 3:08 PM
To: 'dustin...@nist.gov' < <mailto:dustin...@nist.gov> dustin...@nist.gov>; 'pqc-forum' < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov>
Subject: [EXTERNAL] RE: [pqc-forum] Re: Update on SP 800-208
Hi Dustin and team, First of all, we’d like to thank you for listening to the feedback from the industry, and for the presentation last week on this topic. Crypto4A would be happy to contribute to this discussion, and collaborate on defining
Hi Dustin and team,
First of all, we’d like to thank you for listening to the feedback from
the industry, and for the presentation last week on this topic. Crypto4A
would be happy to contribute to this discussion, and collaborate on
defining an appropriate private key format that incorporates the additional
information required to implement “Scheme #2” of John’s presentation. We
have a format that we’ve been using extensively for 6+ years that we think
will work well for this purpose, and which we’re happy to share with the
rest of the community.
At Crypto4A, we’ve been using HSS as a way to secure our HSMs (e.g., FW
signing, attestation, etc.) since 2018 and we use a concept we refer to
as <https://urldefense.com/v3/__https:/crypto4a.com/wp-content/uploads/2023/06/Sectorization.pdf__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4hYyv-oFQ$> sectorization which appears to be the same as “Scheme #2” in the
presentation slides. It is based on, and is essentially an instantiation
of, the reservation systems described in section 5 of McGrew et. al.’s
original <https://urldefense.com/v3/__https:/eprint.iacr.org/2016/357__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4jSuU0_vg$> HBS state-management paper. In our scheme, the private key is
divided into 2d sectors that each cover a mutually exclusive set of OTS
keys, and there is a separate step to “provision” each sector that is
required prior to signing. Fundamentally, establishing a distinction
between the “setup” and the “provision” steps decouples the state management
problem from the operational signing considerations. This has many
advantages, including the ability to perform concurrent signing operations,
scale the performance, provide resilience against disasters, have geo-
redundancy, etc.
We agree with all of the requirements and constraints you’ve outlined in
your presentation. However, we have gathered a few additional requirements
both from our own use of the method, as well as many interactions with
various parties in the industry. In order to reference them more easily
later on, here is a summary of all the requirements gathered so far (“N”
refers to requirements outlined by NIST, and “C” refers to additional
requirements we would like to add):
* N1: Must be able to recover from device failure.
* N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
* N3: Must allow for keys to move from one vendor to another.
* N4: Must minimize the changes to SP800-208.
* N5: Should avoid using patents.
* N6: Signatures must be performed within an HSM.
* C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
* C2: Must be compatible and compliant with CNSA 2.0.
* C3: Must support air-gapped/offline deployments.
* C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
* C5: Should minimize the cost of ownership.
1. C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
2. C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
3. C5c: Should require a minimal level of expertise to maintain.
4. C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
5. C5e: Should allow for manual/procedural or fully automated support for state management.
As an HSM vendor, we strive to offer solutions that work for as many use
cases as possible (i.e. crypto-agility by design) while understanding that
different sets of constraints may apply based on the specific circumstances.
When it comes to scheme #2, we believe that the responses to the
questions at the end of John’s presentations are as follows:
* Is there some reason this won’t work?
* We have been using scheme #2 very successfully for over 6 years for our own manufacturing processes and it works.
* How hard will these be to allow in SP800-208?
* We would suggest that only a few changes to SP800-208 are necessary to accommodate scheme #2. They are as follows:
* The private key format for export must be extended to include the additional information (i.e., Merkle tree path data of upper d levels), and should be standardized to promote HSM interoperability and prevent vendor lock-in.
* The requirement in section 6.1 of SP800-208 on LMS key generation that dictates that “the same SEED value shall be used to generate every private element in a single LMS instance” must be relaxed to allow for the generation of sectors that cover a mutually exclusive set of OTS keys. We would not be averse to allowing these sector seeds to be generated from a root/master seed using a suitable one-way PRNG, provided that root/master seed is destroyed upon completion of the generation of the sector seeds.
* The requirement in section 8.1 of SP800-208 that dictates that “the cryptographic module shall not allow for the export of private keying material” should be relaxed as was described in the meeting on November 13.
* Will these meet industry needs?
* We believe so based on our interactions with companies and customers who have elected to utilize S-HBS.
Take care, and thank you once again for continuing this discussion within the
PQC community!
Jim and the rest of the Crypto4A team
We also recorded a video of the presentation. If you'd like access, please contact me and I can share the video. NIST plans to have a follow-up meeting for some additional discussion and feedback. Details will be announced when that is set up.
Dustin Moody
NIST
<https://urldefense.com/v3/__https:/teams.microsoft.com/l/meetup-join/19*3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli*40thread.v2/0?context=*7b*22Tid*22*3a*222ab5d82f-d8fa-4797-a93e-054655c61dec*22*2c*22Oid*22*3a*22dd46ae92-6bb7-47b9-aaf6-07052c29b63a*22*7d__;JSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4jDRwiWGA$> Join the meeting now
Meeting ID: 220 481 575 152
Passcode: vRCadd
_____
Dial in by phone
<tel:(443)%20339-4347> +1 443-339-4347,,505996741# United States, Sherwood Forest
<https://urldefense.com/v3/__https:/dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4hlLudmKA$> Find a local number
Phone conference ID: 505 996 741#
Join on a video conferencing device
Tenant key: <mailto:1013...@teams-us.bjn.vc> 1013...@teams-us.bjn.vc
Video ID: 118 970 311 8
<https://urldefense.com/v3/__https:/dialin.bluejeans.com/teams?key=101340915&conf=1189703118&domain=teams-us.bjn.vc__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4iYig4A1g$> More info
--
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 <mailto:pqc-forum+...@list.nist.gov> pqc-forum+...@list.nist.gov.
To view this discussion visit <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4iotIyetA$> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov.
--
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 <mailto:pqc-forum+...@list.nist.gov> pqc-forum+...@list.nist.gov.
To view this discussion visit <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59*2476e003b0*2464a00b10*24*40crypto4a.com?utm_medium=email&utm_source=footer__;JSUlJQ!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4hEKsmj3g$> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59%2476e003b0%2464a00b10%24%40crypto4a.com.
Thanks for your excellent feedback! Please
see my responses inline below in red.
Take care.
Jim
From: Mike Ounsworth <Mike.Ou...@entrust.com>
Sent: November 21, 2024 4:33 PM
To: Jim Goodman <ji...@crypto4a.com>; 'dustin...@nist.gov' <dustin...@nist.gov>; 'pqc-forum' <pqc-...@list.nist.gov>
Subject: RE: [EXTERNAL] RE: [pqc-forum] Re: Update on SP 800-208
Thanks Jim. Well worded. At a first glance, I see no problems with your proposed technical content.
This is a nit, but for:
“C5c: Should require a minimal level of expertise to maintain.”
I think here you mean “maintain” as in “requires minimal expertise to operate because the HSM hides all the complexity” and not “requires minimal expertise for an HSM vendor to implement the sectorization algorithm”?
I suggest instead: “C5c: Should require a minimal level of expertise to initially configure and operate over time a crypto module operating in this mode”.
Also, can you please comment specifically on:
“N5: Should avoid using patents.”
Can you please comment directly on whether Crypto4A holds or is aware of any patents around your sectorization method?
---
Mike Ounsworth
From: <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov> On Behalf Of Jim Goodman
Sent: Thursday, November 21, 2024 3:08 PM
To: 'dustin...@nist.gov' < <mailto:dustin...@nist.gov> dustin...@nist.gov>; 'pqc-forum' < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov>
Subject: [EXTERNAL] RE: [pqc-forum] Re: Update on SP 800-208
Hi Dustin and team, First of all, we’d like to thank you for listening to the feedback from the industry, and for the presentation last week on this topic. Crypto4A would be happy to contribute to this discussion, and collaborate on defining
Hi Dustin and team,
First of all, we’d like to thank you for listening to the feedback from
the industry, and for the presentation last week on this topic. Crypto4A
would be happy to contribute to this discussion, and collaborate on
defining an appropriate private key format that incorporates the additional
information required to implement “Scheme #2” of John’s presentation. We
have a format that we’ve been using extensively for 6+ years that we think
will work well for this purpose, and which we’re happy to share with the
rest of the community.
At Crypto4A, we’ve been using HSS as a way to secure our HSMs (e.g., FW
signing, attestation, etc.) since 2018 and we use a concept we refer to
presentation slides. It is based on, and is essentially an instantiation
of, the reservation systems described in section 5 of McGrew et. al.’s
divided into 2d sectors that each cover a mutually exclusive set of OTS
keys, and there is a separate step to “provision” each sector that is
required prior to signing. Fundamentally, establishing a distinction
between the “setup” and the “provision” steps decouples the state management
problem from the operational signing considerations. This has many
advantages, including the ability to perform concurrent signing operations,
scale the performance, provide resilience against disasters, have geo-
redundancy, etc.
We agree with all of the requirements and constraints you’ve outlined in
your presentation. However, we have gathered a few additional requirements
both from our own use of the method, as well as many interactions with
various parties in the industry. In order to reference them more easily
later on, here is a summary of all the requirements gathered so far (“N”
refers to requirements outlined by NIST, and “C” refers to additional
requirements we would like to add):
* N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
* N3: Must allow for keys to move from one vendor to another.
* N4: Must minimize the changes to SP800-208.
* N5: Should avoid using patents.
* N6: Signatures must be performed within an HSM.
* C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
* C2: Must be compatible and compliant with CNSA 2.0.
* C3: Must support air-gapped/offline deployments.
* C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
* C5: Should minimize the cost of ownership.
1. C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
2. C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
3. C5c: Should require a minimal level of expertise to maintain.
4. C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
5. C5e: Should allow for manual/procedural or fully automated support for state management.
As an HSM vendor, we strive to offer solutions that work for as many use
cases as possible (i.e. crypto-agility by design) while understanding that
different sets of constraints may apply based on the specific circumstances.
When it comes to scheme #2, we believe that the responses to the
questions at the end of John’s presentations are as follows:
* We have been using scheme #2 very successfully for over 6 years for our own manufacturing processes and it works.
* How hard will these be to allow in SP800-208?
* We would suggest that only a few changes to SP800-208 are necessary to accommodate scheme #2. They are as follows:
* The private key format for export must be extended to include the additional information (i.e., Merkle tree path data of upper d levels), and should be standardized to promote HSM interoperability and prevent vendor lock-in.
* The requirement in section 6.1 of SP800-208 on LMS key generation that dictates that “the same SEED value shall be used to generate every private element in a single LMS instance” must be relaxed to allow for the generation of sectors that cover a mutually exclusive set of OTS keys. We would not be averse to allowing these sector seeds to be generated from a root/master seed using a suitable one-way PRNG, provided that root/master seed is destroyed upon completion of the generation of the sector seeds.
* The requirement in section 8.1 of SP800-208 that dictates that “the cryptographic module shall not allow for the export of private keying material” should be relaxed as was described in the meeting on November 13.
* Will these meet industry needs?
* We believe so based on our interactions with companies and customers who have elected to utilize S-HBS.
Take care, and thank you once again for continuing this discussion within the
PQC community!
Jim and the rest of the Crypto4A team
From: 'dustin...@nist.gov' via pqc-forum < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov>
Sent: November 18, 2024 9:23 AM
To: pqc-forum < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov>
Cc: <mailto:dustin...@nist.gov> dustin...@nist.gov < <mailto:dustin...@nist.gov> dustin...@nist.gov>
Subject: [pqc-forum] Re: Update on SP 800-208
All,
We have posted the slides from John Kelsey's presentation on NIST's planned update for SP 800-208:
<https://urldefense.com/v3/__https:/csrc.nist.gov/Projects/stateful-hash-based-signatures/presentations__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4i1-UoVeA$> https://csrc.nist.gov/Projects/stateful-hash-based-signatures/presentations
Sent: November 18, 2024 9:23 AM
To: pqc-forum < <mailto:pqc-...@list.nist.gov> pqc-...@list.nist.gov>
Cc: <mailto:dustin...@nist.gov> dustin...@nist.gov < <mailto:dustin...@nist.gov> dustin...@nist.gov>
Subject: [pqc-forum] Re: Update on SP 800-208
All,
We have posted the slides from John Kelsey's presentation on NIST's planned update for SP 800-208:
We also recorded a video of the presentation. If you'd like access, please contact me and I can share the video. NIST plans to have a follow-up meeting for some additional discussion and feedback. Details will be announced when that is set up.
Dustin Moody
NIST
On Friday, November 8, 2024 at 8:18:32 AM UTC-5 <mailto:dustin...@nist.gov> dustin...@nist.gov wrote:
All,
NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, was published in 2020. We've received feedback from some in industry in regards to the restriction against private key export as laid out in 208. In response, NIST has held a few public discussions about possible options about how to deal with issue. NIST would like to share our approach for how we plan to revise SP 800-208 that would enable key export, but also mitigate security concerns.
For those interested, NIST will hold a virtual meeting where John Kelsey will outline our path forward. We realize this is short notice, so we will be sure to post slides, and record the talk as well. Thanks,
Dustin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Wednesday, November 13th
Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
Microsoft Teams <https://urldefense.com/v3/__https:/aka.ms/JoinTeamsMeeting?omkt=en-US__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4io9Wa_-Q$> Need help?
All,
NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, was published in 2020. We've received feedback from some in industry in regards to the restriction against private key export as laid out in 208. In response, NIST has held a few public discussions about possible options about how to deal with issue. NIST would like to share our approach for how we plan to revise SP 800-208 that would enable key export, but also mitigate security concerns.
For those interested, NIST will hold a virtual meeting where John Kelsey will outline our path forward. We realize this is short notice, so we will be sure to post slides, and record the talk as well. Thanks,
Dustin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Wednesday, November 13th
Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
<https://urldefense.com/v3/__https:/teams.microsoft.com/l/meetup-join/19*3ameeting_ZDVlZmEyZTMtODkyYi00OGRmLThlM2EtODY2OThjMTZlNTli*40thread.v2/0?context=*7b*22Tid*22*3a*222ab5d82f-d8fa-4797-a93e-054655c61dec*22*2c*22Oid*22*3a*22dd46ae92-6bb7-47b9-aaf6-07052c29b63a*22*7d__;JSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4jDRwiWGA$> Join the meeting now
Meeting ID: 220 481 575 152
Passcode: vRCadd
_____
<tel:(443)%20339-4347> +1 443-339-4347,,505996741# United States, Sherwood Forest
<https://urldefense.com/v3/__https:/dialin.teams.microsoft.com/292b8cb3-df78-4db2-b335-f5296905ed36?id=505996741__;!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4hlLudmKA$> Find a local number
Phone conference ID: 505 996 741#
Join on a video conferencing device
Video ID: 118 970 311 8
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion visit <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n*40list.nist.gov?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4iotIyetA$> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion visit <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59*2476e003b0*2464a00b10*24*40crypto4a.com?utm_medium=email&utm_source=footer__;JSUlJQ!!FJ-Y8qCqXTj2!eckS70p19z2mT54x6JEi8qVUg7CD99ZDwx9Qd6sawmwjo8TVtMHHDn7dJ30R0ELqLwlBTxnsItm7XQDtG4hEKsmj3g$> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59%2476e003b0%2464a00b10%24%40crypto4a.com.
Andrey Jivsov
Nov 23, 2024, 9:31:58 PM11/23/24
to dustin...@nist.gov, pqc-forum
I think this is a fine proposal. It solves the issue of state management by not managing the state but by re-provisioning new data HSMs in the event of hardware failures and similar accidents.
I personally find it striking how much state management is allegedly a problem, given that in case of HBS it is the easiest states to manage:
* it is public;
* it is a single monotonically increasing integer (per key);
* it is auditable from signatures.
However, at this point the stakeholders have made their mind and it will be hard to change that.
I think that the second method in the proposal is the best because it does not change the signature from the perspective of verifiers, which should be one of the main criteria for any new method.
Regarding ensuring both no-vendor-lock and safe provisioning, my understanding is that the current practice is to save an RSA private key in a safe, which may be password-protected. (Maybe it is split into key shares, but I doubt it. Access to the safe itself can be similarly controlled instead.). Whatever methods are used to store the long-term RSA private keys should work for storing the seed(s). In other words, it does not appear to me that the procedural methods must be solved at the SP 800 208 level.
Second, on slide 18, there is the line "• Store each seed to allow provisioning". Why can't that instead be "store the root seed"? This single seed will be easier to manage. This seed will be able to generate initial d nodes to start the Merkle verification chain. So, the state will be a (root_seed, root+metadata, current derived seed index), v.s. (root+metadata, 2^d seeds, 2^d nodes, current seed index). Both methods are subject to abuse in a similar way.
This will require standardization of pseudo-random private (and public) key generation, but I think this is a fair price to pay to make LMS/XMSS useful in real-world deployments.
Thank you
Sebastien Riou
Dec 1, 2024, 4:31:47 AM12/1/24
to Jim Goodman, Mike Ounsworth, dustin...@nist.gov, pqc-forum
Hi,
Thanks Jim for listing the requirements again and adding a few more. I rewrite them here with the enhanced version of C5c from Mike. I add a few more prefixed with "P":
- N1: Must be able to recover from device failure.
- N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
- N3: Must allow for keys to move from one vendor to another.
- N4: Must minimize the changes to SP800-208.
- N5: Should avoid using patents.
- N6: Signatures must be performed within an HSM.
- C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
- C2: Must be compatible and compliant with CNSA 2.0.
- C3: Must support air-gapped/offline deployments.
- C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
- C5: Should minimize the cost of ownership.
- C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
- C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
- C5c: Should require a minimal level of expertise to initially configure and operate over time a crypto module operating in this mode.
- C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
- C5e: Should allow for manual/procedural or fully automated support for state management.
- P1: Must minimize the number of "procedural defenses" and their complexity.
- P2: The loss of a device (an HSM) must not significantly reduce the number of remaining signatures.
- P3: Must be usable with "small parameters" yielding 32, 1024 and 32768 signatures and preserve their computational efficiency, at least on verification side.
Some remarks/questions:
- N6: HSM equals anything which passed CMVP 140-3 level 3, right ?
- C1: I would like to challenge this one. Perhaps supporting only LMS would be preferable:
- As of today, only LMS has CAVP in place.
- XMSSMT and HSS are not allowed in CNSA 2.0.
- All benchmarks I have seen so far conclude that LMS is faster than XMSS.
- More algorithms means more development/validation/maintenance efforts for developers and more fragmentation in the field.
- C3: Probably every reader has their own idea about the meaning of this one. It would be worth expanding it in my opinion.
- C4: "Concurrently" shall not be interpreted too strictly. CNSA 2.0 limits the use of LMS and XMSS to code signing and for that particular application there is no need to be able to sign EXACTLY at the same time.
- C5: The schemes I proposed are deployable using a single HSM. For the multi party counting, the counter HSMs are replaced by smart cards and the arbiter HSM is merged with the single signing HSM.
- C5* vs P3: I doubt we can have a solution that meets all requirements. However, having a standard which allows us to meet either all C5* or P3 is certainly possible.
- C5e: What do you mean by manual ? I think we shall avoid relying on "humans doing the right thing" as much as possible (P1)
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
as sectorization which appears to be the same as “Scheme #2” in the
presentation slides. It is based on, and is essentially an instantiation
of, the reservation systems described in section 5 of McGrew et. al.’s
original HBS state-management paper. In our scheme, the private key is
divided into 2d sectors that each cover a mutually exclusive set of OTS
keys, and there is a separate step to “provision” each sector that is
required prior to signing. Fundamentally, establishing a distinction
between the “setup” and the “provision” steps decouples the state management
problem from the operational signing considerations. This has many
advantages, including the ability to perform concurrent signing operations,
scale the performance, provide resilience against disasters, have geo-
redundancy, etc.
We agree with all of the requirements and constraints you’ve outlined in
your presentation. However, we have gathered a few additional requirements
both from our own use of the method, as well as many interactions with
various parties in the industry. In order to reference them more easily
later on, here is a summary of all the requirements gathered so far (“N”
refers to requirements outlined by NIST, and “C” refers to additional
requirements we would like to add):
- N1: Must be able to recover from device failure.
- N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
- N3: Must allow for keys to move from one vendor to another.
- N4: Must minimize the changes to SP800-208.
- N5: Should avoid using patents.
- N6: Signatures must be performed within an HSM.
- C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
- C2: Must be compatible and compliant with CNSA 2.0.
- C3: Must support air-gapped/offline deployments.
- C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
- C5: Should minimize the cost of ownership.
- C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
- C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
- C5c: Should require a minimal level of expertise to maintain.
- C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
- C5e: Should allow for manual/procedural or fully automated support for state management.
As an HSM vendor, we strive to offer solutions that work for as many use
cases as possible (i.e. crypto-agility by design) while understanding that
different sets of constraints may apply based on the specific circumstances.
When it comes to scheme #2, we believe that the responses to the
questions at the end of John’s presentations are as follows:
- Is there some reason this won’t work?
- We have been using scheme #2 very successfully for over 6 years for our own manufacturing processes and it works.
- How hard will these be to allow in SP800-208?
- We would suggest that only a few changes to SP800-208 are necessary to accommodate scheme #2. They are as follows:
- The private key format for export must be extended to include the additional information (i.e., Merkle tree path data of upper d levels), and should be standardized to promote HSM interoperability and prevent vendor lock-in.
- The requirement in section 6.1 of SP800-208 on LMS key generation that dictates that “the same SEED value shall be used to generate every private element in a single LMS instance” must be relaxed to allow for the generation of sectors that cover a mutually exclusive set of OTS keys. We would not be averse to allowing these sector seeds to be generated from a root/master seed using a suitable one-way PRNG, provided that root/master seed is destroyed upon completion of the generation of the sector seeds.
- The requirement in section 8.1 of SP800-208 that dictates that “the cryptographic module shall not allow for the export of private keying material” should be relaxed as was described in the meeting on November 13.
- Will these meet industry needs?
- We believe so based on our interactions with companies and customers who have elected to utilize S-HBS.
Take care, and thank you once again for continuing this discussion within the
PQC community!
Jim and the rest of the Crypto4A team
From: 'dustin...@nist.gov' via pqc-forum <pqc-...@list.nist.gov>
Sent: November 18, 2024 9:23 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: dustin...@nist.gov <dustin...@nist.gov>
Subject: [pqc-forum] Re: Update on SP 800-208
All,
We have posted the slides from John Kelsey's presentation on NIST's planned update for SP 800-208:
We also recorded a video of the presentation. If you'd like access, please contact me and I can share the video. NIST plans to have a follow-up meeting for some additional discussion and feedback. Details will be announced when that is set up.
Dustin Moody
NIST
On Friday, November 8, 2024 at 8:18:32 AM UTC-5 dustin...@nist.gov wrote:
All,
NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, was published in 2020. We've received feedback from some in industry in regards to the restriction against private key export as laid out in 208. In response, NIST has held a few public discussions about possible options about how to deal with issue. NIST would like to share our approach for how we plan to revise SP 800-208 that would enable key export, but also mitigate security concerns.
For those interested, NIST will hold a virtual meeting where John Kelsey will outline our path forward. We realize this is short notice, so we will be sure to post slides, and record the talk as well. Thanks,
Dustin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Wednesday, November 13th
Time: 12:00pm-1:30pm, Eastern Standard Time (GMT-5)
Microsoft Teams Need help?
Phone conference ID: 505 996 741#
Join on a video conferencing device
Tenant key: 1013...@teams-us.bjn.vc
Video ID: 118 970 311 8
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/80a8d299-9434-404e-8fc4-c24a3c174486n%40list.nist.gov.
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/000d01db3c59%2476e003b0%2464a00b10%24%40crypto4a.com.
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/004601db3c85%24a87c0aa0%24f9741fe0%24%40crypto4a.com.
Jim Goodman
Dec 2, 2024, 11:19:25 PM12/2/24
to Sebastien Riou, Mike Ounsworth, dustin...@nist.gov, pqc-forum
Hi Sebastien,
Thanks for continuing to help flesh this all out and
move things forward. Please see my comments inline
below in red demarked by [C4A].
Take care.
Jim
From: Sebastien Riou <sebasti...@pqshield.com>
Sent: December 1, 2024 4:31 AM
To: Jim Goodman <ji...@crypto4a.com>
Cc: Mike Ounsworth <Mike.Ou...@entrust.com>; dustin...@nist.gov <dustin...@nist.gov>; pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [EXTERNAL] RE: [pqc-forum] Re: Update on SP 800-208
Hi,
Thanks Jim for listing the requirements again and adding a few more. I rewrite them here with the enhanced version of C5c from Mike. I add a few more prefixed with "P":
- N1: Must be able to recover from device failure.
- N2: Must not make assumptions on the number of devices that will be needed over the lifetime of the key.
- N3: Must allow for keys to move from one vendor to another.
- N4: Must minimize the changes to SP800-208.
- N5: Should avoid using patents.
- N6: Signatures must be performed within an HSM.
- C1: Must work for all variants of stateful HBS keys (XMSS, XMSSMT, LMS and HSS).
- C2: Must be compatible and compliant with CNSA 2.0.
- C3: Must support air-gapped/offline deployments.
- C4: Must support geo-redundancy deployments where the same key can be used concurrently in different geographies.
- C5: Should minimize the cost of ownership.
- C5a: Should be deployable using a single HSM. The purpose of this requirement is to reduce the initial cost of deployment. Naturally, it would be recommended to introduce some redundancy prior to a production-level deployment.
- C5b: Should be scalable (i.e., support parallelism, avoid performance bottlenecks, avoid “dead-time” for signature operations, allow for reallocation of devices based on needs, etc.).
- C5c: Should require a minimal level of expertise to initially configure and operate over time a crypto module operating in this mode.
- C5d: Should not require additional services (e.g., synchronized and secure time, other HSMs used in different roles, and any other components that might add latency for operational use).
- C5e: Should allow for manual/procedural or fully automated support for state management.
- P1: Must minimize the number of "procedural defenses" and their complexity.
[C4A] We don’t think MUST is warranted here, this is at best a SHOULD as we’re always striving to reduce complexity so it’s more of a best practices effort. Similarly, this should also include the setup and maintenance of a complex system, replacing procedural steps with complex components and control isn’t an obvious improvement due to the unforeseen complications that can arise by adopting this approach. Over time, as the kinks get worked out, and experience/expertise is gathered, the complexity may diminish, but it doesn’t come for free. Mike’s C5c was intended to address this concern, and we think it is sufficient for this purpose.
- P2: The loss of a device (an HSM) must not significantly reduce the number of remaining signatures.
[C4A] It’s not clear why this is a MUST. It is at best a SHOULD as over provisioning can easily address this issue without any significant cost both in terms of size and verification time in the vast majority of use cases.
- P3: Must be usable with "small parameters" yielding 32, 1024 and 32768 signatures and preserve their computational efficiency, at least on verification side.
[C4A] Another SHOULD rather than a MUST, though I believe all proposals work fine with this requirement (and indeed, nothing proposed by anyone so far changes anything from the verifier’s perspective).
Some remarks/questions:
- N6: HSM equals anything which passed CMVP 140-3 level 3, right ?
[C4A] We’ll defer to NIST and the CMVP to dictate what constitutes a valid device as at the end of the day they own the validation process. However, regardless of what devices they ultimately deem valid, we’d argue that the real requirement here is that these devices MUST use quantum-safe roots of trust to protect their firmware updating process and services. If you’re going to be relying on a device to provide quantum-safe signatures then it too should be built upon quantum-safe principles trust lest the signatures it generates be akin to steel doors on glass houses since a quantum-capable attacker could compromise the underlying firmware of the device and its behaviour. That kind of defeats the purpose of generating quantum-safe signatures, no?
- C1: I would like to challenge this one. Perhaps supporting only LMS would be preferable:
- As of today, only LMS has CAVP in place.
- XMSSMT and HSS are not allowed in CNSA 2.0.
- All benchmarks I have seen so far conclude that LMS is faster than XMSS.
- More algorithms means more development/validation/maintenance efforts for developers and more fragmentation in the field.
[C4A] We feel this is an unnecessary constraint, and have customers who have invested in an XMSS-based infrastructure due to their preference for its stated security assumptions. We don’t want to get dragged into the LMS vs. XMSS holy war, but think that given they have similar state management problems, we should NOT limit the scope without a good reason. Customers can make their own decisions as to what algorithm they prefer, and given the use case focus on FW signing I don’t think interoperability is a concern as a system builder will tailor their implementation to verify whatever algorithm they deem worthy. As an HSM vendor we strive to provide a full suite of capabilities to our customers, PQShield, or anyone else for that matter, is of course is free to limit their customers’ options if they think that makes sense to them.
- C3: Probably every reader has their own idea about the meaning of this one. It would be worth expanding it in my opinion.
[C4A] We think the meaning is pretty self-evident in the title “air-gapped” as in no external connection. See my earlier comment regarding striving to deliver a full suite of capabilities to our customers, several of which place a very high value on this ability to operate offline in a physically-secure fashion. Hence, they desire to deploy their HSMs in an environment where connectivity is limited (be it on purpose as per a desired security posture, or just due to unreliable connectivity), and they want to ensure that the device can still deliver the intended functionality (e.g., signing a FW image in the often-used example discussed here). This will lead to serious issues if we start placing dependencies like the availability of secure time sources, or access to an arbitration device to dictate whether or not a device can deliver the service it was intended for. A device that cannot operate in a standalone mode after being provisioned increases the potential attack surface, and becomes an easy target for denial-of-service.
- C4: "Concurrently" shall not be interpreted too strictly. CNSA 2.0 limits the use of LMS and XMSS to code signing and for that particular application there is no need to be able to sign EXACTLY at the same time.
[C4A] Once again, we choose to not take that decision out of our customers hands. If they want to generate signatures concurrently then we want to provide that option, and don’t think this arbitrary constraint/interpretation is warranted.
- C5: The schemes I proposed are deployable using a single HSM. For the multi party counting, the counter HSMs are replaced by smart cards and the arbiter HSM is merged with the single signing HSM.
[C4A] That sounds like a reasonable mapping (but will defer to NIST/CMVP to dictate what devices are considered suitable options), but our fear is that the multi-party counting scheme won’t scale very well and is a rather complex solution with single-points of failure. So while it may meet C5a, we’re not sure it maps well to C5b-C5e.
- C5* vs P3: I doubt we can have a solution that meets all requirements. However, having a standard which allows us to meet either all C5* or P3 is certainly possible.
[C4A] Requirements can indeed be impossible to completely satisfy, but the intent is to ensure we provide a reasonable set that allows us to make good decisions while still trying to cover a reasonable variety of customers’ needs. All of our stated requirements were based on actual customer requirements collected over numerous engagements to build S-HBS infrastructure. We’re still not sure we see the importance of P3 as being as high as you seem to be positioning things, but we agree that we should be able to find a solution that makes everyone happy (or at the very least a lot less unhappy than they currently are! ;->).
- C5e: What do you mean by manual ? I think we shall avoid relying on "humans doing the right thing" as much as possible (P1)
[C4A] Let’s not forget that all HSM installations begin with a key ceremony that is an inherently manual process, that is 100% founded on the notion of “humans doing the right thing” in order to ensure auditability of the foundational security of a new root of trust. That being said, we agree that automated solutions have their advantages, but manual ones do too, and both also have their disadvantages. While a manual solution might require humans to do the right thing, an automated one does too given the Herculean efforts required to validate the automation to ensure the devices are doing what was intended in the face of possibly unexpected (and potentially malicious) inputs. Ultimately, manual solutions have the advantage of being much less expensive, and typically much simpler from an implementation perspective. Automated solutions benefit from not requiring human input during normal operation, but they usually require far more complex setup procedures, more complicated software (which increases your attack surface and system complexity), and more complex infrastructures. Ultimately though, customers have different use cases and different requirements, so having flexible solutions that can cover different customers’ use cases is better than taking the choice out of their hands and forcing trade-offs onto those customers. Lastly, sectorization does lend itself to automation in the form of managing the unprovisioned sectors and ensuring no replication or re-provisioning of a sector (e.g., the Key Coordinator concept we presented at the March SP800-208 meeting at NCCoE). It’s just that it doesn’t require automation to work if the system operator decides that the additional complexity isn’t warranted given their comfort level with using manual processes. At the end of the day it’s their decision to make so we try to provide a solution that can work in either scenario.
John Mattsson
Dec 3, 2024, 4:25:01 AM12/3/24
to Jim Goodman, Sebastien Riou, Mike Ounsworth, dustin...@nist.gov, pqc-forum
Hi,
If I could choose, I would much rather see NIST prioritizing additional parameter sets for the general purpose SLH-DSA algorithm. As NIST writes in 800-208, LMS and XMSS are not suitable for general use.
In the Norwegian National Security Authority Cryptographic Recommendations for 2024, LMS and XMSS are not even approved. I agree with the Norwegian recommendations. I see standalone SLH-DSA and hybridized ML-DSA as the two options. LMS and XMSS was just a temporary step before FIPS 204 and FIPS 205.
Cheers,
John
Arne Tobias Ødegaard
Dec 3, 2024, 6:37:31 AM12/3/24
to pqc-forum, John Mattsson, Mike Ounsworth, dustin...@nist.gov, pqc-forum, Jim Goodman, Sebastien Riou
Dear John (and all),
We would like to clarify our position and the purpose of our recommendations. The document shared was a draft version, and LMS and XMSS will be recommended in the final version, of course with the proviso that these algorithms are not for general use. We hope to get the final version published before the end of the year. Furthermore, our recommendations are on purpose rather selective, and the absence of an algorithm from our recommendations does not imply disapproval of that algorithm.
We expect that LMS and/or XMSS will have some important use cases, and for that reason we support NIST trying to update SP 800-208 and making it as good as possible. Of course, we would also welcome standardisation of additional parameter sets for SLH-DSA, but we do not have a strong preference for which one of these should be prioritised.
On behalf of the Norwegian National Security Authority,
Arne Tobias Ødegaard
Sebastien Riou
Dec 6, 2024, 6:24:41 AM12/6/24
to Jim Goodman, Mike Ounsworth, dustin...@nist.gov, pqc-forum
Hi Jim,
I added the P1~P3 requirements as a "user" rather than a "provider". For secure boot, PQShield has the same problems as many other companies working in the semiconductor industry as well as "deeply embedded" products:
1. Boot time shall be as short as possible
2. Boot ROM shall be as small as possible
3. Compromission of a signing key is impacting a huge number of devices and most of the times there isn't any fix because the public key cannot be updated (hardwired or in ROM or in an OTP without any spare location)
Regarding points 1 and 2, LMS with up to 32k signatures is the best solution as of today (SLH-DSA is not a good alternative as it is slower). When using parameters with a higher number of signatures, LMS becomes typically slower than ECDSA and therefore the migration to PQC becomes a problem. In other words, "Overprovisioning" in that context is not a good solution because it makes the product uncompetitive or even not functional (triggering an Airbag after passengers have been thrown out of the windows is not an option for example).
Point 3 is so far agnostic to the algorithm selection but, as security architect, I may downgrade SP800-208 if the only option on the signing side involves more manual steps than for other algorithms. This is especially true if the correctness of the manual step cannot be easily and automatically checked and if it is irreversible (such as the disclosure of an LMS signature generated with an already used part of the OTS tree).
I recognize that sectorization can do the job, I am just saying that it is not the only way and that allowing the separation of the stateless part of the key enables other approaches which seems interesting for the semiconductor industry.
I fully agree with your statement about N6 "these devices MUST use quantum-safe roots of trust to protect their firmware updating process and services". I would add that their backup mechanism and basically any other "admin" function MUST be quantum-safe. I think this point does not belong in SP800-208 though, I think it should be a tick box somewhere in FIPS 140-3 CMVP.
Best regards,
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
Jeffrey Walton
Dec 6, 2024, 1:16:59 PM12/6/24
to Sebastien Riou, dustin...@nist.gov, pqc-forum
On Fri, Dec 6, 2024 at 6:24 AM 'Sebastien Riou' via pqc-forum
<pqc-...@list.nist.gov> wrote:
>
> I added the P1~P3 requirements as a "user" rather than a "provider". For secure boot, PQShield has the same problems as many other companies working in the semiconductor industry as well as "deeply embedded" products:
> 1. Boot time shall be as short as possible
> 2. Boot ROM shall be as small as possible
> 3. Compromission of a signing key is impacting a huge number of devices and most of the times there isn't any fix because the public key cannot be updated (hardwired or in ROM or in an OTP without any spare location)
>
> Regarding points 1 and 2, LMS with up to 32k signatures is the best solution as of today (SLH-DSA is not a good alternative as it is slower). When using parameters with a higher number of signatures, LMS becomes typically slower than ECDSA and therefore the migration to PQC becomes a problem. In other words, "Overprovisioning" in that context is not a good solution because it makes the product uncompetitive or even not functional (triggering an Airbag after passengers have been thrown out of the windows is not an option for example).
>
> Point 3 is so far agnostic to the algorithm selection but, as security architect, I may downgrade SP800-208 if the only option on the signing side involves more manual steps than for other algorithms. This is especially true if the correctness of the manual step cannot be easily and automatically checked and if it is irreversible (such as the disclosure of an LMS signature generated with an already used part of the OTS tree).
>
> I recognize that sectorization can do the job, I am just saying that it is not the only way and that allowing the separation of the stateless part of the key enables other approaches which seems interesting for the semiconductor industry.
>
> I fully agree with your statement about N6 "these devices MUST use quantum-safe roots of trust to protect their firmware updating process and services". I would add that their backup mechanism and basically any other "admin" function MUST be quantum-safe. I think this point does not belong in SP800-208 though, I think it should be a tick box somewhere in FIPS 140-3 CMVP.
For quantum-safe roots and protecting firmware updating processes: I
<pqc-...@list.nist.gov> wrote:
>
> I added the P1~P3 requirements as a "user" rather than a "provider". For secure boot, PQShield has the same problems as many other companies working in the semiconductor industry as well as "deeply embedded" products:
> 1. Boot time shall be as short as possible
> 2. Boot ROM shall be as small as possible
> 3. Compromission of a signing key is impacting a huge number of devices and most of the times there isn't any fix because the public key cannot be updated (hardwired or in ROM or in an OTP without any spare location)
>
> Regarding points 1 and 2, LMS with up to 32k signatures is the best solution as of today (SLH-DSA is not a good alternative as it is slower). When using parameters with a higher number of signatures, LMS becomes typically slower than ECDSA and therefore the migration to PQC becomes a problem. In other words, "Overprovisioning" in that context is not a good solution because it makes the product uncompetitive or even not functional (triggering an Airbag after passengers have been thrown out of the windows is not an option for example).
>
> Point 3 is so far agnostic to the algorithm selection but, as security architect, I may downgrade SP800-208 if the only option on the signing side involves more manual steps than for other algorithms. This is especially true if the correctness of the manual step cannot be easily and automatically checked and if it is irreversible (such as the disclosure of an LMS signature generated with an already used part of the OTS tree).
>
> I recognize that sectorization can do the job, I am just saying that it is not the only way and that allowing the separation of the stateless part of the key enables other approaches which seems interesting for the semiconductor industry.
>
> I fully agree with your statement about N6 "these devices MUST use quantum-safe roots of trust to protect their firmware updating process and services". I would add that their backup mechanism and basically any other "admin" function MUST be quantum-safe. I think this point does not belong in SP800-208 though, I think it should be a tick box somewhere in FIPS 140-3 CMVP.
think SP 800-53A, Assessing Security and Privacy Controls in
Information Systems and Organizations, somewhere around Supply Chain
Risk Management, would be a good choice for the tick box.
Jeff
dustin...@nist.gov
Jan 31, 2025, 8:55:51 AMJan 31
to pqc-forum, dustin...@nist.gov
Subject: Continue the NIST SP 800-208 Discussion - Feb 13, from 1 to 5 PM ET
The objective of the meeting on February 13 from 1 to 5 PM ET is to continue the discussion of the proposed approaches John Kelsey presented last November.
You are welcome to join remotely or in person at the NIST NCCoE facility.
NIST NCCoE
9700 Great Seneca Hwy
Rockville, MD 20850
If you plan to attend in person, please provide your full name as it appears on your government-issued ID. If you are a foreign national, reach out to me immediately so I can collect additional information to clear you for entry into a federal facility. Please provide this information by Wednesday, February 5.
Thanks
Murugiah
dustin...@nist.gov
Jan 31, 2025, 9:14:01 AMJan 31
to pqc-forum, dustin...@nist.gov
To attend remotely:
Microsoft Teams Need help?
Meeting ID: 256 880 097 120
Passcode: 49Ee6hf2
Dial in by phone
+1 443-339-4347,,649384590# United States, Sherwood Forest
Phone conference ID: 649 384 590#
Join on a video conferencing device
dustin...@nist.gov
Jan 31, 2025, 1:32:35 PMJan 31
to pqc-forum, dustin...@nist.gov
I apologize for yet another message, but there is a needed correction. The date for this meeting is February 12th, 1 to 5PM ET.
dustin...@nist.gov
Feb 7, 2025, 11:47:43 AMFeb 7
to pqc-forum, dustin...@nist.gov
John Kelsey has prepared a short document that he'd like to share with those who will be attending the meeting at the NCCoE to continue the discussion on SP 800-208 (stateful hash based signatures). It is attached. It would be helpful to read before the meeting. Thanks!
Dustin
Brent Kimberley
Feb 7, 2025, 1:10:50 PMFeb 7
to dustin...@nist.gov, pqc-forum
>>Backups of stateful HBS are dangerous, as they can lead to reuse of one-time keys
What happens if SP 800-208 was modified to incorporate a strong unique identity – known only to the HSM itself?
From: 'dustin...@nist.gov' via pqc-forum <pqc-...@list.nist.gov>
Sent: February 7, 2025 11:48 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: dustin...@nist.gov <dustin...@nist.gov>
Subject: [pqc-forum] Re: Update on SP 800-208
|
⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️ |
--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/d5182a6e-79b6-4a09-879e-13b4a5029449n%40list.nist.gov.
Brent Kimberley
Feb 7, 2025, 1:27:16 PMFeb 7
to dustin...@nist.gov, pqc-forum
On second thought. Don’t change SP 800-208. The HSM backup and restore process needs to incorporate a scheme to prevent reuse of one-time keys.
From: Brent Kimberley
Sent: February 7, 2025 1:11 PM
To: dustin...@nist.gov <dustin...@nist.gov>; pqc-forum <pqc-...@list.nist.gov>
COSTA Graham
May 19, 2025, 2:20:40 PMMay 19
to dustin...@nist.gov, pqc-forum
THALES GROUP LIMITED DISTRIBUTION to email recipients
As a follow-on from this meeting, are there any updates from NIST CTG on when the community might expect an initial public draft for an updated SP 800-208?
Any guidance is much appreciated as we’re increasingly getting asked questions about facilitating a transfer capability (as proposed by John) in FIPS 140 certified configurations of our HSM. Critical to unlocking that, is understanding timelines linked to any future SP 800-208 updates that might be in flight.
Thanks,
Graham.
From: 'dustin...@nist.gov' via pqc-forum <pqc-...@list.nist.gov>
Sent: Friday, February 7, 2025 4:48 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: dustin...@nist.gov <dustin...@nist.gov>
Subject: [pqc-forum] Re: Update on SP 800-208
John Kelsey has prepared a short document that he'd like to share with those who will be attending the meeting at the NCCoE to continue the discussion on SP 800-208 (stateful hash based signatures). It is attached. It would be helpful to read before the meeting. Thanks!
--
COSTA Graham
Sep 2, 2025, 3:26:02 PMSep 2
to dustin...@nist.gov, pqc-forum
THALES GROUP LIMITED DISTRIBUTION to email recipients
Are there any updates from NIST on the open question below?
This remains an open topic for us as a cryptographic module vendor, as we have customers committed to deploying LMS using our HSM for code signing. In particular, they are interested in timelines for firmware updates that would enable options to transfer sections of generated keys between devices as a FIPS 140-3 approved service.
Graham.
From: COSTA Graham
Sent: Monday, May 19, 2025 7:20 PM
To: dustin...@nist.gov <dustin...@nist.gov>; pqc-forum <pqc-...@list.nist.gov>
Reply all
Reply to author
Forward
0 new messages