AES-CBC

[jedisct1]

Although it is not part of TLS 1.3 (due to the Vaudenay attack), there are quite a few common applications that require AES-CBC.

Since it is widely supported by libraries, this is something we may want to add to the required set of algorithms in WASI-Crypto.

[jedisct1]

Closing. As this is not an AEAD, and is easy to use incorrectly without authentication, it probably doesn't belong to the set of required algorithms.

However, what we can do is define identifiers for a common, optional algorithms such as AES-CBC.

[rcombs]

CBC does continue to have a place in applications where authentication is not required (not everything is TLS!), as does CTR; exposing the raw AES primitive (ECB, effectively) would allow applications to implement additional more-specialized cipher modes (e.g. XTS). Defining them as optional does seem reasonable.

[jedisct1]

Absolutely. Like low-level EC and modular arithmetic, this is something we may want to eventually include in the specification.

But maybe not in the first iteration, which is really more about defining a set small enough to get actual implementations and adoption.

We need to make sure that the APIs can support these without breaking changes, though. Suite names can already be reserved for AES-CBC with and without a HMAC.

As to exposing AES-ECB, that should be a different discussion. This is not enough to implement modern ciphers that use the AES permutation (AEGIS), performance would be poor, and that doesn't play well with using wasi-crypto as a HSM with opaque keys. Defining optional support for AES-XTS is probably a better approach.