)]}'
{
  "commit": "cb583e783500d92bbda9a850e43cd94df0b2d5e1",
  "tree": "6c96a38422d74d6bee12d599c0b76fea45d74708",
  "parents": [
    "5edba0bcc9cf554d7a2539b31713b5cd66bff5fc"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Aug 11 18:37:18 2023 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Tue Aug 15 22:15:47 2023 +0000"
  },
  "message": "Default to q \u003d (p-1)/2 for DH keygen\n\nAs with large p, q, or g in the preceding CL, an application that uses\nDiffie-Hellman incorrectly could be given a large private key length.\nComputing the public key and shared secret will then be very slow.\n\nThis matters for a (p, g)-only group, where q is unknown. One way or\nanother, we should bound or clamp dh-\u003epriv_length. The two relevant\nspecifications I could find are SP 800-56A Rev3 and PKCS#3. SP 800-56A\nwants a value for q, so we\u0027d need to fabricate one. I believe X9.42\u0027s\nDiffie-Hellman formulation similarly expects an explicit q. PKCS#3 is\n(p, g)-only and seems to match what OpenSSL does. In PKCS#3:\n\n- DH groups have an optional l, such that 2^(l-1) \u003c\u003d p\n\n- For keygen, if l was provided, pick 2^(l-1) \u003c\u003d x \u003c 2^l. Otherwise,\n  pick 0 \u003c x \u003c p-1\n\nOur current q-less keygen behavior matches this, with\nl \u003d num_bits(p) - 1. Interestingly, the first constraint allows\nl \u003d num_bits(p), but doing so allows x \u003e\u003d p - 1! This is a bit odd and\nwill wrap around the multiplicative group.\n\nOpenSSL 3.0 (but not 1.1.1) bounds l in their q-less path, and cites\nPKCS#3\u0027s 2^(l-1) \u003c\u003d p in a comment. But their actual check doesn\u0027t match\nand excludes num_bits(p). The two problems cancel each other out.\n\nPKCS#3 is quite old and does not even discuss subgroups or safe primes,\nonly this uninspiring text:\n\n\u003e Some additional conditions on the choice of prime, base, and\n\u003e private-value length may well be taken into account in order to deter\n\u003e discrete logarithm computation. These security conditions fall outside\n\u003e the scope of this standard.\n\nI\u0027m thus not inclined to give the document much weight in 2023. SP\n800-56A Rev3 is not ideal either. First, we must fabricate a value for\nq. (p-1)/2 is most natural, though it assumes g indeed generates a\nprime-order subgroup and not the whole multiplicative group.\n\nThe second annoyance with SP 800-56A Rev3 is its insistance on uniformly\nselecting between [1, 2^N-1] instead of [0, 2^N-1] or [1, 2^N]. For all\nplausible values of N, this difference will not matter, yet NIST\nspecifies rejection sampling, defeating the point of a power-of-two\nbound.\n\nNone of these really matters. p should be large enough to make the\ndifferences between all these schemes negligible. Since we want to\nfollow NIST for the (p, q, g) path, using the same scheme for the (p, g)\npath seems the most reasonable. Thus this CL recasts that path from\nPKCS#3 to SP 800-56A, except dh-\u003epriv_length is clamped before invoking\nthe algorithm, to avoid worrying about whether someone expects\nDH_set_length(BN_num_bits(p)) to work.\n\nChange-Id: I270f235a6f04c69f8abf59edeaf39d837e2c79f8\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62228\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "881f72ddef1b047565fe363340b8e1cff1b793e7",
      "old_mode": 33188,
      "old_path": "crypto/dh_extra/dh_test.cc",
      "new_id": "cb5384effe6a90846615e277b1ad208f27cf8f93",
      "new_mode": 33188,
      "new_path": "crypto/dh_extra/dh_test.cc"
    },
    {
      "type": "modify",
      "old_id": "400a8ebccff318a8a608fcaa837f7367f39caeba",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/dh/dh.c",
      "new_id": "a20b6d11df7bd34fb46aeca2aea81f19331b9415",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/dh/dh.c"
    }
  ]
}