)]}'
{
  "commit": "33f456b8b05c73dff13c0b4653f7d964ed2721d6",
  "tree": "6831f098839af584c0a1032fa8dec9c7327ee521",
  "parents": [
    "470bd56c9bb81b13d362c3a06c66aa98850d313e"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sat Jan 12 15:29:10 2019 +0000"
  },
  "committer": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Feb 01 18:03:39 2019 +0000"
  },
  "message": "Don\u0027t use bsaes over vpaes for CTR-DRBG.\n\nRAND_bytes rarely uses large enough inputs for bsaes to be worth it.\nhttps://boringssl-review.googlesource.com/c/boringssl/+/33589 includes some\nrough benchmarks of various bits here. Some observations:\n\n- 8 blocks of bsaes costs roughly 6.5 blocks of vpaes. Note the comparison\n  isn\u0027t quite accurate because I\u0027m measuring bsaes_ctr32_encrypt_blocks against\n  vpaes_encrypt and vpaes in CTR mode today must make do with a C loop. Even\n  assuming a cutoff of 6 rather than 7 blocks, it\u0027s rare to ask for 96 bytes\n  of entropy at a time.\n\n- CTR-DRBG performs some stray block operations (ctr_drbg_update), which bsaes\n  is bad at without extra work to fold them into the CTR loop (not really worth\n  it).\n\n- CTR-DRBG calculates a couple new key schedules every RAND_bytes call. We\n  don\u0027t currently have a constant-time bsaes key schedule. Unfortunately, even\n  plain vpaes loses to the current aes_nohw used by bsaes, but it\u0027s not\n  constant-time. Also taking CTR-DRBG out of the bsaes equation\n\n- Machines without AES hardware (clients) are not going to be RNG-bound. It\u0027s\n  mostly servers pushing way too many CBC IVs that care. This means bsaes\u0027s\n  current side channel tradeoffs make even less sense here.\n\nI\u0027m not sure yet what we should do for the rest of the bsaes mess, but it seems\nclear that we want to stick with vpaes for the RNG.\n\nBug: 256\nChange-Id: Iec8f13af232794afd007cb1065913e8117eeee24\nReviewed-on: https://boringssl-review.googlesource.com/c/34744\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3e18659358f493681864512dded6af39e7daa2c9",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/e_aesccm.c",
      "new_id": "144a9093cae667500bf633f7f28a3d86bf00f57f",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/e_aesccm.c"
    },
    {
      "type": "modify",
      "old_id": "8c45c8111a5d6364047ed26252ea896b0a04256f",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/e_aesctrhmac.c",
      "new_id": "0834bd1d78f597658a19e249365f9584826918f8",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/e_aesctrhmac.c"
    },
    {
      "type": "modify",
      "old_id": "71a71fac4a66f151b9b4cdb331cf9ac23d760dc2",
      "old_mode": 33188,
      "old_path": "crypto/cipher_extra/e_aesgcmsiv.c",
      "new_id": "0e5063cd5678d7b58104f9ea34e1f0e3fef1917f",
      "new_mode": 33188,
      "new_path": "crypto/cipher_extra/e_aesgcmsiv.c"
    },
    {
      "type": "modify",
      "old_id": "81c74cbf4edf389ef816aa439f17033f9311cc09",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/cipher/e_aes.c",
      "new_id": "7745036f74f33cf754e95d2bf982aedd6e29d6d8",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/cipher/e_aes.c"
    },
    {
      "type": "modify",
      "old_id": "7c739fbd1341858e33ce9386a216805c50d071d7",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/cipher/internal.h",
      "new_id": "b9e61ec8b432be8e2b6814845c3e8fc4bbb6b4c1",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/cipher/internal.h"
    },
    {
      "type": "modify",
      "old_id": "b2fda1dad57c0285d74d104a1812a44fbbcbdbd1",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/rand/ctrdrbg.c",
      "new_id": "418f56b639bb953c314181b3e2f76c7b789f116e",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/rand/ctrdrbg.c"
    }
  ]
}