RFC Errata
Found 8 records.
Status: Verified (3)
RFC 9180, "Hybrid Public Key Encryption", February 2022
Source of RFC: IRTF
Errata ID: 6941
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: CJ
Date Reported: 2022-04-21
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2022-05-12
Section 6.1 says:
In many cases, applications encrypt only a single message to a recipient's public key. This section provides templates for HPKE APIs that implement stateless "single-shot" encryption and decryption using APIs specified in Sections 5.1.1 and 5.2:
It should say:
In many cases, applications encrypt only a single message to a recipient's public key. This section provides templates for HPKE APIs that implement stateless "single-shot" encryption and decryption using APIs specified in Sections 5.1 and 5.2:
Notes:
5.1.1 -> 5.1: I think the description of the single-shot APIs should refer to the entire HPKE modes hence Section 5.1, instead of Section 5.1.1 which is about the base mode only.
Errata ID: 7790
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Neil Madden
Date Reported: 2024-01-30
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2024-04-27
Section 9.1.2 says:
A detailed computational analysis of HPKE's Auth mode single-shot encryption API has been done in [ABHKLR20]. The paper defines security notions for authenticated KEMs and for authenticated public key encryption, using the outsider and insider security terminology known from signcryption [SigncryptionDZ10]. The analysis proves that DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for all Diffie-Hellman groups specified in this document.
It should say:
A detailed computational analysis of HPKE's Auth mode single-shot encryption API has been done in [ABHKLR20]. The paper defines security notions for authenticated KEMs and for authenticated public key encryption, using the outsider and insider security terminology known from signcryption [SigncryptionDZ10]. The analysis proves that DHKEM's AuthEncap()/AuthDecap() interface fulfills the notions of Outsider-CCA, Insider-CCA, and Outsider-Auth for all Diffie-Hellman groups specified in this document. It does not fulfill the notion of Insider-Auth defined in the paper.
Notes:
The referenced paper defines four notions of security, Outsider-CCA, Insider-CCA, Outsider-Auth, and Insider-Auth. It proves that HPKE meets the first three, but, contrary to the current text of the RFC, it proves that it does *not* meet Insider-Auth security and that this is infeasible for HPKE. This is an important negative security result that should have been highlighted in the RFC.
Errata ID: 7932
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-10
Verifier Name: RFC Editor
Date Verified: 2024-05-14
Section 5.2 says:
(In the pseudocode below,
It should say:
(In the pseudocode above,
Notes:
The Context<ROLE>.IncrementSeq() pseudocode has already been provided before the last paragraph of section 5.2.
Status: Reported (5)
RFC 9180, "Hybrid Public Key Encryption", February 2022
Source of RFC: IRTF
Errata ID: 7121
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shane Lontis
Date Reported: 2022-09-07
Section Appendix A says:
A.1.1 skEm 52c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f736 skRm 4612c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8ac8 A.1.2 skEm 463426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f588 skRm c5eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce0fd A.1.3 skEm ff4442ef24fbc3c1ff86375b0be1e77e88a0de1e79b30896d73411c5ff4c3518 skRm fdea67cf831f1ca98d8e27b1f6abeb5b7745e9d35348b80fa407ff6958f9137e skSm dc4a146313cce60a278a5323d321f051c5707e9c45ba21a3479fecdf76fc69dd A.1.4 skEm 14de82a5897b613616a00c39b87429df35bc2b426bcfd73febcb45e903490768 skRm cb29a95649dc5656c2d054c1aa0d3df0493155e9d5da6d7e344ed8b6a64a9423 skSm fc1c87d2f3832adb178b431fce2ac77c7ca2fd680f3406c77b5ecdf818b119f4 A.2.1 skEm f4ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381600 skRm 8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e0fb A.2.2 skEm 0c35fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6321 skRm 77d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879 A.2.3 skEm c94619e1af28971c8fa7957192b7e62a71ca2dcdde0a7cc4a8a9e741d600ab13 skRm 3ca22a6d1cda1bb9480949ec5329d3bf0b080ca4c45879c95eddb55c70b80b82 skSm 2def0cb58ffcf83d1062dd085c8aceca7f4c0c3fd05912d847b61f3e54121f05 A.2.4 skEm 5e6dd73e82b856339572b7245d3cbb073a7561c0bee52873490e305cbb710410 skRm 7b36a42822e75bf3362dfabbe474b3016236408becb83b859a6909e22803cb0c skSm 90761c5b0a7ef0985ed66687ad708b921d9803d51637c8d1cb72d03ed0f64418 A.7.1 skEm 095182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa6748165ed skRm 33d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848 A.7.2 skEm 1d72396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e627 skRm 98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a0c A.7.3 skEm 83d3f217071bbf600ba6f081f6e4005d27b97c8001f55cb5ff6ea3bbea1d9295 skRm ed88cda0e91ca5da64b6ad7fc34a10f096fa92f0b9ceff9d2c55124304ed8b4a skSm c85f136e06d72d28314f0e34b10aadc8d297e9d71d45a5662c2b7c3b9f9f9405 A.7.4 skEm a2b43f5c67d0d560ee04de0122c765ea5165e328410844db97f74595761bbb81 skRm c4962a7f97d773a47bdf40db4b01dc6a56797c9e0deaab45f4ea3aa9b1d72904 skSm 6175b2830c5743dff5b7568a7e20edb1fe477fb0487ca21d6433365be90234d0
It should say:
A.1.1 skEm 50c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f776 skRm 4012c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8a48 A.1.2 skEm 403426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f548 skRm c0eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce07d A.1.3 skEm f84442ef24fbc3c1ff86375b0be1e77e88a0de1e79b30896d73411c5ff4c3558 skRm f8ea67cf831f1ca98d8e27b1f6abeb5b7745e9d35348b80fa407ff6958f9137e skSm d84a146313cce60a278a5323d321f051c5707e9c45ba21a3479fecdf76fc695d A.1.4 skEm 10de82a5897b613616a00c39b87429df35bc2b426bcfd73febcb45e903490768 skRm c829a95649dc5656c2d054c1aa0d3df0493155e9d5da6d7e344ed8b6a64a9463 skSm f81c87d2f3832adb178b431fce2ac77c7ca2fd680f3406c77b5ecdf818b11974 A.2.1 skEm f0ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381640 skRm 8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e07b A.2.2 skEm 0835fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6361 skRm 70d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879 A.2.3 skEm c84619e1af28971c8fa7957192b7e62a71ca2dcdde0a7cc4a8a9e741d600ab53 skRm 38a22a6d1cda1bb9480949ec5329d3bf0b080ca4c45879c95eddb55c70b80b42 skSm 28ef0cb58ffcf83d1062dd085c8aceca7f4c0c3fd05912d847b61f3e54121f45 A.2.4 skEm 586dd73e82b856339572b7245d3cbb073a7561c0bee52873490e305cbb710450 skRm 7836a42822e75bf3362dfabbe474b3016236408becb83b859a6909e22803cb4c skSm 90761c5b0a7ef0985ed66687ad708b921d9803d51637c8d1cb72d03ed0f64458 A.7.1 skEm 085182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa67481656d skRm 30d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848 A.7.2 skEm 1872396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e667 skRm 98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a4c A.7.3 skEm 80d3f217071bbf600ba6f081f6e4005d27b97c8001f55cb5ff6ea3bbea1d9255 skRm e888cda0e91ca5da64b6ad7fc34a10f096fa92f0b9ceff9d2c55124304ed8b4a skSm c85f136e06d72d28314f0e34b10aadc8d297e9d71d45a5662c2b7c3b9f9f9445 A.7.4 skEm a0b43f5c67d0d560ee04de0122c765ea5165e328410844db97f74595761bbb41 skRm c0962a7f97d773a47bdf40db4b01dc6a56797c9e0deaab45f4ea3aa9b1d72944 skSm 6075b2830c5743dff5b7568a7e20edb1fe477fb0487ca21d6433365be9023450
Notes:
The introduction section in Appendix A states that
'Each key pair (skX, pkX) is written in its serialized form, where skXm = SerializePrivateKey(skX) '
For X25519 entries this means that values for skXm should be clamped in the following way to modify the first and last bytes:
skXm[0] &= 248;
skXm[skXmlen - 1] &= 127;
skXm[skXmlen - 1] |= 64;
(See Section 5 of https://www.ietf.org/rfc/rfc7748.txt)
Errata ID: 7251
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Stephen Farrell
Date Reported: 2022-11-15
Section 7.2.1 says:
The RECOMMENDED limit for these values is 64 bytes.
It should say:
The RECOMMENDED limit for these values is 66 bytes. (To enable processing of all the test vectors in Appendix A.)
Notes:
Appendix A.6.1 and others have test vectors with an IKM that is 66 octets long. Seems easier to bump the recommended value by 2, rather than invalidate the test vectors, but the latter could also be done if/when 9180 is revised. Meanwhile, no harm for implementers to know this.
Errata ID: 7933
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-12
Section 5.1 says:
return Context<ROLE>(key, base_nonce, 0, exporter_secret) The ROLE template parameter is either S or R, depending on the role of sender or recipient, respectively. See Section 5.2 for a discussion of the key schedule output, including the role-specific Context structure and its API.
It should say:
return Context<ROLE>(key, base_nonce, 0, exporter_secret) The ROLE template parameter is either S or R, depending on the role of sender or recipient, respectively. The third field in the Context<ROLE> refers to the sequence number, that is initialised with a 0 value. See Section 5.2 for a discussion of the key schedule output, including the role-specific Context structure and its API, and the usage of the sequence number.
Notes:
In Section 5.1 the return value of KeySchedule<ROLE> reflects:
return Context<ROLE>(key, base_nonce, 0, exporter_secret)
I'm assuming the "0" value (in the third field of the Context<ROLE>) refers to the sequence number, with an initialisation value of 0, that is mentioned in Section 5.2, but the RFCs does not include details about the meaning of this third field and value.
I suggest to clarify in section 5.1 the meaning of that 0 value and field, and add a reference to section 5.2 with all the details about the sequence number.
Errata ID: 7934
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-12
Sections 5.1 and 7.2.1 say:
- Section 5.1: The psk and psk_id fields MUST appear together or not at all. The psk, psk_id, and info fields have maximum lengths that depend on the KDF itself,... - Section 7.2.1: The following table lists the maximum allowed lengths of these fields for the KDFs defined in this document,...
It should say:
- Section 5.1: [Add a new note] The info parameter used by HPKE is not related to the optional string info used by the LabeledExpand or Expand functions detailed in section 4. The psk and psk_id parameters MUST appear together or not at all. The psk, psk_id, and info parameters have maximum lengths that depend on the KDF itself,... - Section 7.2.1: The following table lists the maximum allowed lengths of these parameters for the KDFs defined in this document,...
Notes:
The reference to the "info" parameter in sections 5.1 and 7.2.1 might be confusing. Thus, I suggest to clearly differentiate between the optional string "info" for the LabeledExpand or Expand functions, whose value is clearly defined by the RFC for each LabeledExpand function used in DHKEM or KeySchedule, and the "info" parameter used by HPKE.
It seems section 7.2.1 refers to the "info" parameter used by HPKE, as it is referenced from section 5.1. This is the "info" parameter that is used specifically as the key for the "info_hash" LabeledExtract function in KeySchedule.
In section 5.1 the third bullet refer to the HPKE "info" parameter, but the 3rd paragraph after the bullets, as it uses the term "fields", might be confused with the "info" string (or field) used by the LabeledExpand and Expand functions.
Perhaps it would be useful to always use two separate terms along RFC 9180:
- the "info" parameter used by HPKE.
- the "info" string used by the LabeledExpand and Expand functions.
As a result, I would remove the term "field(s)" from sections 5.1 and 7.2.1, and replace it by parameter(s).
Additionally, I suggest to add a note in section 5.1 to differentiate both, and clarify that section 5.1 and 7.2.1, with the input length restrictions, refer to the "info" parameter, and not to the "info" string.
Errata ID: 7937
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-13
Section 7.1.3 says:
For X25519 and X448, the DeriveKeyPair() function applies a KDF to the input: <function()>
It should say:
For X25519 and X448, the DeriveKeyPair() function applies a KDF to the input: <function()> The suite_id used implicitly in LabeledExtract() and LabeledExpand() for DeriveKeyPair(ikm) is derived from the KEM identifier of the DHKEM in use (see Section 7.1), that is, based on the type of key pair been generated for that DHKEM type.
Notes:
RFC 9180 dos not specify all the internal values for LabeledExtract(…) and LabeledExpand(…) for DeriveKeyPair(ikm), specifically the suite_id value. These values are required to standardise the DeriveKeyPair(ikm) function, as it is reference in other IETF drafts, such as https://www.ietf.org/archive/id/draft-westerbaan-cfrg-hpke-xyber768d00-02.html#name-derivekeypair-2, and because it is also used in the RFC 9180 KATs: see Appendix A.