Discussion issue for crypto: AES-CTR implementation

[cryptographix]

The W3C web-crypto specification for AES-CTR (counter-mode) includes a counter length parameter that allows splitting the 128-bit counter block in two, a fixed nonce on the LHS and an incrementing+wrapping counter on the RHS.

ctr crate currently does not support run-time selection of arbitrary (0..128) values of length as per W3C requirements, but three length options are supported as compile-time variants. Upstream issue opened here - thinking about submitting a PR there, but it's not a trivial implementation.

Node and chromium implementations (using openssl/boringssl) do the splitting manually, calling the lower API as many times as required for chunks of counter-value. Not recommended as discussed on discord, and prone to subtle security errors if not done correctly.

However, common usage of AES-CTR appears to be limited to a few specific break-points, for example, IPSEC RFC3686 uses 32 bits, and NIST recommendations (SP800-38A B2) specify two options - 128 (full counter) and 64 bits (64 bit nonce and 64 bit counter).

Since all three common options are supported by the ctr crate, this opens the possibility of DENO shipping AES-CTR with these options, and rejecting any other values of counter-length parameter, before encryption/decryption begins. Of course, this restriction can then be removed if/when the ctr crate includes support for arbitrary values of length.

Strategy implemented in #13177.

LMKWYT @lucacasonato @littledivy