)]}'
{
  "commit": "d75a9670be28b6294f28cc3ddfe597a44878ddaa",
  "tree": "524af1d531185a7ae80e13842cb153a65c2b7a47",
  "parents": [
    "a2eba23aceb2a05ddb96c3661596784fb1698b96"
  ],
  "author": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Fri Jun 19 18:09:56 2026 +0100"
  },
  "committer": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Sat Jun 20 15:53:39 2026 +0100"
  },
  "message": "[tls] Centralise pseudorandom data generation\n\nTLS version 1.3 has a formal key schedule based on HKDF, and requires\nthe client to be able to recall ephemeral secrets at multiple points\nwithin the connection lifecycle.  For example: the ephemeral private\nkey for X25519 key exchange may be required when constructing\nClientHello (for a TLS version 1.3 key share) or when constructing\nClientKeyExchange (if subsequently falling back to use TLS version\n1.2), and again when parsing a ServerHello key share or a\nServerKeyExchange.\n\nSome ephemeral private keys may be large (e.g. for ffdhe4096).  Avoid\nthe need to store these large (and variably sized) private keys by\ninstead instantiating a standalone HKDF instance that we seed with\nper-connection random data and subsequently use to generate ephemeral\nprivate keys on demand.  (Note that this instance is unrelated to the\nHKDF instance defined in the formal key schedule for TLS: we are\nchoosing to reuse HKDF for this purpose simply because supporting TLS\nversion 1.3 will already require HKDF support to be present.)\n\nWe use the key exchange algorithm name (e.g. \"x25519\") as additional\ninformation to ensure separation between keys used for different\npurposes.  Since the initial random seed is generated afresh for each\nconnection, and since there can meaningfully be only one ephemeral\nprivate key per key exchange algorithm per connection, this is\nsufficient to ensure separation.\n\nHaving instantiated this HKDF, we then also use it to generate the\nclient random bytes (with the label \"client random\"), to generate the\nrandom portion of the pre-master secret for classic RSA key exchange\n(with the label \"classic pre-master\"), and to generate the random\nportion of record IVs (using the authentication header structure,\nwhich is already guaranteed to be unique per record within a\nconnection).  Doing this allows us to eliminate all other calls to the\nRNG, and removes some potential failure paths.\n\nWe reset the HKDF on a connection restart and on connection close, to\npreserve the property of forward secrecy.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "18e6446173838a09ddba8f4306492cbd506873d9",
      "old_mode": 33188,
      "old_path": "src/include/ipxe/tls.h",
      "new_id": "210444a38c89e330eb8b0af498a5fec5b038b5ce",
      "new_mode": 33188,
      "new_path": "src/include/ipxe/tls.h"
    },
    {
      "type": "modify",
      "old_id": "a8ca951622e1a5e2efdfd17bf8fcb83ccef70903",
      "old_mode": 33188,
      "old_path": "src/net/tls.c",
      "new_id": "097e72ee022bf15683524f50d22edb719445bbb9",
      "new_mode": 33188,
      "new_path": "src/net/tls.c"
    }
  ]
}