An alternative would be to implement AES encryption on the keyserver from scratch using the part of crypto API that comes typed in flow. I thought about this and it has two disadvantages:

1. We would repeat implementation of the same functionality twice, while technically nothing prevents us from having one common API. It reduces code quailty and maintainability. Every change to the way we handle AES encryption would require to remember about more places in the codebase.
2. Even though some crypto API is typed in flow it is still not complete. In particular the function to generate a secret key for particular algorithm is missing in flow typed. Therefore we would still need to write our own types and probably do casting to any.

An alternative would be to move this entire file to lib and insert webcrypto into global on the keyserver so that the statement declare var crypto: Crypto; is true. However, the crypto on the keyserver is a library and we don't just insert libraries into global so that they don't need to be imported. Therefore I moved only the types to the lib and left global declaration on web.

I could remove this file and use function from lib directly, but I didn't want to affect to much code and leave this layer of abstraction unchanged.

I agree we should not reimplement it. This any-cast is safe, since you immediately cast it to another type

In all three of these cases, your use of async / await is not necessary, and results in unnecessary computation. Instead, you can simplify forward the Promise