Found 4 records.

Status: Verified (1)

RFC 9180, "Hybrid Public Key Encryption", February 2022

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.

Status: Reported (3)

RFC 9180, "Hybrid Public Key Encryption", February 2022

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: 7790
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Neil Madden
Date Reported: 2024-01-30

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.

Report New Errata