Since originallly included in the specification text, a number of cited algorithm specifications have been updated. This should be reflected in the next published revision of the Crypto API.
Proposed bibliography updates
- Update the AES reference to FIPS 197 (May 2023 update). This update makes no technical change to AES, but improves the presentation and adds key-schedule diagrams.
- Replace the reference to FIPS 186-4 with FIPS 186-5, which supersedes FIPS 186-4. This would also require an update to the citing text as the section has moved in FIPS 186, and FIPS186-5 requires key sizes of at least 224 bits for compliance.
- Update the reference to SP 800-108 Rev. 1 Update 1, published in February 2024.
- Update the reference to SP 800-38B, including its October 2016 update.
Legacy algorithms: 3DES and SHA-1
The specification currently includes DES/3DES and SHA-1 because they remain necessary to implement some deployed legacy protocols and to process legacy data. The specification already advises against their general use.
NIST has since withdrawn SP 800-67 Rev. 2: TDEA is no longer approved for applying cryptographic protection, although it remains permitted for legacy decryption, key unwrapping, and MAC verification. NIST also plans to remove SHA-1 from the next revision of FIPS 180 and transition away from SHA-1 for applying cryptographic protection by 31 December 2030.
This raises a broader question for the Crypto API: how should the specification surface an algorithm’s external approval status while retaining support where interoperability with a defined legacy protocol requires it?
Is the current ad-hoc approach for affected algorithms still appropriate, or would a more structured approach for such annotations be considered? Although we might not want to tie guidance to specific approval regimes, or pick which regimes to report on, it does seem appropriate that the API description reflects the status of the algorithm with the organisation that specified it (such as NIST with SHA-1 and DES/3DES).
Is the current approach sufficient to make the security and deployment implications clear to application developers and implementers, while preserving the API support needed by constrained legacy protocols?
Do we need to further update the text relating to SHA-1 and DES given the proposed change in their status in the near future?
Also, are there other externally defined algorithms in the Crypto API whose current status should be reviewed at the same time?
References
Since originallly included in the specification text, a number of cited algorithm specifications have been updated. This should be reflected in the next published revision of the Crypto API.
Proposed bibliography updates
Legacy algorithms: 3DES and SHA-1
The specification currently includes DES/3DES and SHA-1 because they remain necessary to implement some deployed legacy protocols and to process legacy data. The specification already advises against their general use.
NIST has since withdrawn SP 800-67 Rev. 2: TDEA is no longer approved for applying cryptographic protection, although it remains permitted for legacy decryption, key unwrapping, and MAC verification. NIST also plans to remove SHA-1 from the next revision of FIPS 180 and transition away from SHA-1 for applying cryptographic protection by 31 December 2030.
This raises a broader question for the Crypto API: how should the specification surface an algorithm’s external approval status while retaining support where interoperability with a defined legacy protocol requires it?
Is the current ad-hoc approach for affected algorithms still appropriate, or would a more structured approach for such annotations be considered? Although we might not want to tie guidance to specific approval regimes, or pick which regimes to report on, it does seem appropriate that the API description reflects the status of the algorithm with the organisation that specified it (such as NIST with SHA-1 and DES/3DES).
Is the current approach sufficient to make the security and deployment implications clear to application developers and implementers, while preserving the API support needed by constrained legacy protocols?
Do we need to further update the text relating to SHA-1 and DES given the proposed change in their status in the near future?
Also, are there other externally defined algorithms in the Crypto API whose current status should be reviewed at the same time?
References