)]}'
{
  "commit": "9372f38cd06d181e8c9badf34d0d733670f282cc",
  "tree": "9c4a4edb95b7abcd7802daaeb5d3fce6c24ecc5f",
  "parents": [
    "c947efabcbc38dcf93e8ad0e6a76206cf0ec8072"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Aug 14 13:58:34 2020 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Thu Aug 20 01:59:13 2020 +0000"
  },
  "message": "Bound RSA and DSA key sizes better.\n\nMost asymmetric operations scale superlinearly, which makes them\npotential DoS vectors. This (and other problems) are mitigated with\nfixed sizes, like RSA-2048, P-256, or curve25519.\n\nIn older algorithms like RSA and DSA, these sizes are conventions rather\nthan well-defined algorithms. \"Everyone\" uses RSA-2048, but code which\nimports an RSA key may see an arbitrary key size, possibly from an\nuntrusted source. This is commonly a public key, so we bound RSA key\nsizes in check_modulus_and_exponent_sizes.\n\nHowever, some applications import external private keys, and may need\ntighter bounds. These typically parse the key then check the result.\nHowever, parsing itself can perform superlinear work (RSA_check_key or\nrecovering the DSA public key).\n\nThis CL does the following:\n\n- Rename check_modulus_and_exponent_sizes to rsa_check_public_key and\n  additionally call it from RSA_check_key.\n\n- Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and\n  bound p and q before multiplying (quadratic).\n\n- Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit\n  only) than our DSA signer (multiple of 8 bits). Aligner the signer to\n  the verifier\u0027s checks.\n\n- Validate DSA group sizes on parse, as well as priv_key \u003c q, to bound\n  the running time.\n\nIdeally these invariants would be checked exactly once at construction,\nbut our RSA and DSA implementations suffer from some OpenSSL\u0027s API\nmistakes (https://crbug.com/boringssl/316), which means it is hard to\nconsistently enforce invariants. This CL focuses on the parser, but\nlater I\u0027d like to better rationalize the freeze_private_key logic.\n\nPerformance of parsing RSA and DSA keys, gathered on my laptop.\n\nDid 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec)\nDid 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec)\nDid 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec)\nDid 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL]\nDid 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec)\nDid 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec)\nDid 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec)\nDid 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec)\nDid 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec)\nDid 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec)\nDid 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL]\n\nUpdate-Note: Some invalid or overly large RSA and DSA keys may\npreviously have been accepted that are now rejected at parse time. For\npublic keys, this only moves the error from verification to parsing. In\nsome private key cases, we would previously allow signing with those\nkeys, but the resulting signatures would not be accepted by BoringSSL\nanyway. This CL makes us behave more consistently.\n\nBug: oss-fuzz:24730\nChange-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5cd98f8b48676fdc75e15214bbb455c083d6c530",
      "old_mode": 33188,
      "old_path": "crypto/dsa/dsa.c",
      "new_id": "c8695687cf1ac7706af0c20d78f493aeef6efa19",
      "new_mode": 33188,
      "new_path": "crypto/dsa/dsa.c"
    },
    {
      "type": "modify",
      "old_id": "97fd07fee18fba59ccadf69cb879bb2f3f7a7330",
      "old_mode": 33188,
      "old_path": "crypto/dsa/dsa_asn1.c",
      "new_id": "3f3bd48866cb90356fb7532a15415d5a0075fd0b",
      "new_mode": 33188,
      "new_path": "crypto/dsa/dsa_asn1.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "2d86edb2dcb7020033cb2743e7937a6d66b6772b",
      "new_mode": 33188,
      "new_path": "crypto/dsa/internal.h"
    },
    {
      "type": "modify",
      "old_id": "d50e0fc3749cd6f407176da0df9870326027a524",
      "old_mode": 33188,
      "old_path": "crypto/evp/p_dsa_asn1.c",
      "new_id": "ac91127b6975e0cbab703a7999cff093192e94ba",
      "new_mode": 33188,
      "new_path": "crypto/evp/p_dsa_asn1.c"
    },
    {
      "type": "modify",
      "old_id": "faa6fb7470819c6380135f14aa7d027c93b42d3a",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rsa/internal.h",
      "new_id": "d9d6fac80b9a25c5eadfff01d198bafeb181bedf",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rsa/internal.h"
    },
    {
      "type": "modify",
      "old_id": "29296737e02d44bc2c1c3d7185dd274bf70590bd",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rsa/rsa.c",
      "new_id": "ae63e1a67381334750774a7d4f307ef2b187f2ac",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rsa/rsa.c"
    },
    {
      "type": "modify",
      "old_id": "2d9a9c9fa9a589912b608f2fd3dc27f8fa8a1b23",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rsa/rsa_impl.c",
      "new_id": "86ff2f389c8cce50f762862ae637c3f8ef56960d",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rsa/rsa_impl.c"
    },
    {
      "type": "modify",
      "old_id": "b305225bdbc498d8132d14132dc77371af5a94fd",
      "old_mode": 33188,
      "old_path": "include/openssl/evp.h",
      "new_id": "e647cdf60ae298fbc1caf03006e2ccf15151a75c",
      "new_mode": 33188,
      "new_path": "include/openssl/evp.h"
    }
  ]
}