Asymmetric encryption of the AES key made available along with the ciphertext

Question

I know there are much more sophisticated encryption schemes than this one that achieve the same goal but I would like to understand any weaknesses in this basic, and probably typical, process:

1. generate a pair of keys with an asymmetric algorithm of your choice, say RSA.

2. Generate a random 32 byte string with a good random number generation algorithm say Crypto.getRandomValues() of Web Crypto API.

3. Encrypt a file using a good symmetric encryption algorithm, say AES, using the random string referred to in point 2 as the key, creating a binary object C.

4. Encrypt the string referred to in point 2 together with some metadata, for example the filename of encrypted file, with the public key generated in point 1 creating the binary object H.

5. Concatenate the binary objects H and C (in this order) creating a third final binary object which we will call binary object T (target).

6. Repeat the process from 2 to 5 on a series of different files, say 100, obtaining 100 binary objects T1, T2, ..., T100 which are made public.

Which type of attack, if any, is this process prone to?

Are there any particular algorithmic choices in points 1, 2 and 3 that make the process more prone to some type of attack?

Answer 1

in this basic, and probably typical, process

It is relatively typical. Usually though the meta-data is not encrypted together with the AES symmetric key. Usually it is wrapped on it's own without the meta data. It isn't clear what the encryption of the filename is supposed to accomplish or what the new filename would be if it is supposed to be kept confidential.

Which type of attack, if any, is this process prone to?

Before answering the question, it should be made clear which attack scenarios are plausible.

Furthermore, the specification indicates a "good symmetric encryption algorithm, say AES". However, AES is not a generic cipher. For that AES block cipher needs to be run in a mode of operation that creates one.

Less of an issue is supposing that RSA does require a specific scheme as well. Currently you'd just use OAEP. However, all this shows that this is really a prototype protocol rather than an actual protocol.

The current prototype protocol may be vulnerable against the following attacks:

1. an attacker may be able to replace the public key if trust in that key cannot be established by the encrypting party;
2. the protocol doesn't provide any message authentication, which makes it possible to change any bits in transit;
3. it is likely vulnerable against plaintext and padding oracle attacks, in case it is used in a usage scenario where those are feasible.

The "Web Crypto API" shows that this scheme maybe used for web based encryption. In that case you'd need to include TLS at the very minimum; this scheme is not secure for messages in transit.