Google Git
Sign in
boringssl/boringssl/e20b0220e903a1dbe32846eb29018253721f1bf8
commit
e20b0220e903a1dbe32846eb29018253721f1bf8
[log]
author
David Benjamin <davidben@google.com>
Sun May 03 17:32:58 2026 -0400
committer
boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mon May 04 15:03:11 2026 -0700
tree
4e5a14362e877ed729c772ca88dc439bdf367fad
parent
65818adf16411ca394625f5747a1af28faf95d2c [diff]
Use HPKE-PQ test vectors from the spec

I'm not sure where these test vectors came from. They were added to the
generated file and would be clobbered if we ever re-ran the generator.
Instead, import the test-vectors.json file from HPKE-PQ and adapt the
generator to convert both separately.

In doing so, fix up some inconsistencies about what we consider to be
the "seed" input to EVP_HPKE_CTX_setup_sender_with_seed_for_testing. We
generally match ikmE, except for X25519 where we use skEm. (There is no
real consequence to using one or the other.)

As part of this, we have to contend with the spec pairing ML-KEM-1024
with HKDF-SHA-384. It would be nice to not have so many of these, but
given that adding HKDF-SHA-384 is a small scattering of lines, probably
we just add it and don't think about it too hard.

Change-Id: I35396fac367d6c13075e8fda2efaaf3c486e97e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/94647
Commit-Queue: Lily Chen <chlily@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Lily Chen <chlily@google.com>
14 files changed
tree: 4e5a14362e877ed729c772ca88dc439bdf367fad
  1. .bcr/
  2. .github/
  3. bench/
  4. cmake/
  5. crypto/
  6. decrepit/
  7. docs/
  8. fuzz/
  9. gen/
  10. include/
  11. infra/
  12. pki/
  13. rust/
  14. ssl/
  15. third_party/
  16. tool/
  17. util/
  18. .bazelignore
  19. .bazelrc
  20. .bazelversion
  21. .clang-format
  22. .clang-format-ignore
  23. .clangd
  24. .gitattributes
  25. .gitignore
  26. API-CONVENTIONS.md
  27. AUTHORS
  28. BREAKING-CHANGES.md
  29. BUILD.bazel
  30. build.json
  31. BUILDING.md
  32. CMakeLists.txt
  33. codereview.settings
  34. CONTRIBUTING.md
  35. FUZZING.md
  36. go.mod
  37. go.sum
  38. INCORPORATING.md
  39. LICENSE
  40. MODULE.bazel
  41. MODULE.bazel.lock
  42. PORTING.md
  43. PRESUBMIT.py
  44. PrivacyInfo.xcprivacy
  45. README.md
  46. SANDBOXING.md
  47. SECURITY.md
  48. STYLE.md
README.md

BoringSSL

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Project links:

To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.

There are other files in this directory which might be helpful: