Optimize AesCtrEncryptor performance

[kqyang]

There are some performance overheads in the current AES CTR implementation: https://github.com/google/shaka-packager/blob/master/packager/media/base/aes_encryptor.cc#L61.

We should be able to improve the performance significantly by using a similar approach as OpenSSL implementation: https://github.com/google/boringssl/blob/104306f587751f34852838915fb61ce5551c2332/crypto/fipsmodule/modes/ctr.c#L85.

We could either implement it in Shaka Packager repository or implement it in boringssl by adding a new CRYPTO_ctr128_encrypt_ctr64 function and submit a pull request to boringssl.

[kqyang]

This feature request, along with #198 will improve encryption and packaging performance a lot.

[baniks3]

@kqyang I'd be willing to work on this, except I'm not sure what optimization you're looking to implement. https://github.com/google/shaka-packager/blob/master/packager/media/base/aes_encryptor.cc#L79 ends up calling https://github.com/google/boringssl/blob/104306f587751f34852838915fb61ce5551c2332/crypto/fipsmodule/aes/aes.c#L817 which seems to be already using hw acceleration if available. Please advise.

[kqyang]

@baniks3 Thanks for volunteering.

Please see OpenSSL's implementation here: https://github.com/google/boringssl/blob/104306f587751f34852838915fb61ce5551c2332/crypto/fipsmodule/modes/ctr.c#L85.

I had done a quick hack by replacing the current logic in https://github.com/google/shaka-packager/blob/master/packager/media/base/aes_encryptor.cc#L77 with

  AES_ctr128_encrypt(plaintext, ciphertext, plaintext_size, aes_key(),
                     &counter_[0], &encrypted_counter_[0], &block_offset_);

It increased performance by more than 30% on top of the existing hardware acceleration (for encryption). (You can use the current AesPerformanceTest.AesCtr to verify: out/Release/media_base_unittest --gtest_filter="AesPerformanceTest.AesCtr".)

As mentioned in https://github.com/google/shaka-packager/issues/667#issue-510912498, (1) we can implement a function in boringssl with 64 bit increment: AES_ctr64_encrypt or (2) refactor the current implementation in Shaka Packager repo to follow the same approach as OpenSSL's implementation. (2) is probably easier.

The main idea of OpenSSL's implementation is that it breaks the code into three parts:

  ...
  // Part 1: Handle unaligned bytes from previous encrypted counter.
  while (n && len) {
    *(out++) = *(in++) ^ ecount_buf[n];
    --len;
    n = (n + 1) % 16;
  }
  // Part 2: Handle the aligned blocks
  while (len >= 16) {
    (*block)(ivec, ecount_buf, key);
    ctr128_inc(ivec);
    ...
  }
  // Part 3: Handle the remaining unaligned bytes
  if (len) {
    (*block)(ivec, ecount_buf, key);
    ctr128_inc(ivec);
    ...
  }
  ...

(*block)(ivec, ecount_buf, key) can be replaced with AES_encrypt. ctr128_inc can be replaced with Increment64.

Let me know if you have more questions.

[baniks3]

@kqyang Thnx for the input. Hopefully I'll be able to allocate time to work on it from next week.