)]}'
{
  "commit": "29507b81845c25590433a4cf99b915ce99bad155",
  "tree": "3d9b2cf604c350e429800047e1100407597ae8c3",
  "parents": [
    "4b066b0e35dee8704de473490a0eacbd4d4b77a4"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri May 07 15:25:10 2021 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Fri May 14 18:46:54 2021 +0000"
  },
  "message": "Validate RSA public keys more consistently.\n\nhttps://boringssl-review.googlesource.com/c/boringssl/+/42504 aligned\nRSA private key checks, but I missed the public key ones. We have two\ndifferent sets of RSA public key checks right now. One in the parser\njust checks for e \u003d 1 and even e. The other, when using the key, checks\nfor overly large e and n.\n\nAlign the two. Now parsing RSA public keys calls RSA_check_key and the\nextra checks on e are added to RSA_check_key. Note RSA private key\nparsing already called RSA_check_key. The consequences are:\n\nFirst, RSA public keys with large n, large e, or n \u003c e will be rejected\nat parse time. Previously, they would be parsed but all operations on\nthem would fail. This aligns with our existing behavior for parsing\nprivate keys.\n\nSecond, operations on RSA public keys with even e will fail. They\nalready failed to parse, but it was possible to manually construct such\na key. Previously, operations wouldn\u0027t explicitly fail, but they\nwouldn\u0027t do anything useful because even exponents are not invertible.\n(Encrypting would produce something undecryptable and the private key\nwould have a hard time reliably producing signatures we\u0027d accept.) There\nis no change to RSA private keys with even e. Those would already fail\nthe (e, d) consistency check and the fault check.\n\nThird, operations on RSA public keys with e \u003d 1 will fail. They already\nfailed to parse, but it was possible to manually construct such a key\nand \"verify\" signatures or \"encrypt\" messages. However, with e \u003d 1,\nthose operations are no-ops.\n\nFinally, RSA private keys with e \u003d d \u003d 1 will be rejected at parse and\nuse. This is the only case that affects private keys because e \u003d d \u003d 1\nare inverses, just pointless. Uses paired with RSA public key parsing\n(e.g. our TLS library checks consistency with a certificate public key)\nare not affected. Those already rejected such keys because we rejected\nthem in the public key parser. This CL aligns the private half.\n\nThis doesn\u0027t close https://crbug.com/boringssl/316, but we won\u0027t be able\nto resolve that without a consistent story for what keys are valid.\n\nUpdate-Note: See above.\nBug: 316\nChange-Id: Ic27df18c4f48e5e3e57a17d6fe39399e2f8d5c68\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47524\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2f76e9e2e07ca8d98587dac2b0e31a849400cce8",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rsa/rsa_impl.c",
      "new_id": "6dd89b93b484960475a3428aae72d4859615b372",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rsa/rsa_impl.c"
    },
    {
      "type": "modify",
      "old_id": "3cc6a9c3c087243efc771448e51e6bf5adecc566",
      "old_mode": 33188,
      "old_path": "crypto/rsa_extra/rsa_asn1.c",
      "new_id": "58fd69a86d94b5772ac15d9aa7eb3b2ceb0ac248",
      "new_mode": 33188,
      "new_path": "crypto/rsa_extra/rsa_asn1.c"
    }
  ]
}