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?


1 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.

  • $\begingroup$ Thank you for your answer @MaartenBodewes. The whole process is aimed at the simplest possible use of a pair of asymmetric keys that were already in use for other purposes. One use for example for file encryption at rest. My question is aimed at understanding whether anyone who somehow came into possession of the files encrypted through the process described but still did not have access to the pair of asymmetric keys could somehow conduct an attack facilitated in some way by having many files encrypted with the same method available. $\endgroup$
    – blockmined
    Commented May 6 at 8:11
  • $\begingroup$ Usually encryption modes are secure even if the plaintext are known or even controlled by the attacker. For RSA and other asymmetric ciphers this is kind of implied of course, otherwise it would not be secure at all, as you encrypt with the public key. We cannot limit the attacker to a certain number of messages after all. $\endgroup$
    – Maarten Bodewes
    Commented May 6 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.