)]}'
{
  "commit": "ccaee0a64c053bcc799f00bde42e7e29bda02dec",
  "tree": "8f3972d7abbf7fe7f5bab591ac9c77f227f9e5a1",
  "parents": [
    "701d95a2a83aaaa9a75741202867ce3f8a3bf8aa"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sun Aug 25 21:17:55 2019 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Fri Sep 13 17:47:18 2019 +0000"
  },
  "message": "Use a mix of bsaes and vpaes for CTR on NEON.\n\ntl;dr: AES is now constant-time on 32-bit ARM with NEON. Combined with\nall the past work, we now have constant-time AES and GHASH on ARM and\nx86 chips, 32-bit and 64-bit, provided NEON (required by Chrome on\nAndroid, aside from https://crbug.com/341598) or SSSE3 (almost all\nChrome on Windows users) is available!\n\nCTR-like bsaes modes is harder to resolve than CBC decryption. They use\nboth bulk (ctr128_f) and one-off (block128_f) operations. We currently\nuse ctr128_f of bsaes and block128_f of aes_nohw (not constant-time),\nwhich hits 22.0 MB/s on my test chip.\n\nImplement a vpaes/bsaes hybrid to get the best of both worlds. The key\nis kept in vpaes form and, when the input is large enough, we convert\nthe key to bsaes on-demand. This retains bsaes performance, but with no\nvariable-time gaps.\n\nAlternatives considered:\n\n- Convert to bsaes form immediately and only use bsaes. This makes the\n  one-off block128_f calls very expensive. One 8-block batch of\n  bsaes_ctr32_encrypt_blocks costs as much as 5.76 vpaes_encrypt calls.\n\n- Do the above, but fold the one-off calls into bsaes batches because\n  GCM is parallelizable. This is a mess with the current internal\n  structure and doesn\u0027t apply to, e.g., CCM.\n\n- Drop bsaes in favor of vpaes. However, even with\n  vpaes_ctr32_encrypt_blocks, vpaes is 15.5 MB/s. The hybrid is a 40%\n  win on an important platform.\n\n- Try to narrow the gap, as we did for x86_64, with a \"2x\" optimization.\n  I attempted this here but the register pressure was tricky. (x86_64\n  was already tight and NEON can\u0027t address memory in vtbl.) If I ignored\n  this (gives wrong answer), the gap was still 20-25%. Perf here is\n  slower overall (20 MB/s for old ARM vs 120-140 MB/s for old x86_64),\n  so that gap is scarier.\n\nI retained vpaes_ctr32_encrypt_blocks because it\u0027s fairly compact (only\n84 bytes assembled), though it\u0027s less important in the bsaes hybrid.\n\nCortex-A53 (Raspberry Pi 3 Model B+)\nBefore:\nDid 267000 AES-128-GCM (16 bytes) seal operations in 2004871us (133175.7 ops/sec): 2.1 MB/s\nDid 135000 AES-128-GCM (256 bytes) seal operations in 2013825us (67036.6 ops/sec): 17.2 MB/s\nDid 31000 AES-128-GCM (1350 bytes) seal operations in 2059039us (15055.6 ops/sec): 20.3 MB/s\nDid 5565 AES-128-GCM (8192 bytes) seal operations in 2073607us (2683.7 ops/sec): 22.0 MB/s\nDid 2709 AES-128-GCM (16384 bytes) seal operations in 2020264us (1340.9 ops/sec): 22.0 MB/s\nDid 209000 AES-256-GCM (16 bytes) seal operations in 2005654us (104205.4 ops/sec): 1.7 MB/s\nDid 109000 AES-256-GCM (256 bytes) seal operations in 2011293us (54194.0 ops/sec): 13.9 MB/s\nDid 25000 AES-256-GCM (1350 bytes) seal operations in 2082385us (12005.5 ops/sec): 16.2 MB/s\nDid 4452 AES-256-GCM (8192 bytes) seal operations in 2080729us (2139.6 ops/sec): 17.5 MB/s\nDid 2226 AES-256-GCM (16384 bytes) seal operations in 2079819us (1070.3 ops/sec): 17.5 MB/s\n\nAfter:\nDid 542000 AES-128-GCM (16 bytes) seal operations in 2003408us (270539.0 ops/sec): 4.3 MB/s [+104.8%]\nDid 124000 AES-128-GCM (256 bytes) seal operations in 2012579us (61612.5 ops/sec): 15.8 MB/s [-8.1%]\nDid 30000 AES-128-GCM (1350 bytes) seal operations in 2020636us (14846.8 ops/sec): 20.0 MB/s [-1.5%]\nDid 5502 AES-128-GCM (8192 bytes) seal operations in 2068807us (2659.5 ops/sec): 21.8 MB/s [-0.9%]\nDid 2772 AES-128-GCM (16384 bytes) seal operations in 2085176us (1329.4 ops/sec): 21.8 MB/s [-0.9%]\nDid 459000 AES-256-GCM (16 bytes) seal operations in 2003587us (229089.1 ops/sec): 3.7 MB/s [+117.6%]\nDid 100000 AES-256-GCM (256 bytes) seal operations in 2018311us (49546.4 ops/sec): 12.7 MB/s [-8.6%]\nDid 24000 AES-256-GCM (1350 bytes) seal operations in 2026975us (11840.3 ops/sec): 16.0 MB/s [-1.2%]\nDid 4410 AES-256-GCM (8192 bytes) seal operations in 2079581us (2120.6 ops/sec): 17.4 MB/s [-0.6%]\nDid 2226 AES-256-GCM (16384 bytes) seal operations in 2099318us (1060.3 ops/sec): 17.4 MB/s [-0.6%]\n\nBug: 256\nChange-Id: Ib74ab7e63974d3ddae8ce5fc35c9b44e73dce305\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37429\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d147c968731acc4c243bffd3f0c7991156a03de1",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/aes/asm/vpaes-armv7.pl",
      "new_id": "f9fadda99a479648fd97036ab96e37f5d30a9e77",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/aes/asm/vpaes-armv7.pl"
    },
    {
      "type": "modify",
      "old_id": "8471a808a06619086264496d4ee5b3d9c305037f",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/aes/internal.h",
      "new_id": "99d509a98394a80e4a1e6a3aae509b36139b01cc",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/aes/internal.h"
    },
    {
      "type": "modify",
      "old_id": "685d2db7230f84b742af8cd4f9aeb5d94e71dd1d",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/cipher/e_aes.c",
      "new_id": "72910edb7e48f07ebcfb221deb8dabf05683fda8",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/cipher/e_aes.c"
    }
  ]
}