)]}'
{
  "commit": "08b1f38577b6da8533179ffdb4a42b5afc36dc27",
  "tree": "b3cf11637201262c19aa19b261687b245720e698",
  "parents": [
    "028bae7ddc67b6061d80c17b0be4e2f60d94731b"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue Feb 28 17:22:23 2023 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Mar 01 17:26:52 2023 +0000"
  },
  "message": "Use KEM terminology in TLS ECDHE and key_share abstractions\n\nTLS 1.2 ECDHE and TLS 1.3 key shares were originally designed around\nDiffie-Hellman-like primitives and use language based on that.\nPost-quantum replacements do not look like Diffie-Hellman, where each\npart exchanges a public key, but schemes that work differently can still\nslot in without protocol changes.\n\nWe previously came up with our own Offer/Accept/Finish abstraction for\nearly post-quantum experiments, but the NIST constructions are all\nexpressed as KEMs: First, the recipient generates a keypair and sends\nthe public key. Then the sender encapsulates a symmetric secret and\nsends the ciphertext. Finally, the recipient decapsulates the ciphertext\nto get the secret.\n\nAlign our C++ and Go abstractions to this terminology. The functions are\nnow called Generate/Encap/Decap, and the output of Encap is called\n\"ciphertext\", which seems to align with what most folks use. (RFC 9180\nuses \"enc\" for \"encapsulated key\", but they staple a KEM to an AEAD, so\n\"ciphertext\" would be ambiguous.)\n\nWhere variable names refer to parts of the protocol, rather than the\nthe underlying KEM-like construction, I\u0027ve kept variable names matching\nthe protocol mechanism, so we still talk about \"curves\" and \"key\nshares\", but, when using the post-quantum replacements, the terminology\nis no longer quite accurate.\n\nI\u0027ve also not yet renamed SSLKeyShare yet, though the name is now\ninaccurate. Also ideally we\u0027d touch that up so the stateful object is\njust a KEM private key, for SSLKEMKey. Though at that point, we maybe\nshould just add EVP_KEM and EVP_KEM_KEY APIs to libcrypto.\n\nChange-Id: Icbcc1840c5d2dfad210ef4caad2a7c4bf8146553\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57726\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0c54c93445bf364f942cd3c9622875d772636837",
      "old_mode": 33188,
      "old_path": "ssl/extensions.cc",
      "new_id": "ba923603557797f6273330acd797a80e3aebae00",
      "new_mode": 33188,
      "new_path": "ssl/extensions.cc"
    },
    {
      "type": "modify",
      "old_id": "ccb0b5e4218ccd5fca001976033a983da4da65a2",
      "old_mode": 33188,
      "old_path": "ssl/handoff.cc",
      "new_id": "6e5cc2da1434fa8a07f3f86744c4d506f8fbd75d",
      "new_mode": 33188,
      "new_path": "ssl/handoff.cc"
    },
    {
      "type": "modify",
      "old_id": "64fd2f2d0dc62e552afbdd6f3fac740efdd94401",
      "old_mode": 33188,
      "old_path": "ssl/handshake_client.cc",
      "new_id": "e7dca1bebc7ded611e967bfac0559aab57b9f4b7",
      "new_mode": 33188,
      "new_path": "ssl/handshake_client.cc"
    },
    {
      "type": "modify",
      "old_id": "70fe9839e395e7f06412d8949630ad04d566f35a",
      "old_mode": 33188,
      "old_path": "ssl/handshake_server.cc",
      "new_id": "e50a69021342d81b003717881d0ecda6cef926df",
      "new_mode": 33188,
      "new_path": "ssl/handshake_server.cc"
    },
    {
      "type": "modify",
      "old_id": "fac15b6b2b87a9face56c05d6ae64221ba3888d5",
      "old_mode": 33188,
      "old_path": "ssl/internal.h",
      "new_id": "e71dd0c08b1c4096ed0e5fc19ac388dc48430a0d",
      "new_mode": 33188,
      "new_path": "ssl/internal.h"
    },
    {
      "type": "modify",
      "old_id": "c604c870cc05504ef8abac6507193bf8e11f0140",
      "old_mode": 33188,
      "old_path": "ssl/ssl_key_share.cc",
      "new_id": "a81b91704d12133d52efabaea89237db1cc8b6f7",
      "new_mode": 33188,
      "new_path": "ssl/ssl_key_share.cc"
    },
    {
      "type": "modify",
      "old_id": "5d04994ad23ef8917b6d5ca69ac41ef44a5681eb",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/handshake_client.go",
      "new_id": "42f0534fd0db4f0b1366e177d7e4e97c162454f0",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/handshake_client.go"
    },
    {
      "type": "modify",
      "old_id": "5ae7d936524beba2003b3b4ac0c326e46b0c4ca8",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/handshake_server.go",
      "new_id": "de297a66359d7a3e7551d3834aed94610d261584",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/handshake_server.go"
    },
    {
      "type": "modify",
      "old_id": "bfd35f69f6da9c0960293a5800357956127f2850",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/key_agreement.go",
      "new_id": "47cdbb8b0e159051b7bb96de8f4e344004118ff4",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/key_agreement.go"
    },
    {
      "type": "modify",
      "old_id": "ca436242ae53963742b59c99affa57ea35620e1b",
      "old_mode": 33188,
      "old_path": "ssl/tls13_server.cc",
      "new_id": "0bbe97f2732e607a65146e843280c1a760dadae1",
      "new_mode": 33188,
      "new_path": "ssl/tls13_server.cc"
    }
  ]
}