)]}'
{
  "commit": "669ffe64a498a16ed8a339758c3abedcbb3d9522",
  "tree": "3416fffe8c4caa5c7355f753e3bc60b8879dac83",
  "parents": [
    "00e434d67e15c9b6d535a29e9ef05a7ab48ad122"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Wed Apr 07 16:17:50 2021 -0400"
  },
  "committer": {
    "name": "CQ bot account: commit-bot@chromium.org",
    "email": "commit-bot@chromium.org",
    "time": "Thu Apr 08 21:08:56 2021 +0000"
  },
  "message": "Simplify the Lucky13 mitigation.\n\nRather than computing kVarianceBlocks, which is hard to reason about,\nuse a sha1_final_with_secret_suffix abstraction. This lets us separate\nreasoning in bytes about the minimum and maximum values of |data_size|\nand the interaction with HMAC, separately from the core constant-time\nSHA-1 update.\n\nIt\u0027s also faster. I\u0027m guessing it\u0027s the more accurate block counts.\n\nBefore:\nDid 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec)\nDid 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec)\nDid 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec)\nDid 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec)\nDid 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec)\n\nAfter:\nDid 2089000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000049us (16.7 MB/sec) [+141.3%]\nDid 851000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000034us (108.9 MB/sec) [+38.2%]\nDid 553000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002169us (372.9 MB/sec) [+28.1%]\nDid 178000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2008596us (726.0 MB/sec) [+20.1%]\nDid 98000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2001509us (802.2 MB/sec) [+18.6%]\n\nConfirmed with valgrind tooling that this is still constant-time. In\ndoing so, I ran into a new nuisance with GCC. In loops where we run\nconstant_time_lt with a counter value, GCC sometimes offsets the loop\ncounter by the secret. It cancels it out before dereferencing memory,\netc., but valgrind does not know that x + uninit - uninit \u003d x and gets\nupset. I\u0027ve worked around this with a barrier for now.\n\nChange-Id: Ieff8d2cad1b56c07999002e67ce4e6d6aa59e0d3\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46686\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "af7e0e7ab74ad724f791807e20cb898c609245a9",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/cipher_test.cc",
      "new_id": "57fdc8ac1cbb588dbef7ad6f18e5b8319fc787f6",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/cipher_test.cc"
    },
    {
      "type": "modify",
      "old_id": "e0d4eb4cdf5eb4f3cd7a19380a1f597b33d44850",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/e_tls.c",
      "new_id": "6d84f7f02c411a5ea7d7099808e1ff692b92ade0",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/e_tls.c"
    },
    {
      "type": "modify",
      "old_id": "c2af48e22639d8cea38bedb6c3485e8dbde9d82d",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/internal.h",
      "new_id": "a2ec30b07ad0d778ddd20848f4384f17c00aa710",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/internal.h"
    },
    {
      "type": "modify",
      "old_id": "f446362dc9f1b971b7d0b7ee513d66c358ba8b83",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/tls_cbc.c",
      "new_id": "e1e95d42540ab7fed24e7bb96318ac2a4593520e",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/tls_cbc.c"
    }
  ]
}