NIST Lightweight Cryptography -- Timeline
159 views
Skip to first unread message
Sonmez Turan, Meltem (Fed)
Dec 30, 2022, 2:06:56 PM12/30/22
to lwc-...@list.nist.gov
Dear subscribers of the NIST Lightweight Cryptography forum,
We would like to inform you that NIST LWC team is planning to continue internal discussions for a few additional weeks before announcing the winner(s) of the standardization effort.
Please feel free to share your recent results/observations via the forum or email the NIST team directly at lightweig...@nist.gov.
Happy holidays,
On behalf of the NIST Lightweight Cryptography Team
Arne Padmos
Jan 5, 2023, 5:12:38 PM1/5/23
to Sonmez Turan, Meltem (Fed), lightweig...@nist.gov, lwc-...@list.nist.gov, cry...@nist.gov
Dear Meltem and the rest of the team,
Thank you for this update and best wishes for the new year.
I would very much appreciate if the final LWC report could include a
detailed discussion supporting key decisions made, including different
perspectives of the team and the role that external input has played, as
well as how this has been gathered (see the final AES report from 2001,
pages 13--16, as one example). Besides aligning with fundamental
principles such as transparency and openness behind NISTIR 7977, such
detailed supporting arguments are also very valuable for posterity,
including for those researching the dynamics of security competitions.
On the topic of NISTIR 7977, there are several relevant points to make.
It specifically describes a NIST competition as having one winner. Of
course, both the PQC and LWC process are classed as 'competition-like'.
However, such an approach to cryptographic standards development is not
described in NISTIR 7977. This document from March 2016 notes that it is
to be reviewed every five years. I have not been able to find any public
information about this review. Maybe the broader Cryptographic
Technology Group can clarify whether and how NISTIR 7977 has been
reviewed, and how this review relates to competition-like processes.
Although such considerations haven't been made explicit in NISTIR 7977,
I understand how performance gaps of two orders of magnitude on a given
measure support having multiple algorithms for PQC, even if that leads
to a decrease in compatibility and an increase in complexity. This is
less clear to me when it comes to symmetric cryptography. I haven't yet
found detailed arguments for the shift from the 'if any' stance to the
description of standardising 'one or more' algorithms. Are there any
measures for which there is an order of magnitude improvement, and/or
are there any other distinguishing features to support standardising one
or more new symmetric algorithms (for example, providing a flexible
interface/toolkit allowing designers of embedded systems to translate
protection goals to properties in an efficient and error-proof manner,
aka Saltzer & Schroeder's psychological acceptability principle)?
More broadly speaking (and looking back to NISTIR 7977): whatever choice
NIST makes, are the above considerations transparent and made with
sufficient community involvement? This is not just a question around the
analysis of individual algorithms, but also for underlying fundamental
questions (such as whether and if so how many algorithms are
standardised besides AES and SHA2/SHA3; see paragraph 3 of page 15 of
the final AES report for what this discussion looked like in 2000).
Regards,
Arne
PS. For those who don't have the final AES report at hand: 'At the AES3
conference, there was significant discussion regarding the number of
algorithms that should be included in the AES. The vast majority of
attendees expressed their support -- both verbally and with a show of
hands -- for selecting only a single algorithm. There was some support
for selecting a backup algorithm, but there was no agreement as to how
that should be accomplished. The above sentiments were reflected in
written comments provided to NIST by many of the attendees after the
conference.'
On 2022-12-30 20:06, 'Sonmez Turan, Meltem (Fed)' via lwc-forum wrote:
> Dear subscribers of the NIST Lightweight Cryptography forum,
>
> We would like to inform you that NIST LWC team is planning to continue
> internal discussions for a few additional weeks before announcing the
> winner(s) of the standardization effort.
>
> Please feel free to share your recent results/observations via the
> forum or email the NIST team directly at
> lightweig...@nist.gov<mailto:lightweig...@nist.gov>.
Thank you for this update and best wishes for the new year.
I would very much appreciate if the final LWC report could include a
detailed discussion supporting key decisions made, including different
perspectives of the team and the role that external input has played, as
well as how this has been gathered (see the final AES report from 2001,
pages 13--16, as one example). Besides aligning with fundamental
principles such as transparency and openness behind NISTIR 7977, such
detailed supporting arguments are also very valuable for posterity,
including for those researching the dynamics of security competitions.
On the topic of NISTIR 7977, there are several relevant points to make.
It specifically describes a NIST competition as having one winner. Of
course, both the PQC and LWC process are classed as 'competition-like'.
However, such an approach to cryptographic standards development is not
described in NISTIR 7977. This document from March 2016 notes that it is
to be reviewed every five years. I have not been able to find any public
information about this review. Maybe the broader Cryptographic
Technology Group can clarify whether and how NISTIR 7977 has been
reviewed, and how this review relates to competition-like processes.
Although such considerations haven't been made explicit in NISTIR 7977,
I understand how performance gaps of two orders of magnitude on a given
measure support having multiple algorithms for PQC, even if that leads
to a decrease in compatibility and an increase in complexity. This is
less clear to me when it comes to symmetric cryptography. I haven't yet
found detailed arguments for the shift from the 'if any' stance to the
description of standardising 'one or more' algorithms. Are there any
measures for which there is an order of magnitude improvement, and/or
are there any other distinguishing features to support standardising one
or more new symmetric algorithms (for example, providing a flexible
interface/toolkit allowing designers of embedded systems to translate
protection goals to properties in an efficient and error-proof manner,
aka Saltzer & Schroeder's psychological acceptability principle)?
More broadly speaking (and looking back to NISTIR 7977): whatever choice
NIST makes, are the above considerations transparent and made with
sufficient community involvement? This is not just a question around the
analysis of individual algorithms, but also for underlying fundamental
questions (such as whether and if so how many algorithms are
standardised besides AES and SHA2/SHA3; see paragraph 3 of page 15 of
the final AES report for what this discussion looked like in 2000).
Regards,
Arne
PS. For those who don't have the final AES report at hand: 'At the AES3
conference, there was significant discussion regarding the number of
algorithms that should be included in the AES. The vast majority of
attendees expressed their support -- both verbally and with a show of
hands -- for selecting only a single algorithm. There was some support
for selecting a backup algorithm, but there was no agreement as to how
that should be accomplished. The above sentiments were reflected in
written comments provided to NIST by many of the attendees after the
conference.'
On 2022-12-30 20:06, 'Sonmez Turan, Meltem (Fed)' via lwc-forum wrote:
> Dear subscribers of the NIST Lightweight Cryptography forum,
>
> We would like to inform you that NIST LWC team is planning to continue
> internal discussions for a few additional weeks before announcing the
> winner(s) of the standardization effort.
>
> Please feel free to share your recent results/observations via the
> forum or email the NIST team directly at
Sonmez Turan, Meltem (Fed)
Jan 11, 2023, 11:55:25 AM1/11/23
to Arne Padmos, lightweight-crypto, lwc-...@list.nist.gov
Dear Arne,
Thank you very much for your suggestions.
The NIST team is currently finalizing the third-round status report that explains the selection process. We accept your suggestion to include more detailed discussion, similar to that in the
2001 AES report. Link: dx.doi.org/10.6028/jres.106.023
Regarding the review process, the NIST Computer Security Division established the Crypto Publications Review Board in January 2021. The aim of the board is to periodically review NIST’s cryptographic
standards and guidelines as promised in NISTIR 7977. NIST currently has over 40 publications that are within the scope of this review process (some older than 20 years). So far, the board has completed seven reviews (see link).
Ongoing reviews include FIPS 197, Advanced Encryption Standard, FIPS 180-4, Secure Hash Standard, the SP 800-38 series (block cipher modes of operation), and SP 800-132 (password based key derivation function). There are several factors that determine the order
of publication reviews, such as the publication date, recent research developments, and the potential impact of the review. The board plans to initiate the public review of NISTIR 7977 in early 2023.
The NIST team is still discussing the standardization of 'one or more' algorithms. Additional comments and suggestions are welcome.
Regards,
Meltem on behalf of the NIST LWC team
Arne Padmos
Jan 11, 2023, 6:33:13 PM1/11/23
to Sonmez Turan, Meltem (Fed), lightweight-crypto, lwc-...@list.nist.gov
Dear Meltem,
Great to hear that you'll be adding additional details on the selection
process to the third-round status report. (Sidenote: section 2
'Selection Issues and Methodology' of the document you linked appears to
be equivalent to pages 13--16 of
https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=151226.)
Thank you for clarifying the situation with respect to the review of
NISTIR 7977. If the document had been reviewed earlier, this may have
proved useful for driving both the PQC and LWC processes. But it's hard
to say with certainty whether and if so how this may have influenced
things. Either way, 'it is what it is'.
As to your note that additional comments and suggestions are welcome:
I've shared my views before, which can be summarised as the utility of
having a single standard with a flexible interface that affords a clean
and efficient mapping to higher-level protocols. I'd like to encourage
others on the lwc-forum to also share their perspectives. Besides being
of potential value to the final deliberations of NIST, I think it is
also interesting to explore and learn from different and similar ways of
looking at the question of standardising 'one or more' algorithms and
related topics.
Regards,
Arne
On 2023-01-11 17:55, 'Sonmez Turan, Meltem (Fed)' via lwc-forum wrote:
> Dear Arne,
>
> Thank you very much for your suggestions.
>
> The NIST team is currently finalizing the third-round status report
> that explains the selection process. We accept your suggestion to
> include more detailed discussion, similar to that in the 2001 AES
> report. Link: dx.doi.org/10.6028/jres.106.023
>
> Regarding the review process, the NIST Computer Security Division
> established the Crypto Publications Review Board in January 2021. The
> aim of the board is to periodically review NIST's cryptographic
> standards and guidelines as promised in NISTIR 7977. NIST currently
> has over 40 publications that are within the scope of this review
> process (some older than 20 years). So far, the board has completed
> seven reviews (see
> link<https://csrc.nist.gov/projects/crypto-publication-review-project/completed-reviews>).
>> lightweig...@nist.gov<mailto:lightweig...@nist.gov<mailto:lightweig...@nist.gov<mailto:lightweig...@nist.gov>>.
Great to hear that you'll be adding additional details on the selection
process to the third-round status report. (Sidenote: section 2
'Selection Issues and Methodology' of the document you linked appears to
be equivalent to pages 13--16 of
https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=151226.)
Thank you for clarifying the situation with respect to the review of
NISTIR 7977. If the document had been reviewed earlier, this may have
proved useful for driving both the PQC and LWC processes. But it's hard
to say with certainty whether and if so how this may have influenced
things. Either way, 'it is what it is'.
As to your note that additional comments and suggestions are welcome:
I've shared my views before, which can be summarised as the utility of
having a single standard with a flexible interface that affords a clean
and efficient mapping to higher-level protocols. I'd like to encourage
others on the lwc-forum to also share their perspectives. Besides being
of potential value to the final deliberations of NIST, I think it is
also interesting to explore and learn from different and similar ways of
looking at the question of standardising 'one or more' algorithms and
related topics.
Regards,
Arne
On 2023-01-11 17:55, 'Sonmez Turan, Meltem (Fed)' via lwc-forum wrote:
> Dear Arne,
>
> Thank you very much for your suggestions.
>
> The NIST team is currently finalizing the third-round status report
> that explains the selection process. We accept your suggestion to
> include more detailed discussion, similar to that in the 2001 AES
> report. Link: dx.doi.org/10.6028/jres.106.023
>
> Regarding the review process, the NIST Computer Security Division
> established the Crypto Publications Review Board in January 2021. The
> aim of the board is to periodically review NIST's cryptographic
> standards and guidelines as promised in NISTIR 7977. NIST currently
> has over 40 publications that are within the scope of this review
> process (some older than 20 years). So far, the board has completed
> seven reviews (see
Robert Moskowitz
Jan 11, 2023, 6:41:52 PM1/11/23
to Arne Padmos, Sonmez Turan, Meltem (Fed), lightweight-crypto, lwc-...@list.nist.gov
yes to higher-level calls, but given sp800-185 and cSHAKE and KMAC,
I would expect the same to follow here.
I have worked with Xoodyak:
https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
there is code in the openHIP base to support this.
But if you peruse the draft, you will see how I had to use cyclist calls rather than some nice KMAC-like call.
I also want the KDF covered. I understand all that has to be updated to document using KMAC directly as a KDF. Please don't get us locked up like that here. KDFs are important and though less used than keyed-MACs still need to be efficient.
Robert
I have worked with Xoodyak:
https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
there is code in the openHIP base to support this.
But if you peruse the draft, you will see how I had to use cyclist calls rather than some nice KMAC-like call.
I also want the KDF covered. I understand all that has to be updated to document using KMAC directly as a KDF. Please don't get us locked up like that here. KDFs are important and though less used than keyed-MACs still need to be efficient.
Robert
--
Robert Moskowitz
Owner
HTT Consulting
C: 248-219-2059
F: 248-968-2824
E: r...@labs.htt-consult.com
There's no limit to what can be accomplished if it doesn't matter who gets the credit
Robert Moskowitz
Owner
HTT Consulting
C: 248-219-2059
F: 248-968-2824
E: r...@labs.htt-consult.com
There's no limit to what can be accomplished if it doesn't matter who gets the credit
Reply all
Reply to author
Forward
0 new messages